From mboxrd@z Thu Jan  1 00:00:00 1970
From: john at keeping.me.uk (John Keeping)
Date: Sat, 7 Mar 2015 18:20:03 +0000
Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
In-Reply-To: <20150307174932.8657.41364@typhoon>
References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk>
 <20150307155926.6430.47439@typhoon>
 <20150307170259.GI1369@serenity.lan>
 <20150307174932.8657.41364@typhoon>
Message-ID: <20150307182002.GJ1369@serenity.lan>

On Sat, Mar 07, 2015 at 06:49:32PM +0100, Lukas Fleischer wrote:
> On Sat, 07 Mar 2015 at 18:02:59, John Keeping wrote:
> > [...]
> > I'm not sure what benefit it has if it's optional.  Will anyone check?
> > 
> > Maybe we could do something like:
> > 
> >         if type sha256sum >/dev/null 2>&1
> >         then
> >                 sha256sum --check git.sha256sum $(GIT_FILE)
> >         else
> >                 echo >&2 'WARNING: sha256sum not found so we cannot verify'
> >                 echo >&2 'WARNING: the integrity of the Git archive!'
> >         fi
> > 
> 
> That is exactly what I meant by suggesting to make it optional. Sorry
> for being vague...
> 
> > > On a related note, can we download a signature and use `gpg --verify`
> > > instead (should probably be optional as well, to avoid a dependency on
> > > GnuPG)?
> > 
> > I thought about that, but we'd have to embed a key with CGit for it to
> > work reliably and how do we choose what key to use (given that
> > individual Git archives are not signed - the list of SHA256 checksums
> > is)?
> > 
> 
> Huh? This works fine for me:
> 
>     $ gpg --recv-keys 96AFE6CB 
>     gpg: key 713660A7: public key "Junio C Hamano <gitster at pobox.com>" imported
>     gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
>     gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
>     gpg: Total number processed: 1
>     gpg:               imported: 1
>     $ curl -OO https://www.kernel.org/pub/software/scm/git/git-2.3.2.tar.{xz,sign} 
>       % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                      Dload  Upload   Total   Spent    Left  Speed
>     100 3529k  100 3529k    0     0  1133k      0  0:00:03  0:00:03 --:--:-- 1133k
>     100   543  100   543    0     0   3404      0 --:--:-- --:--:-- --:--:--  3404
>     $ unxz git-2.3.2.tar.xz

Oh, I tried this earlier but completely missed the fact that the
signature was on the bare tar file not one of the compressed versions.

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.

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.

>     $ gpg --verify git-2.3.2.tar.sign 
>     gpg: assuming signed data in 'git-2.3.2.tar'
>     gpg: Signature made Sat 07 Mar 2015 12:10:41 AM CET using RSA key ID 96AFE6CB
>     gpg: Good signature from "Junio C Hamano <gitster at pobox.com>" [unknown]
>     gpg:                 aka "Junio C Hamano <jch at google.com>" [unknown]
>     gpg:                 aka "Junio C Hamano <junio at pobox.com>" [unknown]
>     gpg: WARNING: This key is not certified with a trusted signature!
>     gpg:          There is no indication that the signature belongs to the owner.
>     Primary key fingerprint: 96E0 7AF2 5771 9559 80DA  D100 20D0 4E5A 7136 60A7
>          Subkey fingerprint: E1F0 36B1 FEE7 221F C778  ECEF B0B5 E886 96AF E6CB