Thank you, JF. Copying SG16 and the author of P2538R0 (C++ Identifier Security using Unicode Standard Annex 39).

This effort has implications for future work on P2538R0; we'll want to ensure that any such efforts are consistent with the guidance and work eventually produced by this new Unicode Consortium group.

Tom.

On 3/2/22 6:32 PM, JF Bastien via Ssrg wrote:
Related to the recent paper discussion. 

---------- Forwarded message ---------
From: announcements via announcements <announcements@corp.unicode.org>
Date: Thu, Mar 3, 2022 at 8:03 AM
Subject: Avoiding Source Code Spoofing
To: <announcements@corp.unicode.org>
CC: announcements <announcements@corp.unicode.org>


[board
                  image]Unicode has convened a group of experts in programming languages, tooling, and security to provide guidance and recommendations on how to better handle international text in source code, as well as providing code to help implementations.

Recent reports have highlighted problems in the review of source code containing non-ASCII Unicode characters (the so-called “Trojan Source exploit”). A person reviewing a submission of source code could be fooled into thinking that the code was okay, when it was actually malicious. The basic problem occurs when the actual text is different from what the reader perceives it to be, based on what is displayed. This can result either from the presence of characters used in right-to-left scripts (such as Arabic or Hebrew) that can change the visual ordering of text, or from the presence of characters that look like others (also known as “confusables”).

The problems here are not solely a security issue: text with different writing directions or confusable characters can be hard to work with. Finding a solution here is important from both security and usability points of view. Developers of source code editors or compilers should not be required to have a deep knowledge of Unicode to provide good user experience and robust security mitigations.

Unicode’s mission is to allow everyone to use their own languages on computers and mobile devices. The above issues are part and parcel of a character set that covers all the writing systems of the world – and have been documented in the Unicode Standard since its very first version in 1991. Unicode’s past efforts have focused on misleading URLs and identifiers, and correct visual ordering of plain text. And while much of this material is relevant to source code, this group of experts will now collect, curate, and supplement that early documentation with concrete recommendations to support source code editors and compilers.

While it may seem that it is easiest to simply go back to limiting source code to only ASCII characters, ASCII-only environments make it much harder to write and maintain software that can be used all over the world – a fundamental requirement for modern software. Moreover, this approach disadvantages software developers who use languages other than English.

More details on the source code spoofing issue, the proposed plan, and formation of this group are found in document L2/22-007R2.


Over 144,000 characters are available for adoption to help the Unicode Consortium’s work on digitally disadvantaged languages

[badge]

http://blog.unicode.org/2022/03/avoiding-source-code-spoofing.html