From mboxrd@z Thu Jan  1 00:00:00 1970
From: john at keeping.me.uk (John Keeping)
Date: Sun, 8 Mar 2015 10:45:21 +0000
Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
In-Reply-To: <20150307233510.GU3567@zaya.teonanacatl.net>
References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk>
 <20150307155926.6430.47439@typhoon>
 <20150307170259.GI1369@serenity.lan>
 <20150307174932.8657.41364@typhoon>
 <20150307182002.GJ1369@serenity.lan>
 <20150307233510.GU3567@zaya.teonanacatl.net>
Message-ID: <20150308104520.GK1369@serenity.lan>

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:
> 
> http://git.kernel.org/cgit/git/git.git/tag/?id=junio-gpg-pub)
> 
> 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 
> targeting.

Precisely.

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

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