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. _______________________________________________ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit