Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

How to execute console commands from wizard?

<< < (2/3) > >>

writser:

--- Quote from: Game_Ender on October 22, 2006, 08:28:39 pm ---While pkg-config in the final build options is not best for CodeCompletion its the best solution for portability there is.  Just taking the output of pkg-config during the wizard phase makes the wizard portable but the not the resulting project file.  So I think the solution is to find a way for CodeCompletion to parse the output of pkg-config for include paths.  Tools like pkg-config are common place (see wx-config) so its not an unusual request.

Keeping the scripts sandbox only protects the user if they run untrusted wizards/configuration scripts and if the script can't already do something nasty through the CB sdk API.

--- End quote ---

I agree this is the best method. But it is also harder to implement. And is it really that evil to allow scripts to access the console? I mean, it's a 'script', right? Not a plain textfile. If a user downloads an evil script from an evil website, is it our responsibility to stop that script from doing harm? And any 3rd party compiled plugin could do the same. Should they be restricted too? I don't know. In any case, adding support for pkg-config and friends is really something I would like to see in Code::Blocks. I don't know any other IDE with this feature and it would be really useful.

takeshimiya:
I'm 300% with Game_ender, pkg-config the best solution for portability, it's easy to implement.

For example, I've used both wx-config and pkg-config for both Windows and Linux for the C::B plugins wizard

See here cbpluginwizard.patch and codeblocks.pc.

And about CodeCompletion, the best fix is the Game_ender solution's.

workwind:

--- Quote from: writser on October 22, 2006, 08:55:16 pm ---I agree this is the best method. But it is also harder to implement. And is it really that evil to allow scripts to access the console? I mean, it's a 'script', right? Not a plain textfile. If a user downloads an evil script from an evil website, is it our responsibility to stop that script from doing harm? And any 3rd party compiled plugin could do the same. Should they be restricted too? I don't know. In any case, adding support for pkg-config and friends is really something I would like to see in Code::Blocks. I don't know any other IDE with this feature and it would be really useful.

--- End quote ---
That's right! I don't think that security is an issue here: At the moment it would be possible for a sqirrel script to add a new project with a custom Makefile, place some evil code in the file, and invoke the build process....

thomas:

--- Quote ---The exec-function is described here: http://squirrel-lang.org/doc/sqstdlib2.html#d0e1925.
--- End quote ---
Ah, though it's called system, I must be blind for not having found that. Thanks :)


--- Quote ---Although I 'm the one who did this, I doubt we gained any security at all
--- End quote ---
It is the only sensible thing to do, though.

Scripts are not only embeddable in wizards, but also in other places (for example project files). People are not necessarily aware of this, neither do antivirus packages necessarily scan project files (for example, I remember from back in the old days when I was foolish enough to use Nerfton, the default setting would only scan a small subset of files).
It is also unclear inhowfar the mighty heuristic algorithms found in today's virus scanners are able to scan scripts for unknown malicious code at all (in particular squirrel, which is probably not even considered being "code" by most). I'd rather believe they don't do much.

Given functions that can modify files, rename and move files and folders, and execute external programs, scripts are quite a dangerous tool. Embedded scripts are a necessary evil, but they should be as safe as can be. Even then we can never be 100% sure that there is no exploit, but we have done what we can.

While it is true that a plugin could do all of that (and more) too, it is a much more obvious threat. Every user is probably aware of this possibility, and can decide whether or not to take that risk (or could read the sources and recompile the plugin from source).
It is true, too, that I can always ship a makefile that contains a rm /* or some other evil stuff. However, one thing being insecure does not justify making another thing insecure, too (actually I am thinking right now whether it may be a good idea to allow turning off custom makefiles entirely, since most people don't use them anyway).

From a user's point of view, knowing that scripts can be embedded in so many subsystems and a script is able to damage my system or install malware would be a good reason to stop using Code::Blocks for me.
I refuse to look at Word and PowerPoint documents that people send to me for the same reason, even if it's people that I have known for 10 years.


--- Quote ---If a user downloads an evil script from an evil website, is it our responsibility to stop that script from doing harm?
--- End quote ---
Do you work for Microsoft?  :lol:
Just wondering... sounds like IE's standard mode of operation ;)

takeshimiya:
About the security stuff...
It really depends on which side of the balance you are, sandboxed scripts vs. powerful scripts.

For example Squirrel Shell gives access to run programs, create folders, so it's on the powerful-scripts side.

How much malicious .vbs scripts have been made for Word and PowerPoint? A lot.
And how much have been made for Visual Studio? ...

A solution could be something like code signing (despite the source).

I really doubt specially power-users, administrators or developers like to be limited like regular users.

I would leave that to consumer-grade programs...

BTW, I was wanting to add the very useful bindings of Squirrel Shell to the C::B bindings, but if security is SUCH an issue, I guess this will need more discussion.


Now back on topic, writser, please make use of pkg-config directly, because it is tiresome to write different projects for different platforms where it is not necessary.

Navigation

[0] Message Index

[#] Next page

[*] Previous page