On Tue, Jan 25, 2022 at 11:13 AM Tom Honermann via SG16
<sg16_at_[hidden]> wrote:
>
> On 1/25/22 3:13 AM, Corentin Jabot via SG16 wrote:
>
>
>
> On Tue, Jan 25, 2022, 08:20 Ville Voutilainen via SG16 <sg16_at_[hidden]> wrote:
>>
>> On Tue, 25 Jan 2022 at 08:38, Reini Urban via SG16
>> <sg16_at_[hidden]> wrote:
>> >> Thank you, Reini. I will get these scheduled for review in SG16. Please note that we are now beyond the deadline for new papers for C23 and C++23, so review will be directed towards later standards. Our immediate priority is to finalize features that have been accepted for C++23. As a result, it may be a few months before these papers get scheduled in SG16. Though an argument could be made that your proposal constitutes modification of a feature accepted for C++23 (P1949) and therefore in scope for that standard, I see your proposal as more of a competing one rather than a modification. P1949 effectively brought the standard up to date with more recent Unicode versions without changing the design intent; the changes you propose are a change in direction and more disruptive.
>> >
>> >
>> > In my point of view is that C11 made identifiers insecure by making them non-identifiable, and adopting TR39 will fix that spec bug. So a bugfix, not a feature.
>>
>> At any rate, going into C++23 with P1949 and then looking at this
>> proposal later would mean that we have a breaking change
>> in our hands. If we go with this proposal, we can relax the
>> identifiers if we decide (again, tho, I might add) that we're not
>> concerned (*) about
>> bidi/homoglyph attacks.
>>
>> (*) Or, rather, that we leave that to Quality of Implementation and
>> external tools, I guess.
>>
>> But still, the high-order bit, to me, seems to be that if we go with
>> P1949 for C++23, the horses are out of the barn and the cats are out
>> of the bag. Taking a step back and going with what's proposed here
>> after C++23 has been published seems.. ..awkward. I would
>> find the hypothetical reverse order much less awkward, or even just
>> sticking with what's being proposed here.
>>
>> I must wonder, tho, whether the cats are already out of the bag,
>> considering that gcc and clang already allow all sorts of identifiers
>> and gcc has that bidi warning. Seems like we're damned if we do,
>> damned if we don't.
>
>
> There is no way that we can accommodate both stability and safety simultaneously for any Unicode related things, nor can we react fast enough to security concerns. In fact there have been a lot of developments in the last few weeks alone.
>
> Now, these security concerns are both important, and to handle with care as... It's easy to preclude legitimate use cases.
>
> We need as an industry to:
> * Understand where the diagnostic needs to be produced (ide, compilers, code review tools...)
> * Find the right way to handle security without excluding legitimate use cases, and a lot of that will come from the Unicode consortium
> * Have some flexibility to adapt to new best practices
>
> I don't think the C++ standard is the place to try to solve these matters, but we could (should?) offer some recommendations.
>
> I think this is a point worth further discussion. For example, addressing these matters via MISRA and other such compliance standards may be preferred; perhaps as a starting point for eventual standardization.
>
> The standard could (I think) also provide normative encouragement to implementors to emit a diagnostic for identifiers that are not inline with TR39 guidance. I'm not sure if we already have examples of encouragement for additional diagnostics elsewhere.

FWIW, WG14 uses the "Recommended Practice" ISO words of power to give
such recommendations, and WG21 has recently followed suit:
http://eel.is/c++draft/dcl.attr.deprecated#4. So there is some
precedent for providing normative encouragement for diagnostics, but I
don't know whether this particular topic rises to the same level of
need.

~Aaron

>
> Tom.
>
>
> But long cycles and a desire to provide more stability than Unicode guarantees, as well as limited bandwidth, makes me think this is ultimately a QoI concern.
>
> Anyway, P1949 is a breaking change, this is another breaking change. P1949 was designed to guarantee stability over time but security consideration on top won't. So maybe which cycle this gets in doesn't matter terribly, except that we should either consider security matters swiftly, or recognize that we are not the right body to deal with that.
>
> I mentioned somewhere else that the rust compiler does confusable detection yet the spec only mentions UAX.
>
> For me the question is: does the sudden interest for Unicode related security matters invalidates p1949's initial analysis that confusable detection is better left in the hands of implementations?
>
>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16