GNU bug report logs -
#78542
[Security] hash locking needed for tree-sitter downloads
Previous Next
To reply to this bug, email your comments to 78542 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
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):
> 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.