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.

Tom.

>
> Cheers,
> Timur
>
>> On 13 Nov 2023, at 22:56, Bret Brown <mail_at_[hidden]> wrote:
>>
>> 
>> 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
>>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15