digitalmars.D - -J all
- DigitalDesigns (15/15) Jun 09 2018 Please allow -J to specify that all subdirectories are to be
- Basile B. (5/20) Jun 10 2018 This is opened as an enhancement request now:
- DigitalDesigns (8/32) Jun 10 2018 Yeah, but -J was added for a security concern! So when does the
- Cym13 (12/45) Jun 10 2018 There's no contradiction nor insanity, you're saying the same
- DigitalDesigns (51/97) Jun 10 2018 No I'm not, which proves the insanity is still here:
- Basile B. (10/113) Jun 11 2018 Common man just calm down. Read the thread again. About the
- Basile B. (3/27) Jun 10 2018 Sorry i've been extremely clumsy with the issue description. It's
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 .... ... .. .
Jun 09 2018
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.
Jun 10 2018
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:Yeah, but -J was added for a security concern! So when does the insanity end? 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.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.
Jun 10 2018
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:There's no contradiction nor insanity, you're saying the same thing he did: -J was added for a security concern.On Sunday, 10 June 2018 at 01:49:37 UTC, DigitalDesigns wrote:Yeah, but -J was added for a security concern! So when does the insanity end?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.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. It's not a bad risk to consider but I wonder if that's the best solution we can find.
Jun 10 2018
On Monday, 11 June 2018 at 05:15:05 UTC, Cym13 wrote:On Sunday, 10 June 2018 at 19:10:52 UTC, DigitalDesigns wrote: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.On Sunday, 10 June 2018 at 14:42:21 UTC, Basile B. wrote:There's no contradiction nor insanity, you're saying the same thing he did: -J was added for a security concern.On Sunday, 10 June 2018 at 01:49:37 UTC, DigitalDesigns wrote:Yeah, but -J was added for a security concern! So when does the insanity end?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.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?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.
Jun 10 2018
Basile B. <b2.b2.temp.temp gmx.gmx.com.com.com> On Monday, 11 June 2018 at 06:52:20 UTC, DigitalDesigns wrote:On Monday, 11 June 2018 at 05:15:05 UTC, Cym13 wrote: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.On Sunday, 10 June 2018 at 19:10:52 UTC, DigitalDesigns wrote: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.On Sunday, 10 June 2018 at 14:42:21 UTC, Basile B. wrote:There's no contradiction nor insanity, you're saying the same thing he did: -J was added for a security concern.On Sunday, 10 June 2018 at 01:49:37 UTC, DigitalDesigns wrote:Yeah, but -J was added for a security concern! So when does the insanity end?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.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?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.
Jun 11 2018
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:Sorry i've been extremely clumsy with the issue description. It's now https://issues.dlang.org/show_bug.cgi?id=18968Please 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.
Jun 10 2018