Quote https://trojansource.codes
source code at the encoding level.
while semantically correct, diverges from the logic presented by the
logical ordering of source code tokens.
code, not the visual order.

- > Compilers, interpreters, and build pipelines supporting Unicode
should throw errors or warnings for unterminated bidirectional control
characters in comments or string literals, and for identifiers with
mixed-script confusable characters.

- > Language specifications should formally disallow unterminated
bidirectional control characters in comments and string literals.

- > Code editors and repository frontends should make bidirectional
control characters and mixed-script confusable characters perceptible
with visual symbols or warnings.

additional ideas to protect from this:

- **check if potential existing compromises:** scan all source code for
existing unicode

- **educate existing and future source code reviewers:** add a source
code reviewer policy which existing and future reviewers need to
acknowledge that they understand the issue.

- **remove as much unicode from source code as possible**: by reducing
the amount of unicode in source code, audits for malicious unicode with
automated tools gets simpler. If possible, if unicode is considered
essential, instead of writing `®` when required it should be encoded as
`®`.

- **local check by reviewer:** document tools that source code reviewers
could/should use to scan future contributions for malicious unicode

- **lintian check:** a lintian test that notifies when unicode is
included in the source code.

- **build scripts / CI scripts:** should check if there is unicode in
any files except in opt-in expected files defines in a list. If there is
any unexpected unicode in unexpected files, the build should error out.

- **scan upstream projects source code**: check if these are compromised
by malicious unicode.

- **notify upstream projects**: these might not be aware of this issue
and already compromised by malicious unicode.

how to check example:

grep_args="--exclude=changelog.upstream --exclude-dir=.git
--binary-files=without-match --recursive --color=auto -P -n"

LC_ALL=C grep $grep_args '[^\x00-\x7F]'

LC_ALL=C grep $grep_args "[^[:ascii:]]"

A few other tools might be desirable in case grep can ever be tricked to
miss anything.

Your text is quite chaotic, it is hard to distinguish the quotes from
your ideas what to do in Debian.

I think the main problem here are the programs which are presenting
source code to humans (text editors, terminals, HTML pages in Gitlab
etc.).
Quotes should always terminate everything. A control character within a
string literal should not have any effect outside of the quotes. The
rules should be similar as we know them from syntax highlighting. All
directional instructions should be terminated by the closing quote.

However, since it is not realistic to free all relevant tools from all
related bugs soon, compiler warnings make sense.
There I think it does not make sense to ban all Unicode. Unicode
clearly distinguishes printable and non-printable characters and so on.
So all characters that print something clearly visible can be
whitelisted.

Regards

Hi,


This email will close this way too broad bugreport.
Having this BR closed will prevent further drain of human energy.

Those who think "but it important" do I recomment
to take smaller steps in going forward.


Regards
Geert Stappers
DD
--
Silence is hard to parse