From: john at keeping.me.uk (John Keeping)
Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
Date: Sun, 8 Mar 2015 10:45:21 +0000 [thread overview]
Message-ID: <20150308104520.GK1369@serenity.lan> (raw)
In-Reply-To: <20150307233510.GU3567@zaya.teonanacatl.net>
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.
next prev parent reply other threads:[~2015-03-08 10:45 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
2015-03-07 23:35 ` tmz
2015-03-08 10:45 ` john [this message]
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=20150308104520.GK1369@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).