The issue in the tooling study group is about what to advise about. There's
no specific tooling standard for compiling artifacts. Also, the contracts
papers don't seem to have much discussion about tooling support for
building code with contracts (but maybe I'm out of the loop?). Given all
that, I don't see how to incorporate security hardening into workflows that
build programs that define contracts.

The concern about making programs more susceptible to attacks seems
reasonable. They were definitely well-presented! But we don't really have a
vehicle for addressing that concern from a tooling perspective.

Absent that vehicle, it probably makes sense for relevant stakeholders to
invest in ways to harden binaries in implementation defined ways, such as
altering binaries after they are built. Case study papers about that
process would be well received by the tooling study group. Possibly some
technical reports or ecosystem standards could be developed to improve
understanding and support for these issues.

Bret

On Mon, Nov 13, 2023, 14:16 Timur Doumler via SG15 <sg15_at_[hidden]>
wrote:

> Hi,
>
> On 13 Nov 2023, at 17:30, Ran Regev via SG15 <sg15_at_[hidden]>
> wrote:
>
> On Mon, Nov 13, 2023, 17:19 Joshua Berne <berne_at_[hidden]> wrote:
>
>> SG15 and SG23 both discussed P2947 last week. Has there been new
>> information published to indicate that it needs to be revisited?
>>
>
> I'm not aware of such information. I have read the minutes from both
> discussions.
>
> When the authors of P2947 approached SG21 initially, I deferred to SG23
> and said that SG21 will look at this if (and only if) SG23 considers this a
> security issue that needs to be fixed in the language spec. SG23 clearly
> does not consider this to be a security issue that needs to be fixed in the
> language spec. They deferred it to SG15, who do not consider this to be an
> issue that needs to be fixed in the language spec either. So they deferred
> it to us, which means the cycle is complete and we're back where we started.
>
> I think it should at least be discussed within SG21 as SG15 suggested:
> https://wiki.edg.com/bin/view/Wg21kona2023/SG15P2947.
>
>
> Sure, if the authors insist, SG21 can discuss this paper. But honestly —
> and I mean this with all due respect — I don't think such a discussion
> would be a particularly good use of anybody's time.
>
> SG21 does not specialise in security issues; nor do we specialise in
> tooling issues. We do language design. If SG23 does not consider this to be
> a security issue that needs to be fixed in the language spec, and SG15 does
> not consider this to be a tooling issue that needs to be fixed in the
> language spec, then all that's left for us to do in SG21 is to discuss
> whether the proposed change nevertheless makes sense from a language design
> perspective. I have a pretty good idea where such a discussion would go.
>
> Please let me know if you disagree with the above!
>
> Cheers,
> Timur
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>