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

Previous Next

Package: emacs;

Reported by: Daniel Colascione <dancol <at> dancol.org>

Date: Wed, 21 May 2025 19:13:04 UTC

Severity: normal

To reply to this bug, email your comments to 78542 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#78542; Package emacs. (Wed, 21 May 2025 19:13:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Colascione <dancol <at> dancol.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 21 May 2025 19:13:04 GMT) Full text and rfc822 format available.

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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78542; Package emacs. (Thu, 22 May 2025 06:47:04 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: Yuan Fu <casouri <at> gmail.com>, 78542 <at> debbugs.gnu.org
Subject: Re: bug#78542: [Security] hash locking needed for tree-sitter
 downloads
Date: Thu, 22 May 2025 09:36:57 +0300
> When downloading code, a tag isn't good enough.  We should insist on a
> specific commit.
> [...]
> 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.

Indeed, tags can be easily relocated to a different commit.

> 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.

Agreed, "hash locking" should lock commit hashes, not tags.

> 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.

The only reason currently tags are used instead of commit hashes is
because there is no way to checkout a specific commit with the
current implementation when the default value of
'treesit--install-language-grammar-full-clone' is nil.

> 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.

Apparently no need, so they could be removed.




This bug report was last modified 2 days ago.

Previous Next


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