Hello Konstantin, On Mon, Mar 12, 2018 at 05:20:26PM -0400, Konstantin Ryabitsev wrote: > On 03/08/18 05:15, Uwe Kleine-König wrote: > > The kernel.org archive provides signatures for the software available > > (which is great!). The method to verify these according to > > > > > > https://www.kernel.org/category/signatures.html#using-gnupg-to-verify-kernel-signatures > > > > is to download the .tar.xz and the .tar.sign file, unxz the archive and > > check the signature against the .tar file. > > > > For one this is inconvenient because most tools don't know > > this scheme. In my case this is tooling from Debian to work with > > upstream archives[1]. > > I know it's a problem for Debian,
I wouldn't call it a "problem". AFAICT Debian is well capable to adapt here and some tools already support this scheme of signing. My main focus is on the security implications, the inconvenience is just a side effect. > but changing this scheme for us would require significant retooling > just as it would for Debian infra. The major upside of the current > approach is that we are free to add new compressors, recompress > existing archives with higher compression ratios, etc, without needing > to re-sign all files. > > > 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. 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. (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.) 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.) 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. Best regards Uwe
signature.asc
Description: PGP signature
