On Wed, 07 Feb 2007 07:36:23 +0200, Vladimir Panteleev wrote:

> On Wed, 07 Feb 2007 02:06:44 +0200, John Reimer <terminal.node@gmail.com> wrote:
> 
>> On Wed, 07 Feb 2007 05:13:06 +0900, Bill Baxter wrote:
>>
>>> Also, people download and run makefiles to build their software all the time. Who knows what that makefile is doing.  There could be an rm -rf / buried in there somewhere in all that tab-sensitive gobbledy-gook.
>>
>> Very good point.
>>
>> Any auxillary tool in the compilation process could could do the same.  I have difficult recognizing the validity of Walter's concern in this context.
> 
> I believe there must be a strict distinction between tools which just work with data or code, and tools which run code. The sole definition of a compiler is transform human-readable code to machine code - not run any of those outside the purpose of generating other code or data.
> 
> Unit tests are a separate issue, because to run them the user must specify a switch on the compiler's command-line - in which case he is well-aware that code will be run. Thus, if any such feature does get implemented, the compiler should not execute any code and give off an error instead, and force the user to specify a switch which allows this, to prevent any naive mistakes and annoyances.
> 
> That, or write in big letters on the DMD download page... "This compiler may run some of the compiled code" in big red letters. But that'll just scare more people off...
>


Hmm... so is not possible that rdmd.exe (rdmd on linux) might commit the same sort of security breech?  It's even packaged with the compiler?  Is it safe?

-JJR

On Wed, 07 Feb 2007 07:44:06 +0200, John Reimer <terminal.node@gmail.com> wrote:

> On Wed, 07 Feb 2007 07:36:23 +0200, Vladimir Panteleev wrote:
>
>> I believe there must be a strict distinction between tools which just work with data or code, and tools which run code. The sole definition of a compiler is transform human-readable code to machine code - not run any of those outside the purpose of generating other code or data.
>>
>> Unit tests are a separate issue, because to run them the user must specify a switch on the compiler's command-line - in which case he is well-aware that code will be run. Thus, if any such feature does get implemented, the compiler should not execute any code and give off an error instead, and force the user to specify a switch which allows this, to prevent any naive mistakes and annoyances.
>>
>> That, or write in big letters on the DMD download page... "This compiler may run some of the compiled code" in big red letters. But that'll just scare more people off...
>>
>
> Hmm... so is not possible that rdmd.exe (rdmd on linux) might commit the same sort of security breech?  It's even packaged with the compiler?  Is it safe?

rdmd is on the other side of the "line" which I described - its base purpose is to run code, while the compiler's purpose (unless explicitly specified by the user) is to manipulate code. If we are to continue thinking this way, why not eliminate the "executable" attribute on Unix filesystems and assume all files are executable? The user surely knows what is he doing. It's simply common safety practice.

Either way, allowing the compiler to run potentially dangerous code should at least be optional (however [my] common sense would say that it should be disallowed unless manually enabled). Imagine the problems this would cause with remote compiling systems, for example at ACM contests.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow@gmail.com

On Wed, 07 Feb 2007 07:53:20 +0200, Vladimir Panteleev wrote:

>>
>> Hmm... so is not possible that rdmd.exe (rdmd on linux) might commit the same sort of security breech?  It's even packaged with the compiler?  Is it safe?
> 
> rdmd is on the other side of the "line" which I described - its base purpose is to run code, while the compiler's purpose (unless explicitly specified by the user) is to manipulate code. If we are to continue thinking this way, why not eliminate the "executable" attribute on Unix filesystems and assume all files are executable? The user surely knows what is he doing. It's simply common safety practice.
> 
> Either way, allowing the compiler to run potentially dangerous code should at least be optional (however [my] common sense would say that it should be disallowed unless manually enabled). Imagine the problems this would cause with remote compiling systems, for example at ACM contests.
>


Good points.  Your argument make sense.

-JJR

Vladimir Panteleev wrote:
> On Wed, 07 Feb 2007 07:44:06 +0200, John Reimer <terminal.node@gmail.com> wrote:
> 
>> On Wed, 07 Feb 2007 07:36:23 +0200, Vladimir Panteleev wrote:
>>
>>> I believe there must be a strict distinction between tools which just work with data or code, and tools which run code. The sole definition of a compiler is transform human-readable code to machine code - not run any of those outside the purpose of generating other code or data.
>>>
>>> Unit tests are a separate issue, because to run them the user must specify a switch on the compiler's command-line - in which case he is well-aware that code will be run. Thus, if any such feature does get implemented, the compiler should not execute any code and give off an error instead, and force the user to specify a switch which allows this, to prevent any naive mistakes and annoyances.
>>>
>>> That, or write in big letters on the DMD download page... "This compiler may run some of the compiled code" in big red letters. But that'll just scare more people off...
>>>
>> Hmm... so is not possible that rdmd.exe (rdmd on linux) might commit the
>> same sort of security breech?  It's even packaged with the compiler?  Is
>> it safe?
> 
> rdmd is on the other side of the "line" which I described - its base purpose is to run code, while the compiler's purpose (unless explicitly specified by the user) is to manipulate code. If we are to continue thinking this way, why not eliminate the "executable" attribute on Unix filesystems and assume all files are executable? The user surely knows what is he doing. It's simply common safety practice.
> 
> Either way, allowing the compiler to run potentially dangerous code should at least be optional (however [my] common sense would say that it should be disallowed unless manually enabled). Imagine the problems this would cause with remote compiling systems, for example at ACM contests.
> 

Some good points.  With great power comes great responsibility.  Its a good idea to be able to turn off the responsibility when you want it.

I've got nothing against a switch however I think others may feel that once an extremely powerful feature like this gained a foothold, half of D wouldn't work if you disabled the option.

-Joel

Vladimir Panteleev wrote:
> Either way, allowing the compiler to run potentially dangerous code should at least be optional (however [my] common sense would say that it should be disallowed unless manually enabled). Imagine the problems this would cause with remote compiling systems, for example at ACM contests.

I'm with you on that point.

Take something like DSP: you have an embedded D compiler that is invoked in response to a change in a web-script written in D. Without being able to specify where these literal imports are coming from, the results could be disastrous.

There should be an option to disable the behavior, and the path searching behavior of the import expression needs to be well defined.  Ideally, this would involve a separate switch for specifying import paths as distinct from the module include path (so it can be routed to /dev/null if need be). The last thing we want is people hijacking a server, just because a compiler was provided under httpd's process (with it's permissions).


-- 
- EricAnderton at yahoo

Pragma wrote:
> Take something like DSP: you have an embedded D compiler that is invoked in response to a change in a web-script written in D. Without being able to specify where these literal imports are coming from, the results could be disastrous.
> 
> There should be an option to disable the behavior, and the path searching behavior of the import expression needs to be well defined.  Ideally, this would involve a separate switch for specifying import paths as distinct from the module include path (so it can be routed to /dev/null if need be). The last thing we want is people hijacking a server, just because a compiler was provided under httpd's process (with it's permissions).

I think you're right.

Pragma wrote:
> Vladimir Panteleev wrote:
>> Either way, allowing the compiler to run potentially dangerous code should at least be optional (however [my] common sense would say that it should be disallowed unless manually enabled). Imagine the problems this would cause with remote compiling systems, for example at ACM contests.
> 
> I'm with you on that point.
> 
> Take something like DSP: you have an embedded D compiler that is invoked in response to a change in a web-script written in D. Without being able to specify where these literal imports are coming from, the results could be disastrous.

But isn't DSP also going to *run* the resulting compiled code?  If so then you still have the exact same security issues.

--bb