GNU bug report logs -
#78542
[Security] hash locking needed for tree-sitter downloads
Previous Next
Full log
View this message in rfc822 format
Ping! Do we want to make some progress here?
> Cc: Yuan Fu <casouri <at> gmail.com>, 78542 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> 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 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.