The feedback from SG15 was that this is a QoI issue. We had representants
from implementers in the meeting and the overall feedback was that this opt
out is going to be supported regardless of what the spec says.

We also welcomed the contribution of an overall report about binary
anonymization, which could likely be published as a TR, that should cover
aspects beyond contracts, to identify areas where implementers could do
more than what they're already doing today.

In other words, SG15 didn't feel that the language spec is the only
mechanism to address this kind of concern.

If the spec allows for the anonymization, that's enough space for tooling
to do the right thing.

Daniel

On Wed, Nov 15, 2023, 08:10 Andrei Zissu via SG15 <sg15_at_[hidden]>
wrote:

> On Tue, Nov 14, 2023 at 7:05 PM Ville Voutilainen via SG21 <
> sg21_at_[hidden]> wrote:
>
>> On Tue, 14 Nov 2023 at 18:36, Tom Honermann via SG15
>> <sg15_at_[hidden]> wrote:
>> >
>> > On 11/13/23 4:59 PM, Timur Doumler via SG15 wrote:
>> >
>> > Thanks for the summary, Bret!
>> >
>> > I totally agree that the concern seems reasonable but there doesn't
>> seem to be an appropriate ship vehicle at the moment. Addressing the
>> problem via the language spec seems like the wrong direction, and
>> addressing it via the language spec in just one specific feature like
>> Contracts seems like doubly the wrong direction, which is exactly why I
>> believe this would go nowhere in SG21 (and not because the concern is
>> unreasonable). Hope that makes sense.
>> >
>> > I agree that the language specification is the wrong place to address
>> this with the exception that the language spec has to permit omitting the
>> information (which is already the case).
>> >
>> > If there was a desire to do anything about this, I think the right ship
>> vehicle is the ecosystem IS; we could have a section that discusses removal
>> of sensitive information. I have no strong opinions about pursuing that
>> though.
>>
>> I don't find it troublesome to specify such information-scrubbing in
>> the language spec. I would, however, expect that it's not handled
>> as a requirement for a contracts facility, but with a proposal of its
>> own that handles contract violation information, source_location in
>> general,
>> and __FILE__ and __LINE__ and __func__ in a coherent package. Or
>> explains why it doesn't.
>>
>
> Either way I would indeed prefer this to be in the language spec rather
> than in the tooling ecosystem, due to my understanding (am I wrong?) that
> the latter option would imply a "scrubbing" mechanism, as in preparing the
> final binary and then running an additional (possibly non-standard?) tool
> that would remove this information. This feels to me both awkward (why not
> just refrain from putting the sensitive texts in there to begin with during
> compilation?) and harder to do, since the final binary might lack the
> contextual information necessary for safely and efficiently determining
> what is to be removed.
>
> Our original intention was just to drive a small fix into P2811 itself,
> out of our concern that:
>
> 1. A contracts MVP without this opt out might create an
> unfavorable reputation for contracts and hamper their adoption, which may
> be hard to bounce back from later.
> 2. Whether real or just perceived (by the wider C++ community), the
> mentioned risk is greatly enhanced with contracts.
>
> This means we would like to see a quick fix, ideally baked straight into
> the contracts MVP. We could go for the bigger effort (and I'm not ruling
> it out), but that's an all or nothing scenario which might end up with
> contracts in C++26 without the fix we're advocating for. And besides,
> wouldn't the macros you mentioned also require the extra step of
> coordinating such a change with WG14?
>
> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>> Link to this post: http://lists.isocpp.org/sg21/2023/11/5534.php
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>