GNU bug report logs - #78542
[Security] hash locking needed for tree-sitter downloads

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [Security] hash locking needed for tree-sitter downloads
Date: Wed, 21 May 2025 15:12:32 -0400

When downloading code, a tag isn't good enough.  We should insist on a
specific commit.

We have a fair bit of code in Emacs that looks like this:

(add-to-list
 'treesit-language-source-alist
 '(javascript "https://github.com/tree-sitter/tree-sitter-javascript" "v0.23.1")
 t)
(add-to-list
 'treesit-language-source-alist
 '(jsdoc "https://github.com/tree-sitter/tree-sitter-jsdoc" "v0.23.2")
 t)

The entries in treesit-language-source-alist mostly have tags but not
commit hashes.  The expected commit hash should be *mandatory*, because
right now, anyone with access to one of these repositories can retarget
any of those tags at malicious code.

See https://snyk.io/blog/npm-security-preventing-supply-chain-attacks/

Every other important language ecosystem has evolved some kind of "hash
locking" capability for breaking the author-retargets-to-malware attack
vector.  We should too.  We shouldn't allow the commit hash to be absent
for ordinary users.

P.S. we've debated vendoring these grammars with Emacs.  I still think
that's the right way to go.  But if we're going to download and build,
we should at least do it in a secure way.

P.S.S. Do we need the list of grammars in build.sh under admin? It
duplicates what's in Lisp elsewhere in the tree.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.