On Thu, Nov 16, 2023 at 3:26 AM Ben Boeckel <ben.boeckel_at_[hidden]> wrote:

> On Wed, Nov 15, 2023 at 21:09:53 +0200, Ville Voutilainen via SG15 wrote:
> > I took a look, blanking source information provided by the builtins
> > (that are also used by source_location in general)
> > based on a command-line flag seems like a flick of the wrist to do. I
> > can do that
> > for the natural syntax implementation if people want to play with it.
> >
> > Blanking the source information provided by __FILE__, __LINE__ and
> > __func__ takes more than a flick of the wrist,
> > mostly because I'm not familiar with GCC's preprocessor
> > implementation. I don't suppose there's anything insurmountable
> > in it, tho.
>
> Note that the compiler can inject source paths via other mechanisms
> (e.g., debug info, though this is trivially stripped today with `strip`)
> or via the linker (e.g., object names in static libraries tend to
> correlate with their source filenames).


I believe those are thrown out by the linker after it consumes them,
otherwise MSVC would have had no need to invent pdb files. MSVC allows you
to throw out the symbols, put them in pdb's or keep them in the binary, but
it's definitely under user control.


> The idea behind tooling's vote
> (as I understand it) is to say something along the lines of "there exist
> sources of de-anonymizing strings from various sources, so let's just
> Solve The Problem™ and provide guidance" along the lines of:
>
> 1) detecting such information (including common sources or places it
> gets squirreled away)
> a) this includes deterministic derived IDs like `NT_GNU_BUILD_ID`
> where it would allow an adversary to see that some artifact is the
> same as another deployment
> b) embedded timestamps
> c) etc.
> 2) describing what tools can do to resolve this problem
> a) blanking strings and replacing line/column info with `0`
> b) ID replacement with an output of a lookup from ID to string so that
> reported errors can be more easily useful
> c) something else I haven't thought of
>
> These things are certainly outside of the (language) standard and while
> providing mechanisms for language-sourced bits of information like this
> *can* be done, I don't think it is Solving The Problem™, but instead
> more along the lines of addressing a symptom.
>

They may be outside the language standard, but I believe language experts
will still have to weigh in as to their impacts. There may soon be 2
standards, but it's still a (hopefully...) single language.

>
> Of course, SG21 can do whatever it wants with source_location use in
> contract violation handlers, but I got the sense that SG23 is also more
> interested in Solving Problems™ than addressing every instance of a
> problem throughout the standard (e.g., see discussion of P2951
> addressing one pattern of aliasing causing trouble feeling like (to me
> at least) using paper to plug a hole in a dam[1]).
>
> --Ben
>
> [1] And afterwards it occurred to me that we just need a scoped "pragma
> poison" to do as well as the proposed shadowing.
>