Caratteri bidirezionali nelle lingue LTR postano fix di sicurezza

Supporto
1

Mi sono appena imbattuto nel seguente PR:

Penso che possa rendere il testo ebraico o arabo legittimo illeggibile.

Una delle soluzioni che ho trovato è stata disabilitare gli algoritmi Unicode e visualizzare semplicemente una rappresentazione dei caratteri non stampabili (penso che fosse implementato in Pootle).
Quindi, fondamentalmente, l’idea è di trasformare:
Questo‎‏ testo

In:
Questo\\u003cLRM\u003e\\u003cRLM\u003e testo

In questo modo l’utente può scegliere se questo è dannoso o meno comprendendo quali sono i caratteri effettivi e possibilmente scegliere di abilitare gli algoritmi Unicode per poter leggere correttamente il testo.
Grazie.

3

Grazie per aver sollevato questo problema, avevamo pensato a questa preoccupazione. La correzione che hai collegato nell’OP si applica solo ai caratteri bidirezionali Unicode nei blocchi pre e code, scritti manualmente come HTML o generati da blocchi di codice delimitati da markdown \u003ccode\u003e```\u003c/code\u003e, quindi non dovrebbe essere un problema con il testo ebraico o arabo normale in un post composto.

7

Demo:

#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;
}

Test: “שלום חבר” - Hello Friend

Senza BIDI

Test: “שלום חבר” - Hello Friend

Markdown:

Test: "שלום חבר" - Hello Friend

Senza BIDI

Test: "שלום חבר" - Hello Friend

Non è il miglior esempio del mondo, ma dovresti capire il concetto qui, influisce solo sul codice sorgente pubblicato sul forum. I caratteri Bidi nel codice sorgente non sono qualcosa che di solito viene fatto.

8

Ti darò un altro esempio in cui nessun RLM interrompe la frase.

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

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

Vedi la differenza? L’unica modifica è RLM, volevo congratularmi con Sam e informare che Martin se ne va (senza offesa).

9

Sì, quell’esempio è decisamente molto meglio! Come puoi vedere continua a funzionare e non è influenzato dalla correzione di sicurezza :tada:

10

Hmmm, non è un blocco di codice :slight_smile:
Intendevo dire che all’interno di un blocco di codice non apparirà come previsto (è proprio di questo che si tratta la correzione, giusto?)

11

Sì, ma perché dovresti includerlo in un blocco di codice?

12

Estratto da gettext, stringhe native ebraiche/arabe, ci sono tali casi.

13

Il caso anomalo qui avrebbe delle soluzioni alternative (screenshot, caricamenti di allegati e così via), inoltre è abbastanza chiaro che il carattere speciale è presente.

Il rischio di https://trojansource.codes/ è superiore al rischio di lievi interruzioni in casi estremi anomali.

14

Ma il mio suggerimento interrompe la frase con alcuni indizi, quindi sostituire RLM e LRM con <RLM> o <LRM> mostrerà all’utente che c’erano caratteri aggiuntivi e ora il testo viene visualizzato senza di essi, informando comunque che potrebbe interrompere l’esperienza e che esiste un’opzione per ripristinarli manualmente, se necessario, rimuovere completamente i caratteri senza alcuni indicatori non lascia spazio a decisioni informate.

E impedirà anche il codice sorgente trojan come hai menzionato perché l’utente sarà in grado di vedere il codice dannoso con gli indicatori.

Cercherò di ottenere alcuni screenshot da Pootle, non ricordo di aver visto quell’opzione di stringhe raw negli ultimi due anni, è stata molto utile quando abbiamo iniziato a correggere la localizzazione di LibreOffice.

15

Non seguo, non rimuoviamo ma sostituiamo, vedi il mio esempio sopra

16

Capisco, non sarebbe meglio usare i loro nomi invece delle entità Unicode?

17

Se c’è confusione ripetuta segnalata nell’uso reale, possiamo certamente affinare