Allowing relative file imports

[Georg Wrede]

Walter Bright wrote:
> Georg Wrede wrote:
>> I mean, how often do you see web sites where stuff is fed to a C 
>> compiler and the resulting programs run????? (Yes it's too slow, but 
>> that's hardly the point here.) That is simply not done.
> 
> Consider the Java JVM. You've probably got one installed on your 
> computer. It gets java code from gawd knows where (as the result of web 
> browsing), it compiles it, and runs it on your machine unbeknownst to you.

I was talking server side. But now that you mention, it would be kind of 
cool to have D within the browser.

> .NET does that too.
> 
> Every day my browser downloads javascript code, compiles it, and runs it.
> 
> There's no reason in principle that D could not be used instead.

True. But then, what would happen to the Systems Language image of D in 
folks' minds, if it is run in a browser, next to Javascript, Java, and 
who knows what "toy" languages? Would Phobos then have to be replaced 
with another library for running the app within a browser?

> This means that we should think about security issues. Compiling 
> untrusted code should not result in an attack on your system.

Well, removing disk file ops, and OS APIs in general would be the first 
step. And if you restrict some include paths, then, for symmetry, you 
should restrict all command line file paths similarly. I think there's a 
lot to do here. A half baked version would just give bad PR, but a 
proper and tight version presumably is quite some work -- but is the 
reward worth it? Is it established that enough people would use it?

Are you thinking of having a parallell Phobos tree for this, or doing it 
with conditional compilation?

> http://www.comeaucomputing.com lets you upload random C++ code, compile 
> it on their system, and view the messages put out by their compiler. 
> Suppose you did it with D, had it import some sensitive file, and put it 
> out with a pragma msg statement?

Well, even they don't let you run the compiled programs. (But that's 
probably mostly because kids would waste all the cpu cycles.) And I'd 
bet the compiler is chrooted, just to be safe. Chrooting would take care 
of that D pragma "exploit", too.

Ahhh, about links: it's the responsibility of the operator to see that 
there are no unnecessary links within the chroot tree. But some 
installations need (and others want, for specific reasons) to have soft 
links, so I don't think the compiler should frawn upon them. It's really 
not the compiler's responsibility. Similarly, there may be hard links, 
and while even they can be "detected", it's really not called for. (One 
could call this Compartmentalization of Responsibility, unheard of in 
Windows.)

---

But really, what I'm wondering here is, is this yet another "hey let's 
do this" thing?? Can we go on like this till September? And where would 
we be then? Shouldn't there be like a roadmap, or something? Or priorities?