Bug 19819 – __FILE__ might emit personally identifiable information in release executable

Very trivial example: // test.d void main() { import std.stdio; writeln(__FILE__); } Whatever path is provided to the compiler is emitted as a string literal: $ dmd -run test.d test.d $ dmd -run /Users/lio/repos/d/dmd/test.d /Users/lio/repos/d/dmd/test.d This is as expected, but often the compiler is invoked by a build tool, like `dub`, and absolute paths are passed to the command line instead, resulting in leaking of the local path names which might include the username (or other secrets like project codename or customer name.) Note that these string literals are emitted for release builds as they are often passed to Exception constructors. $ strings test | grep '\.d$' | sort | uniq ./generated/osx/release/64/../../../../../phobos/std/stdio.d /Users/llunesu/repos/d/dmd/test.d src/core/demangle.d src/core/exception.d src/core/internal/parseoptions.d src/core/internal/string.d src/core/sync/mutex.d src/core/thread.d src/core/time.d src/gc/proxy.d src/object.d src/rt/lifetime.d src/rt/minfo.d std/algorithm/searching.d std/array.d std/conv.d std/format.d std/internal/cstring.d std/range/primitives.d std/stdio.d std/uni.d std/utf.d

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.

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.

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?

(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.

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__

I don't see anything actionable on the compiler part here. Perhaps this a job for 3rd party tools.

I don't agree. Golang has added `-trimpath` to address the same issue: https://go.dev/src/cmd/go/testdata/script/build_trimpath.txt