Was it only 29.2 that introduced these bugs, or are earlier Emacs versions also vulnerable? Some still-current Linux distributions (particularly “enterprise” ones) are packaging Emacs 28 or 27. But I don’t think GNU generally makes maintenance releases of older versions.

Morris worm?

I'm grateful that the Emacs team takes these sort of issues seriously.

There's always going to be a temptation to enable arbitrary code execution inside your editor, because that's "the easy way" to do lots of useful and powerful things. I'm grateful that Emacs, in general, works to avoid that temptation, and to provide sophisticated editing capabilities "the hard way".

(I cringe when I see somebody using an editor that prompts them to "trust this project" to enable advanced features. I suspect that often means "trust everything that ever gets pulled into the present git repository." Obviously trust your own code, but most of us no longer live in a world where the only code we're reading or editing is our own.)

Yes, Emacs has the option to trust "safe values of risky local variables", but those are sensibly tracked per-value, not per-variable or per-directory or per-project. (Which means that users and Lisp developers are encouraged to use even risky variables in limited, safe ways.)

Until now, Emacs hasn't had an "untrusted-content" variable. The answer was always (and should be) "t".

I don't use Org mode regularly, and I'm not familiar with the features in question here. But the "evaluate Lisp on export" feature looks a little sketchy (I guess you can assume people will only ever export a document they wrote themselves?) And the "LaTeX preview" feature looks *quite* sketchy. It's not just a matter of "might generate huge PDF files" - LaTeX is an actual programming language, y'know?