C++ Logo

sg16

Advanced search

Concerning - C/C++ Identifier Security using Unicode Standard Annex 39

From: Corentin <corentin.jabot_at_[hidden]>
Date: Wed, 19 Jan 2022 11:40:17 +0100
Hello,

Concerning your request here
https://github.com/sg16-unicode/sg16/issues/48#issuecomment-1014698519

For WG21, please follow the procedure here
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers

Adding Aaron Ballman who can help you with the WG14 side of things.

---
It might be best to synchronize with SG16 (unicode study group) as
suggested by Tom before going to the C committee though.
Note that C++ already accepted P1949 and is reaching design freeze - but
your paper can be considered a bug fix if accepted.
C is less advanced with their paper
<https://www9.open-std.org/JTC1/SC22/WG14/www/docs/n2836.pdf>, but they are
also reaching design freeze, and we are trying to keep both languages in
sync.
----
Concerning your paper, both committees need to decide whether
security considerations
should be part of the standard, rather than being
quality-of-implementation, hopefully come with a consistent answer.
>From there the paper can be refined and... you will need specification
wording, which is likely to be different for both languages.
I hope that helps with the organization side of things.
---
Now, for my unsolicited opinions:
Great paper!
However, I'm afraid security considerations are a moving target and keeping
them as warnings/QoI avoid a huge burden on the committee(s) while granting
more flexibility to implementers.
In particular the set allowed/disallowed/recommended scripts is likely to
be unstable.
I expect more research to come out of the unicode consortium in the coming
months in regard to security/confusable/bidi attacks.
A big selling point of UAX31/P1949 is that it avoids a huge burden on 2
slow moving standard bodies (who have limited Unicode expertise and even
less expertise with the impact on specific affected scripts).
This is the approach chosen by other languages, notably rust:
confusable detection is implemented but not part of the spec.
Furthermore the same attack vectors exist for string literals, where
standards are even less the right place for these restrictions.
Maybe other folks will have very different ideas.
I hope this helps,
Regard,
Corentin Jabot

Received on 2022-01-19 10:40:29