On 03/13/18 05:33, Uwe Kleine-König wrote: >>> But it also has an impact on security: As long as the signature isn't >>> verified I have to consider the .tar.xz "untrusted" and the less tools I >>> have to make operate on it the better. This scheme allows an attacker >>> that has control over a mirror to provide a .tar.xz that makes unxz do >>> undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an >>> attack idea. >> >> Which is why we provide sha256sums.asc in each directory. > > That would be worth to point out more prominently on the above webpage > then IMHO.
We do, we have a whole section about sha256sums.asc files: https://www.kernel.org/signature.html#kernel-org-checksum-autosigner-and-sha256sums-asc > When you recompress files you have to resign your sha256sum file, so I > don't see the advantage "without needing to re-sign all files" you > mentioned above. Released tarballs carry signatures from developers, not from any automated infrastructure, so you can see how that complicates the picture if we have to ask Linus or Greg KH to create new signatures for all tarballs they've ever created. > (Also recompressing has the immediate downside to break > third-party tools that rely on unchanged files from upstream, which IMHO > outweighs the disk space gained from recompressing.) I would say such tools are wrong because they expect non-normalized formats to remain constant. I appreciate that I'm basically saying "everyone is doing it wrong and we're the only ones who are shiny and smell nice," but I do believe there's at least solid technical reasoning behind our decision to sign .tar archives and not the compressed versions. I think it will help you understand the reasoning more if I explain the workflow behind how releases are currently produced (you can see my talk about the entirety of the release process here: https://www.youtube.com/watch?v=vohrz14S6JE): 1. Linus creates a .tar archive locally on his laptop, using "git archive" -- which is always deterministic 2. Linus creates a detached signature of that tar archive 3. Linus sends us a very small request with just three things in it a. the tag b. the prefix to use with "git archive" c. the detached signature 4. We use these to create the .tar archive from our version of the tree, verify it against Linus's detached signature, and if (and only if) the signature verifies, we create .gz and .xz archives and upload them to the frontends. There are the following major benefits behind this process: 1. Linus only has to upload a few KB of data to produce a release, instead of 200+ MB of combined .xz and .gz archive data. Since he routinely produces releases while at conferences and remote diving locations, he greatly appreciates not having to do that. 2. More importantly, if Linus's laptop is compromised and someone tries to sneak in a trojaned tarball between the time when "git archive" finishes and "gpg --detach-sign" fires off, the signature verification will fail when we try to generate the tarball on our end. Any trojans would need to exist in the git tree, where they have a much greater chance of being discovered than in a one-off tarball. By using our current procedure we significantly reduce the risks of workstation compromises resulting in trojaned tarballs carrying legitimate developer signatures. It's true, we could ask Linus to generate signatures for the .xz archive on his end, but this would require that he runs "xz -9" on a 600MB tarball and wait half an hour for it to finish -- and then hope we produce the same resulting .xz on our end, which is not at all guaranteed between different xz versions, whereas git has tests that specifically check that git-archive generated .tar archives are identical between git releases. > Also for the attack vector against the decompressor, this effectively > renders the developer's signature useless because I have to trust the > sha256sum.asc (and so the archive key) before handing the compressed > file to the decompressor. > (Yeah I know, this is harder to exploit than introducing changes to the > tar archive, but IMHO this is no reason to keep this flaw unfixed.) I hope I've demonstrated how "fixing" this attack vector opens up a whole another one that is much, much worse. > Would it be possible to provide signatures on the compressed archives > using the same key that today signs sha256sums? I imagine this wouldn't > result in a significant retooling issue on your side and in return it > would simplify the handling of signature verification for all those who > care. No, because this would pretty much guarantee that people will not bother checking developer signatures and would just rely on automatically generated ones. This would violate our grand principle of "trust the developer, not infrastructure." I believe our approach has merit and results in better security protections. To verify the validity of any release you should: 1. Download the tarball and sha256sums.asc 2. Verify the signature on sha256sums.asc using a trusted keyring 3. Verify the tarball hash in sha256sums.asc 4. Decompress the tarball (in a jailed environment, if you like) 5. Verify the developer signature on the .tar file against a trusted keyring Regards, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation
signature.asc
Description: OpenPGP digital signature
