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.

--

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.

--

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?

--

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.

--

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__

--

https://issues.dlang.org/show_bug.cgi?id=19819

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

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

--

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.

--

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

--