On Monday, 11 June 2018 at 06:52:20 UTC, DigitalDesigns wrote:
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?
Common man just calm down. Read the thread again. About the
security concern i had say "I'm no 100% sure". After verification
it appears that what i remembered was
http://cwe.mitre.org/data/definitions/22.html
This is about going in the parent folders not children so this
wildcard thing would be possible. "Would" because it's not
necessary, this works already:
https://issues.dlang.org/show_bug.cgi?id=14349 was fixed years
ago.