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