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
