On Monday, 11 June 2018 at 05:15:05 UTC, Cym13 wrote:
On Sunday, 10 June 2018 at 19:10:52 UTC, DigitalDesigns wrote:
On Sunday, 10 June 2018 at 14:42:21 UTC, Basile B. wrote:
On Sunday, 10 June 2018 at 01:49:37 UTC, DigitalDesigns wrote:
Please allow -J to specify that all subdirectories are to be
included! I'm having to include all subdirectories of my
library with J because I import each file and extract
information. It would be better to have something like
-JC:\Lib\*
rather than
-JC:\Lib\Internal
-JC:\Lib\Internal\OS
-JC:\Lib\API
-JC:\Lib\API\V1
-JC:\Lib\API\V1\Templates
....
...
..
.
This is opened as an enhancement request now:
https://issues.dlang.org/show_bug.cgi?id=18967. IIRC there
was a security concern mentioned last time this was proposed,
not 100% sure.
Yeah, but -J was added for a security concern! So when does
the insanity end?
There's no contradiction nor insanity, you're saying the same
thing he did: -J was added for a security concern.
No I'm not, which proves the insanity is still here:
He's saying that *'s wasn't added out of security concerns:
"This is opened as an enhancement request now:
https://issues.dlang.org/show_bug.cgi?id=18967. IIRC there was a
security concern mentioned last time this was proposed, not 100%
sure."
And I'm saying that -J was implemented out of security concerns.
So, -J was added for security concerns and * was rejected out of
security concerns!
Please don't be insane, thanks.
If it's such a big, e.g., to prevent root access then limit
asterisk usage to non root and maybe only a depth of 3.
After all, if someone wanted access to sensitive areas just do
-JC:\Windows\System32.
At some point one has to stop policing everything.
I'm not entirely sure what the threat model is, but it seems to
me that we're not trying to protect against an user exposing
sensitive areas. We're trying to protect against code that
isn't trusted at compile time. I think the idea is to avoid
allowing someone to import your config file with all passwords
at compile-time so that it can use it or send it later at
runtime to the attacker.
Yes, that is the point, else why restrict access? So -J was added
so we could get around it because one has to be able to get
around it. But dmd makes it hard for humans to get around it
because they have to go look up all the directories they want to
add and add each one separately. If a D compile time program is
going to use dmd to steal something, it can do it either way.
It is easy for a program to parse multiple directories in to
several commands but more difficult for a human. So adding * is
not much of a threat and it could be limited if someone feels
like it is too much.
-J is a blaring security hole if one really wants to get down to
it. I wouldn't use D if I could it it to import files at compile
time. It breaks all my apps... specially since not one D compile
time virus exists(I'm sure someone will run out and make one).
So, lets go to the chalk board to make sure you understand: -J is
a restriction to prevent any D source code from opening external
files using import except what is listed under -J. Not having
wildcard support further restricts ones freedom as it requires
one to list many extra paths. If * was supported then it would
make using -J much easier without it? it is much harder.
-J added for security and (not *) added for security. So we have
security on top of security... that is the insanity I was
speaking of. Who's idea is to secure D when no one even bothers
to use it to do some potential something that no one could really
describe except basic hacking.
I mean, after all, if someone uses dmd to somehow steal file
information then they almost surely could do it without it and
when they compile they can just use -J with the directory of the
info they want. So, there is really no point in -J in the first
place. You could say that it would be better to be safe than
sorry... of course, that is where the insanity comes from! Are we
really any safer? Where are all these D CT viruses at that I'm
being protected from?!?! And why having they figured out ways to
hack -J?
After all, if this malicious code is ran then it can surely
replace dmd.exe with an imposter and feed it -J so the next time
it is ran would be able then to have access to -J the next time
it is ran.
At some point in the distant future am I going to have to wear a
condom to program in D?
