Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
April 23, 2019 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 --- Comment #1 from Lionello Lunesu <lio+bugzilla@lunesu.com> --- Simply compiling the previous `test.d` with dub shows the problem: $ cat dub.sdl name "test" targetType "executable" $ dub build -b=release Performing "release" build using dmd for x86_64. test ~master: building configuration "application"... Linking... $ strings test | rg '\.d$' | sort | uniq /Users/llunesu/repos/d/dmd/generated/osx/release/64/../../../../../phobos/std/stdio.d etc. When including other Dub dependencies, their paths inside the .dub cache folder will be stored in the final executable as well. -- |
April 23, 2019 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 --- Comment #2 from Lionello Lunesu <lio+bugzilla@lunesu.com> --- One solution I thought of is to strip components from the filenames, the way PATCH(1) does it with its option "--strip": -pnum or --strip=num Strip the smallest prefix containing num leading slashes from each file name found in the patch file. A sequence of one or more adjacent slashes is counted as a single slash. This controls how file names found in the patch file are treated, in case you keep your files in a different directory than the person who sent out the patch. For example, supposing the file name in the patch file was /u/howard/src/blurfl/blurfl.c setting -p0 gives the entire file name unmodified, -p1 gives u/howard/src/blurfl/blurfl.c without the leading slash, -p4 gives blurfl/blurfl.c and not specifying -p at all just gives you blurfl.c. Whatever you end up with is looked for either in the current directory, or the directory specified by the -d option. -- |
April 23, 2019 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 Seb <greeenify@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |greeenify@gmail.com --- Comment #3 from Seb <greeenify@gmail.com> --- I am not sure how this could leak secure data. If you do a release build, you typically strip away all debug information anyhow and that includes __FILE__. Do you have a concrete example on how this could be dangerous or is this just a general concern? -- |
April 24, 2019 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 --- Comment #4 from Lionello Lunesu <lio+bugzilla@lunesu.com> --- (In reply to Seb from comment #3) > I am not sure how this could leak secure data. If you do a release build, you typically strip away all debug information anyhow and that includes __FILE__. Any usage of __FILE__ becomes a string literal and ends up in release builds as well. Which makes sense, but was a bit surprising to me. > Do you have a concrete example on how this could be dangerous or is this just a general concern? My second example shows how my username ended up in the executable, but it could be all kinds of private information: the product name, or a customer name. -- |
April 24, 2019 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 --- Comment #5 from anonymous4 <dfj1esp02@sneakemail.com> --- The idea behind __FILE__ is that editor/ide should be able to automatically locate it, so it might need to be a system-wide unambiguous path. For identification alone there's __MODULE__ -- |
December 17, 2022 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P4 -- |
April 18, 2023 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 ZombineDev <petar.p.kirov@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |petar.p.kirov@gmail.com -- |
April 18, 2023 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |razvan.nitu1305@gmail.com Resolution|--- |WONTFIX --- Comment #6 from RazvanN <razvan.nitu1305@gmail.com> --- I don't see anything actionable on the compiler part here. Perhaps this a job for 3rd party tools. -- |
April 18, 2023 [Issue 19819] __FILE__ might emit personally identifiable information in release executable | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=19819 --- Comment #7 from Lionello Lunesu <lio+bugzilla@lunesu.com> --- I don't agree. Golang has added `-trimpath` to address the same issue: https://go.dev/src/cmd/go/testdata/script/build_trimpath.txt -- |
Copyright © 1999-2021 by the D Language Foundation