From: "Michal Suchánek" <msuchanek@suse.de>
To: Eli Schwartz <eschwartz93@gmail.com>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
Git List <git@vger.kernel.org>
Subject: Re: Stability of git-archive, breaking (?) the Github universe, and a possible solution
Date: Tue, 31 Jan 2023 21:45:50 +0100 [thread overview]
Message-ID: <20230131204550.GI19419@kitsune.suse.cz> (raw)
In-Reply-To: <df7b0b43-efa2-ea04-dc5b-9515e7f1d86f@gmail.com>
On Tue, Jan 31, 2023 at 11:34:59AM -0500, Eli Schwartz wrote:
> On 1/31/23 11:20 AM, Konstantin Ryabitsev wrote:
> > On Tue, Jan 31, 2023 at 10:56:52AM -0500, Eli Schwartz wrote:
> >> And for tarballs that are generated once and uploaded to ftp storage,
> >> not repeatedly generated on the fly, we know the checksum will never
> >> legitimately change, so we *want* to hash the compressed file.
> >> Decompressing kernel.org tarballs in order to run PGP on them is *slow*.
> >
> > FWIW, the most correct way is:
> >
> > * download sha256sums.asc and verify its signature (auto-signed by infra)
> > * download the tarball you want and verify that the checksum matches
> > * uncompress and verify the PGP signature (signed by developer)
> >
> > This script implements this workflow:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/get-verified-tarball
>
>
> This is just what I said, but with an additional first step for when you
> are updating to a new tarball and don't have your own checksums
> integrated into your own ecosystem tracking.
>
> In most contexts, it's utterly unacceptable to not remember the checksum
> of the file you used last time and instead simply trust PGP identity
> verification. This permits upstream the technical means to be malicious,
> and re-upload a totally different tarball with the same name, different
> contents, and different PGP signature, and you will never notice because
> the PGP signature is still okay.
But where is the hash remembered?
The signature is a hash+signature, it you can replace that, you can also
repolace a hash without a signature.
You can store hashesd of anything you want locally, and indeed such
stored hashes in some build systemns did detect some code hosting
corruption but that's not for upstream to do, that's something that only
unrelated third party can do.
Thanks
Michal
next prev parent reply other threads:[~2023-01-31 20:46 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 0:06 Stability of git-archive, breaking (?) the Github universe, and a possible solution Eli Schwartz
2023-01-31 7:49 ` Ævar Arnfjörð Bjarmason
2023-01-31 9:11 ` Eli Schwartz
2023-02-02 9:32 ` [PATCH 0/9] git archive: use gzip again by default, document output stabilty Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 1/9] archive & tar config docs: de-duplicate configuration section Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 2/9] git config docs: document "tar.<format>.{command,remote}" Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 3/9] archiver API: make the "flags" in "struct archiver" an enum Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 4/9] archive: omit the shell for built-in "command" filters Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 5/9] archive-tar.c: move internal gzip implementation to a function Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 6/9] archive: use "gzip -cn" for stability, not "git archive gzip" Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 7/9] test-lib.sh: add a lazy GZIP prerequisite Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 8/9] archive tests: test for "gzip -cn" and "git archive gzip" stability Ævar Arnfjörð Bjarmason
2023-02-02 9:32 ` [PATCH 9/9] git archive docs: document output non-stability Ævar Arnfjörð Bjarmason
2023-02-02 10:25 ` brian m. carlson
2023-02-02 10:30 ` Ævar Arnfjörð Bjarmason
2023-02-02 16:34 ` Junio C Hamano
2023-02-04 17:46 ` brian m. carlson
2023-02-02 16:17 ` [PATCH 0/9] git archive: use gzip again by default, document output stabilty Phillip Wood
2023-02-02 16:40 ` Junio C Hamano
2023-02-03 13:49 ` Ævar Arnfjörð Bjarmason
2023-02-06 14:46 ` Phillip Wood
2023-02-03 15:47 ` Theodore Ts'o
2023-02-02 16:25 ` Junio C Hamano
2023-02-04 18:08 ` René Scharfe
2023-02-05 21:30 ` Ævar Arnfjörð Bjarmason
2023-02-12 17:41 ` René Scharfe
2023-02-02 19:23 ` Raymond E. Pasco
2023-02-03 8:06 ` [PATCH] archive: document output stability concerns Raymond E. Pasco
2023-01-31 9:54 ` Stability of git-archive, breaking (?) the Github universe, and a possible solution brian m. carlson
2023-01-31 11:31 ` Ævar Arnfjörð Bjarmason
2023-01-31 15:05 ` Konstantin Ryabitsev
2023-01-31 22:32 ` brian m. carlson
2023-02-01 9:40 ` Ævar Arnfjörð Bjarmason
2023-02-01 11:34 ` demerphq
2023-02-01 12:21 ` Michal Suchánek
2023-02-01 12:48 ` demerphq
2023-02-01 13:43 ` Ævar Arnfjörð Bjarmason
2023-02-01 15:21 ` demerphq
2023-02-01 18:56 ` Theodore Ts'o
2023-02-02 21:19 ` Joey Hess
2023-02-03 4:02 ` Theodore Ts'o
2023-02-03 13:32 ` Ævar Arnfjörð Bjarmason
2023-02-01 23:16 ` brian m. carlson
2023-02-01 23:37 ` Junio C Hamano
2023-02-02 23:01 ` brian m. carlson
2023-02-02 23:47 ` rsbecker
2023-02-03 13:18 ` Ævar Arnfjörð Bjarmason
2023-02-02 0:42 ` Ævar Arnfjörð Bjarmason
2023-02-01 12:17 ` Raymond E. Pasco
2023-01-31 15:56 ` Eli Schwartz
2023-01-31 16:20 ` Konstantin Ryabitsev
2023-01-31 16:34 ` Eli Schwartz
2023-01-31 20:34 ` Konstantin Ryabitsev
2023-01-31 20:45 ` Michal Suchánek [this message]
2023-02-01 1:33 ` brian m. carlson
2023-02-01 12:42 ` Ævar Arnfjörð Bjarmason
2023-02-01 23:18 ` brian m. carlson
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=20230131204550.GI19419@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=eschwartz93@gmail.com \
--cc=git@vger.kernel.org \
--cc=konstantin@linuxfoundation.org \
--cc=sandals@crustytoothpaste.net \
/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).