Re: Trojan Source detection/highlight in Emacs?

[Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>]

>> Clearly, Eli will know better, but I suspect that we may be able to
>> avoid most of those issues by (conceptually) treating comment delimiters
>> as bidi barriers.  Of course, that leaves open the question of what
>> I mean by "bidi barrier" and of how to implement it ;-)
>
> It's more than that: bidi reordering happens on a very low level in
> the display engine, where there's absolutely no information about
> stuff like comment delimiters and PL syntax in general.  In
> particular, that code runs before font-lock and similar features
> examined the text syntactically and decided what is and what isn't a
> comment.

That's the "how to implement it" part, yes.  BTW, I don't think it's the
case that bidi reordering is done "before font-lock and similar features
examined the text" (bidi reordering applies to text rendering and
font-lock faces are applied before the buffer's text is rendered).

> We could instead provide an ability to bidi-reorder only certain
> stretches of text, marked by some special text property.  Then a Lisp
> program could mark only comments and strings with that property, and
> the reordering would not happen anywhere else in the buffer.

If we don't want to allow properly rendered Hebrew identifiers, then
it's indeed a great solution.  It would be pretty easy to make font-lock
add a special `bidi-enable` text property to strings and comments.

> Doing something like that is relatively simple, but not too simple, so
> I'd say this particular issue doesn't justify the effort.

I suspect none of the solutions are "too simple" to implement.
But I don't think we should rush to implement something, since there are
several ways to attack this problem, and it's probably worth thinking
a bit more about the full extent of the problem (after all, it's mostly
a problem of security, where we hence should assume the attacker will be
clever enough to try and circumvent the simple measures we may come up
with).

> I would start with detecting such reordered code and flagging it.

Indeed, another approach is to render it "normally" and then flag those
places where the rendering may mislead the reader, which could also
include the confusables.

A simple and straightforward way to do that is to highlight any
non-ASCII char, and to render all the "non printing" chars (such as
RIGHT-TO-LEFT OVERRIDE) as tofu or something like that (otherwise, the
highlighting applied to it wouldn't be visible).


        Stefan