* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
@ 2015-03-07 14:46 john
2015-03-07 15:59 ` cgit
0 siblings, 1 reply; 14+ messages in thread
From: john @ 2015-03-07 14:46 UTC (permalink / raw)
This requires that we save the downloaded file explicitly rather than
piping it straight to tar, but that is advisable anyway since it allows
us to check the exit status of curl and make sure that we have
downloaded the file successfully.
Also add a test to make sure we don't forget to update the file when
updating our Git version in the future.
Signed-off-by: John Keeping <john at keeping.me.uk>
---
Makefile | 8 ++++++--
git.sha256sum | 1 +
tests/t0001-validate-git-versions.sh | 11 +++++++++++
3 files changed, 18 insertions(+), 2 deletions(-)
create mode 100644 git.sha256sum
diff --git a/Makefile b/Makefile
index ed329e8..807879f 100644
--- a/Makefile
+++ b/Makefile
@@ -15,7 +15,8 @@ pdfdir = $(docdir)
mandir = $(prefix)/share/man
SHA1_HEADER = <openssl/sha.h>
GIT_VER = 2.3.2
-GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.gz
+GIT_FILE = git-$(GIT_VER).tar.gz
+GIT_URL = https://www.kernel.org/pub/software/scm/git/$(GIT_FILE)
INSTALL = install
COPYTREE = cp -r
MAN5_TXT = $(wildcard *.5.txt)
@@ -146,7 +147,10 @@ clean-doc:
$(RM) cgitrc.5 cgitrc.5.html cgitrc.5.pdf cgitrc.5.xml cgitrc.5.fo
get-git:
- curl -L $(GIT_URL) | tar -xzf - && rm -rf git && mv git-$(GIT_VER) git
+ curl -L $(GIT_URL) --output $(GIT_FILE) && \
+ sha256sum --check git.sha256sum && \
+ tar -xzf $(GIT_FILE) && \
+ rm -rf git && mv git-$(GIT_VER) git
tags:
$(QUIET_TAGS)find . -name '*.[ch]' | xargs ctags
diff --git a/git.sha256sum b/git.sha256sum
new file mode 100644
index 0000000..1214d3d
--- /dev/null
+++ b/git.sha256sum
@@ -0,0 +1 @@
+a35aea3a0f63f4cc3dd38fa32127e97273f335a14ea2586b649eb759ecf675a3 git-2.3.2.tar.gz
diff --git a/tests/t0001-validate-git-versions.sh b/tests/t0001-validate-git-versions.sh
index a65b35e..3325c77 100755
--- a/tests/t0001-validate-git-versions.sh
+++ b/tests/t0001-validate-git-versions.sh
@@ -9,6 +9,12 @@ test_expect_success 'extract Git version from Makefile' '
s/^GIT_VER[ ]*=[ ]*//
p
}" ../../Makefile >makefile_version
+ GIT_VER=$(cat makefile_version)
+ sed -n -e "/^GIT_FILE[ ]*=/ {
+ s/^GIT_FILE[ ]*=[ ]*//
+ s/\$(GIT_VER)/$GIT_VER/
+ p
+ }" ../../Makefile >makefile_file
'
# Note that Git's GIT-VERSION-GEN script applies "s/-/./g" to the version
@@ -38,4 +44,9 @@ test_expect_success 'test submodule version matches Makefile' '
fi
'
+test_expect_success 'git.sha256sum version matches Makefile' '
+ sed -e "s/[0-9a-z]* *//" ../../git.sha256sum >sha256sum_file
+ test_cmp sha256sum_file makefile_file
+'
+
test_done
--
2.3.1.308.g754cd77
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 14:46 [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading john
@ 2015-03-07 15:59 ` cgit
2015-03-07 17:02 ` john
0 siblings, 1 reply; 14+ messages in thread
From: cgit @ 2015-03-07 15:59 UTC (permalink / raw)
On Sat, 07 Mar 2015 at 15:46:41, John Keeping wrote:
> This requires that we save the downloaded file explicitly rather than
> piping it straight to tar, but that is advisable anyway since it allows
> us to check the exit status of curl and make sure that we have
> downloaded the file successfully.
>
> Also add a test to make sure we don't forget to update the file when
> updating our Git version in the future.
>
> Signed-off-by: John Keeping <john at keeping.me.uk>
> ---
> Makefile | 8 ++++++--
> git.sha256sum | 1 +
> tests/t0001-validate-git-versions.sh | 11 +++++++++++
> 3 files changed, 18 insertions(+), 2 deletions(-)
> create mode 100644 git.sha256sum
> [...]
I like the idea, however, sha256sum is not available on all platforms.
This breaks `make get-git` under OpenBSD, for example (OpenBSD has a
utility called sha256 with a different command line interface). Maybe we
can make the check optional, though?
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)?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 15:59 ` cgit
@ 2015-03-07 17:02 ` john
2015-03-07 17:49 ` cgit
0 siblings, 1 reply; 14+ messages in thread
From: john @ 2015-03-07 17:02 UTC (permalink / raw)
On Sat, Mar 07, 2015 at 04:59:26PM +0100, Lukas Fleischer wrote:
> On Sat, 07 Mar 2015 at 15:46:41, John Keeping wrote:
> > This requires that we save the downloaded file explicitly rather than
> > piping it straight to tar, but that is advisable anyway since it allows
> > us to check the exit status of curl and make sure that we have
> > downloaded the file successfully.
> >
> > Also add a test to make sure we don't forget to update the file when
> > updating our Git version in the future.
> >
> > Signed-off-by: John Keeping <john at keeping.me.uk>
> > ---
> > Makefile | 8 ++++++--
> > git.sha256sum | 1 +
> > tests/t0001-validate-git-versions.sh | 11 +++++++++++
> > 3 files changed, 18 insertions(+), 2 deletions(-)
> > create mode 100644 git.sha256sum
> > [...]
>
> I like the idea, however, sha256sum is not available on all platforms.
> This breaks `make get-git` under OpenBSD, for example (OpenBSD has a
> utility called sha256 with a different command line interface). Maybe we
> can make the check optional, though?
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
> 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)?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 17:02 ` john
@ 2015-03-07 17:49 ` cgit
2015-03-07 18:20 ` john
0 siblings, 1 reply; 14+ messages in thread
From: cgit @ 2015-03-07 17:49 UTC (permalink / raw)
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
$ 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 17:49 ` cgit
@ 2015-03-07 18:20 ` john
2015-03-07 23:35 ` tmz
2015-03-11 15:25 ` mricon
0 siblings, 2 replies; 14+ messages in thread
From: john @ 2015-03-07 18:20 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 18:20 ` john
@ 2015-03-07 23:35 ` tmz
2015-03-08 10:45 ` john
2015-03-09 22:30 ` Jason
2015-03-11 15:25 ` mricon
1 sibling, 2 replies; 14+ messages in thread
From: tmz @ 2015-03-07 23:35 UTC (permalink / raw)
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.
(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.
> 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.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Life is the art of drawing without an eraser.
-- John Gardner
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 23:35 ` tmz
@ 2015-03-08 10:45 ` john
2015-03-09 19:39 ` tmz
2015-03-09 22:30 ` Jason
1 sibling, 1 reply; 14+ messages in thread
From: john @ 2015-03-08 10:45 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-08 10:45 ` john
@ 2015-03-09 19:39 ` tmz
2015-03-09 20:49 ` john
0 siblings, 1 reply; 14+ messages in thread
From: tmz @ 2015-03-09 19:39 UTC (permalink / raw)
John Keeping wrote:
> On Sat, Mar 07, 2015 at 06:35:10PM -0500, Todd Zullinger wrote:
>> 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.
Agreed. The caveat is that I'm not sure there is a convenient method
for end-users or packagers to verify the authenticity of a cgit
tarball.
Those on the list can check the PGP signature on the announcement mail
and then use the included SHA1 to check the tarball, but doing that as
a non-list member isn't as easy due to many list archives stripping or
mangling PGP signatures. I tried doing this with the 0.11
announcement from the Mailman and Gmane archives now and wasn't
successful.
Posting a detached PGP signature for the tarball would improve the
ability for users to trust and verify the cgit tarball. It's not a
blocker for your patch, but it would make it significantly more
useful, so I thought I would broach the subject. ;)
Thank you for all of your work on cgit. It's very nice to see it
continue to improve, with even the smallest details getting attention.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now don't say you can't swear off drinking; it's easy. I've done it a
thousand times.
-- W.C. Fields
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-09 19:39 ` tmz
@ 2015-03-09 20:49 ` john
2015-03-09 22:32 ` Jason
0 siblings, 1 reply; 14+ messages in thread
From: john @ 2015-03-09 20:49 UTC (permalink / raw)
On Mon, Mar 09, 2015 at 03:39:29PM -0400, Todd Zullinger wrote:
> Those on the list can check the PGP signature on the announcement mail
> and then use the included SHA1 to check the tarball, but doing that as
> a non-list member isn't as easy due to many list archives stripping or
> mangling PGP signatures. I tried doing this with the 0.11
> announcement from the Mailman and Gmane archives now and wasn't
> successful.
It turns out that GMane mangles the list address in the message, so it
is possible to validate it but it's not straightforward:
curl http://article.gmane.org/gmane.comp.version-control.cgit/2387/raw |
sed -e 's/cgit[^ ]*@public.gmane.org/cgit at lists.zx2c4.com/' |
gpg --verify
> Posting a detached PGP signature for the tarball would improve the
> ability for users to trust and verify the cgit tarball. It's not a
> blocker for your patch, but it would make it significantly more
> useful, so I thought I would broach the subject. ;)
It seems that Jason currently relies on CGit to generate the tarballs by
pointing to http://git.zx2c4.com/cgit/refs/tags, which means that a
signature isn't guaranteed to remain correct (Git has subtly changed the
tar encoding in the past and could do so again).
There's a recent thread on the Git mailing list about a way to handle
this better[0], but there isn't any code yet AFAIK.
[0] http://thread.gmane.org/gmane.comp.version-control.git/264533
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 23:35 ` tmz
2015-03-08 10:45 ` john
@ 2015-03-09 22:30 ` Jason
2015-03-09 22:42 ` tmz
1 sibling, 1 reply; 14+ messages in thread
From: Jason @ 2015-03-09 22:30 UTC (permalink / raw)
On Mar 8, 2015 12:35 AM, "Todd Zullinger" <tmz at pobox.com> wrote:
> But while we're on the subject, are there PGP signatures available for
the cgit tarballs themselves?
I include a sha256 of the tarball in the announcement emails. Those emails
are pgp signed. My pgp key is embedded in the repo, as well, and it's
verifiable that all announce emails have been signed with the same key.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20150309/8add9ccd/attachment.html>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-09 20:49 ` john
@ 2015-03-09 22:32 ` Jason
2015-03-09 22:34 ` Jason
0 siblings, 1 reply; 14+ messages in thread
From: Jason @ 2015-03-09 22:32 UTC (permalink / raw)
On Mar 9, 2015 9:49 PM, "John Keeping" <john at keeping.me.uk> wrote:
> It turns out that GMane mangles the list address in the message,
Better archives:
http://lists.zx2c4.com/pipermail/cgit/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20150309/36b9d33a/attachment.html>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-09 22:32 ` Jason
@ 2015-03-09 22:34 ` Jason
0 siblings, 0 replies; 14+ messages in thread
From: Jason @ 2015-03-09 22:34 UTC (permalink / raw)
Oh, hah, my pipermail does the same. That's annoying. I'll change up the
release announcement next time to avoid that.
On Mar 9, 2015 11:32 PM, "Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
>
> On Mar 9, 2015 9:49 PM, "John Keeping" <john at keeping.me.uk> wrote:
> > It turns out that GMane mangles the list address in the message,
>
> Better archives:
> http://lists.zx2c4.com/pipermail/cgit/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20150309/f1cbaa4c/attachment.html>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-09 22:30 ` Jason
@ 2015-03-09 22:42 ` tmz
0 siblings, 0 replies; 14+ messages in thread
From: tmz @ 2015-03-09 22:42 UTC (permalink / raw)
Jason A. Donenfeld wrote:
> On Mar 8, 2015 12:35 AM, "Todd Zullinger" <tmz at pobox.com> wrote:
>> But while we're on the subject, are there PGP signatures available
>> for the cgit tarballs themselves?
>
> I include a sha256 of the tarball in the announcement emails. Those
> emails are pgp signed. My pgp key is embedded in the repo, as well,
> and it's verifiable that all announce emails have been signed with
> the same key.
(It's a SHA1, isn't it? Not that I care terribly about that part,
other than a general preference for SHA256. :)
More importantly is that verifying the PGP signature from an archive
is not always easy. More often than not, list archives introduce
subtle whitespace damage or worse.
The other point that John made is more interesting. If cgit generates
a tarball on demand, aren't there opportunities for the hash in the
announcement mail (or a detactch signature) to become invalid? I
belive that git archive has made changes in the past to avoid
including the timestamp in the gzip archive, which helps. I don't
know if there are other ways this could change.
In the end, I don't know if it's a problem that can be solved in a way
that doesn't cause more work for you as a maintainer or the other fine
folks who are contributing. That's certainly not my intention. ;)
> On Mar 9, 2015 9:49 PM, "John Keeping" <john at keeping.me.uk> wrote:
>> It turns out that GMane mangles the list address in the message,
>
> Better archives:
> http://lists.zx2c4.com/pipermail/cgit/
I tried that earlier, before posting and found that it munges things
too. Mailman's munging is often due to whitespace changes and are
hard to avoid. Maybe the change to hyperkitty in Mailman 3 will
improve this aspect of the archives. ;)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damn you and your estrogenical treachery!
-- Stewie Griffin
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
2015-03-07 18:20 ` john
2015-03-07 23:35 ` tmz
@ 2015-03-11 15:25 ` mricon
1 sibling, 0 replies; 14+ messages in thread
From: mricon @ 2015-03-11 15:25 UTC (permalink / raw)
On 07/03/15 01:20 PM, 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.
Here's 2 Canadian cents from the guy who is in charge of putting those
.sign files in place. :)
You can do it this way:
1. Create a pubring with Junio's key in it, like so:
gpg --export 96AFE6CB > gitsig.gpg
2. Distribute gitsig.gpg with cgit
3. In the makefile, do something like this (e.g. for git-2.3.2):
xz -cd git-2.3.2.tar.xz | gpgv --homedir=/tmp --keyring=./gitsig.gpg
--status-fd=1 git-2.3.2.tar.sign - | grep '^\[GNUPG:\] GOODSIG'
If the last grep exits with 0, you're good.
Note, that the "grep GOODSIG" part is important if you care to check for
key expiration. Default gpgv behaviour is to exit with 0 even if the key
used to sign the archive has long since expired or has been revoked
(yeah!). Grepping for "GOODSIG" will do the right thing but will also
break your builds when Junio's key expires in September. :)
If you don't care about such levels of paranoia, you can omit the "grep"
and --status-fd=1 part and just rely on gpgv exit code. It's good enough
for most people.
Extra note: instead of using --homedir=/tmp, use a temporary dir created
during make, in order to avoid potential security risks with someone
spiking /tmp with a pubring.gpg.
Hope this helps.
Best,
--
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montr?al, Qu?bec
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-03-11 15:25 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-07 14:46 [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading 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
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
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).