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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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