Re: Fixing security vulnerabilities before new releases

>> > so we could introduce an `intern--without-shorthands` and replace the
>> > few `intern` calls we see as risky.
>> SGTM.  Should I prepare a patch, or leave it you?
> I don't think we can install such changes on the emacs-31 branch at
> this time, sorry.

Given the severity of the security hole, what kind of change would you
consider acceptable?
E.g. is Eshel's `vc-hooks.el` patch acceptable?

BTW, w.r.t mitigation, maybe we could install a patch like the
one below?


=== Stefan


diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index c293789cee3..b35c285771b 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -2888,7 +2888,24 @@ elisp-byte-compile-buffer
           (delete-file elc))))))
 
 
-(put 'read-symbol-shorthands 'safe-local-variable #'consp)
+(put 'read-symbol-shorthands 'safe-local-variable
+     ;; FIXME: In Emacs-32, `read-symbol-shorthands' is inherently much
+     ;; safer because we don't use it for all calls to `intern' any more.
+     ;; In the mean time, try and make it harder to exploit holes.
+     (lambda (shorthands)
+       (with-demoted-errors "%S"
+         ;; By definition shorthands are supposed to be ...well... shorter,
+         ;; so make sure that's indeed the case.  Also superficial inspection
+         ;; of packages "out there" suggests that in practice shorthands
+         ;; are not just shorter but significantly so, more specifically
+         ;; less than half the size of their longhand, so strengthen
+         ;; the test accordingly.
+         ;; FIXME: Would it also make sense to restrict shorthands to end
+         ;; in some kind of "delimiter" (non-letter)?
+         (all (lambda (sh)
+                (<= (* 2 (length (car sh))) (length (cdr sh))))
+              shorthands))))
 
 (provide 'elisp-mode)
 ;;; elisp-mode.el ends here