[PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
john at keeping.me.uk
Sun Mar 8 11:45:21 CET 2015
On Sat, Mar 07, 2015 at 06:35:10PM -0500, Todd Zullinger wrote:
> John Keeping wrote:
> > I still think we can't rely on `gpg --recv-keys` though, we would
> > have to distribute the key with CGit and possible also do something
> > to avoid importing it into the user's keyring by default.
> If the check was to be run from a cgit clone, the key Junio uses to
> sign git tarballs could be included as a blob, similarly to how it's
> done in git.git.
My assumption is that if people have cloned CGit then they will probably
clone Git as well, at which point they check out an explicit SHA-1.
> (See the junio-gpg-pub tag in git.git for anyone unfamiliar with this
> already. The key can be extracted via:
> git cat-file blob junio-gpg-pub
> I've always thought that was a neat use of git, but certainly not a
> common one. I can't manage to make github display this tagged blob,
> which is also amusing.
> The cgit-hosted kernel.org repo displays it easily though:
> This method does nothing for users who have downloaded a cgit tarball,
> of course, which I expect is more likely to be the use case you're
> > I think a hash is more appropriate for the situation we're in - we
> > are assuming that the user is happy that the CGit distribution they
> > have is trustworthy but we must verify that the Git distribution we
> > download is also correct.
> I don't think this is unreasonable at all. Trust has to start
> somewhere. For users that want to go to the source, they can always
> download git directly (or just the detached PGP signature) and verify
> the tarball. When I updated cgit packages in Fedora and EPEL, this is
> what I always did. I don't know if the current maintainers follow
> that process still, but hopefully they do. ;)
> But while we're on the subject, are there PGP signatures available for
> the cgit tarballs themselves? I know the git tags are signed, but I
> don't think I've seen detached signatures for the tarballs. In this
> case, how does a user become "happy that the CGit distribution they
> have is trustworthy"? The cgit tarball download isn't available via
> https either, which might be a reasonable answer in the absence of a
> detached git signature.
> Without a signature on the tarball or some other method to verify the
> cgit tarball, the sha256 of the git tarball included in the cgit
> Makefile is more or less only useful as a basic download integrity
> check (in which case sha256 is mild overkill).
> None of this is to say that this patch isn't a step in the right
> direction. It certainly helps to display a nicer error message if a
> user receives a corrupted git tarball. It's just important that users
> don't confuse this with providing any real authentication of the git
I'm not sure this is true. Providing that the CGit tarball is trusted,
then I think this does provide sufficient authentication of the Git
tarball. If the CGit tarball isn't trusted, then all bets are off
More information about the CGit