Emacs 31 blockers listed as file-open RCE sparks release fight

Sean Whitton has posted the open bugs he believes must be fixed or explicitly deferred before Emacs can cut a 31 release candidate. The list covers the usual pre-release mix: package.el regressions, macOS and Android build failures, display glitches, tree-sitter quirks, and assorted crashes.

One item outside that list has become the real argument. Bug 80574 is an arbitrary code execution flaw that makes opening a crafted file unsafe. It already affects Emacs 30. Eshel Yaron called it a release blocker, arguing that a new major version invites fresh installs and that shipping another vulnerable build would delay a fix users actually need. Óscar Fuentes backed him, calling the hole very serious and warning that a known, easily exploited vulnerability in a fresh release would damage Emacs's reputation as a serious project.

Whitton initially disagreed. Because the bug is already in the wild on 30, he said releasing 31 does not make the situation worse; a point release can follow once a solid fix lands. Yaron replied that "not worse" is the wrong bar: the project should aim to make things better, and a simple temporary mitigation would be enough for 31 if a full redesign takes longer.

Stefan Monnier has since pushed mitigations on the development trunk. The emacs-31 branch remains exposed. Whitton invited a backport. Separately, Michael Albinus opened Debbugs tracking bug 81521 so the remaining blockers can be managed with the project's formal release-blocking machinery, and several lesser items are already being dropped as non-regressions or too narrow to hold the train.