LTR语言中的双向字符发布安全修复

支持
1

我刚刚遇到了以下 PR：

我认为这可能会使合法的希伯来语或阿拉伯语文本变得无法阅读。

我遇到的解决方案之一是禁用 unicode 算法，只显示非打印字符的某种表示形式（我认为它是在 Pootle 中实现的）。
所以基本上这个想法是将：
This‎‏ text

变成：
This\\u003cLRM\u003e\\u003cRLM\u003e text

这样用户就可以通过了解实际字符是什么来选择这是否是恶意的，并可能选择启用 unicode 算法以能够正确阅读文本。
谢谢。

3 个赞
3

感谢您提出这个问题，我们已经考虑到了这个顾虑。您在 OP 中链接的修复程序仅适用于 pre 和 code 块中的 Unicode 双向字符，无论是手动编写的 HTML 还是由 <code>```</code></code> markdown 围栏代码块生成的，因此它不应影响组合帖子中的常规希伯来语或阿拉伯语文本。

2 个赞
7

演示：

#include <cstdio.h>

int main() {
    /* Say hello; newline<U+2067> /*/ return 0 ;
    printf("Hello world.\n");
    return 0;
}

#include 

int main() {
    /* Say hello; newline<U+2067> /*/ return 0 ;
    printf("Hello world.\n");
    return 0;
}

测试：‫"שלום חבר" - Hello Friend

无双向文本
测试：“שלום חבר” - Hello Friend

Markdown：

测试：&#x202B;"שלום חבר" - Hello Friend

无双向文本

测试："שלום חבר" - Hello Friend

这算不上最好的例子，但你应该能明白我的意思，它只影响发布在论坛上的源代码。源代码中的双向文本字符通常是不使用的。

5 个赞
8

我将举另一个例子，其中 RLM 不会打断句子。

שלום לכולם ובמיוחד ל־Sam, Martin בחר לעזוב אותנו.

שלום לכולם ובמיוחד ל־Sam,‏ Martin בחר לעזוב אותנו.

你看到区别了吗？
唯一的改变是 RLM，我想祝贺 Sam 并告知 Martin 要离开了（没有冒犯）。

3 个赞
9

是的，那个例子确实好多了！正如你所见，它仍然在工作，并且不受安全修复的影响 :tada:

4 个赞
10

嗯，它不是代码块 :slight_smile:
我的意思是，在代码块中它不会按预期显示（这正是修复的重点，对吧？）

1 个赞
11

是的，但你为什么要把它包含在代码块中？

2 个赞
12

来自 gettext 的摘录，希伯来语/阿拉伯语原生字符串，存在这种情况。

2 个赞
13

我希望这里的异常情况有变通方法（截图、附件上传等），而且特殊字符已到位。

https://trojansource.codes/ 的风险高于极端异常情况下的轻微干扰风险。

3 个赞
14

但是我的建议会因为一些提示符而破坏句子，所以用 <RLM> 或 <LRM> 替换 RLM 和 LRM 将向用户显示存在一些额外的字符，而现在文本已在没有这些字符的情况下呈现，同时告知这可能会破坏体验，并且如果需要，可以选择手动替换回来，完全删除字符而没有任何指示，则没有留下做出明智决定的余地。

而且，正如您提到的，它还将防止特洛伊木马源代码，因为用户将能够看到带有指示符的恶意代码。

我将尝试从 Pootle 获取一些截图，我不记得在过去几年里看到过那个原始字符串选项，在我们开始修复 LibreOffice 本地化时，它非常有用。

2 个赞
15

不遵循，我们不剥离，我们替换，请看我上面的例子

3 个赞
16

我明白了，用他们的名字而不是 Unicode 实体会不会更好？

1 个赞
17

如果在实际使用中反复出现混淆，我们可以进行微调。

3 个赞
18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.