List for cgit developers and users
 help / color / mirror / Atom feed
From: john at keeping.me.uk (John Keeping)
Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
Date: Sat, 7 Mar 2015 18:20:03 +0000	[thread overview]
Message-ID: <20150307182002.GJ1369@serenity.lan> (raw)
In-Reply-To: <20150307174932.8657.41364@typhoon>

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


  reply	other threads:[~2015-03-07 18:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-07 14:46 john
2015-03-07 15:59 ` cgit
2015-03-07 17:02   ` john
2015-03-07 17:49     ` cgit
2015-03-07 18:20       ` john [this message]
2015-03-07 23:35         ` tmz
2015-03-08 10:45           ` john
2015-03-09 19:39             ` tmz
2015-03-09 20:49               ` john
2015-03-09 22:32                 ` Jason
2015-03-09 22:34                   ` Jason
2015-03-09 22:30           ` Jason
2015-03-09 22:42             ` tmz
2015-03-11 15:25         ` mricon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150307182002.GJ1369@serenity.lan \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).