“CVE”2021-42694 根本不影响代码。它会影响人类用于审查代码和提议的代码更改的系统——即花哨的文本编辑器/IDE、GitHub 拉取请求和代码审查工作流等。这是盲目地将UTR #9应用于整个代码体的结果/patch作为单个上下文，而不是以特定于应用程序（在此上下文中，特定于编程语言）的方式“解析嵌入级别”，因此不允许嵌入/覆盖控件对不同上下文施加格式影响（注释块，引用的字符串等）或根本不尊重嵌入/覆盖控制字符。

关键问题当然不在Unicode 规范到 14.0 的字符定义中。事实上，Unicode 委员会提供了足够的方法来修复此类攻击，至少是对标识符的 homoglpygh 和欺骗攻击。有 TR31、TR36 和 esp。提供建议的 TR39。这是自 2000 年以来发布的，几乎没有人遵循这些安全建议。

问题是标识符是不可识别的。这发生在代码中，但也发生在对象文件中，因为它们确实具有 ABI 和 API，例如标头、FFI、链接器访问、缺少检查的工具。

主要问题在于所有语言委员会和实施者，他们在没有任何安全措施的情况下快速实施对标识符的 unicode 支持。唯一安全的语言是拒绝的语言（zig 和 J），以及遵循 TR39 的语言：Java、cperl 和 Rust。其他 100 个人在设计上都是易受攻击的。现在甚至 gcc-10 也提供了这些不安全感。我在https://github.com/rurban/libu8ident/blob/master/c11.md上对各种语言和编译器的不安全性进行了概述

对于 C23++ 标准的固定版本。但是，当我在 2016 年为 perl5 执行此操作时，他们并不在意，所以只有我的 fork cperl 是安全的。Rust 确实在那段时间倾听并提供了适当的 unicode 安全性。

无论如何，现在我有一个可以用来实现它的 C 库，以及一个可以检查的 linter。我还在尝试使用改进的readelf -L -Ul检查器来查找库中现有的 unicode 安全问题。显示 utf-8 的 readelf 很糟糕。这需要进一步改进以更好地显示 unicode 问题。比如最近在github上。有关 readelf 补丁，请参见我的 github。

顺便说一句：另一个愤世嫉俗的解决方法是将标识符重命名为语言规范中的符号。因为符号不需要是可识别的。它们只是与文件名相同的二进制垃圾。当然，文件系统和登录系统（数据库，如 ldap 和 passwd）也需要修复。