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

Fixed in version 31.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Yuan Fu <casouri <at> gmail.com>, 78542 <at> debbugs.gnu.org, dancol <at> dancol.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78542: [Security] hash locking needed for tree-sitter
 downloads
Date: Tue, 24 Jun 2025 03:45:15 +0300
On 23/06/2025 19:51, Juri Linkov wrote:
>>> When I tried various similar recipes, they all failed.  Maybe because I tried
>>> with abbreviated SHA1s.  However, with the full SHA1 this seems to work.
>>> I don't know how reliable this method is, since it requires setting
>>> uploadpack.allowReachableSHA1InWant=true on the server side.
>>
>> I wonder if the new --revision option relies on that server setting anyway
>> (how else would it be implemented?)
> 
> Can't find any mentions of allowReachableSHA1InWant in
> https://github.com/git/git/commit/337855629f59a3f435dabef900e22202ce8e00e1

I think that's client code. Whereas the setting above would be on the 
server.

> Probably because --revision is a simplified and limited version of --branch:
> 
>    Option `--revision` on contrary detaches HEAD, creates no tracking
>    branches, and writes no fetch refspec.

It still needs to know how to fetch a single revision that does not 
reference a tag or etc. Maybe that's a capability that was available 
internally already - but then why would the server setting be needed for 
the "old" solution for this? One using 'git fetch'.

>>> Otherwise, let's wait until the new --revision option becomes more widespread.
>>
>> Might take a few years (or 5-10). This script runs on the user's machine,
>> and historically we've been hesitant to up the requirements on the
>> installed version of Git.
> 
> Meanwhile we could use something like
> (version<= "2.49.0" (vc-git--program-version))

Yeah, that should work.




This bug report was last modified 23 days ago.

Previous Next


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