[Rpm-maint] [rpm-software-management/rpm] Support uncompressed/reconstructed payloads (#861)
notifications at github.com
Sat Sep 28 04:49:15 UTC 2019
(The source hash is an interesting and not-unrelated problem, but there's some other stuff to figure out before that can get done correctly - like how to make a sufficiently-unique but also human-meaningful identifier for the environment the package was built in, or the flags used to build it, etc..)
> Somehow permitting the payload bits to differ from what was created at build-time would be a pretty significant change for rpm, but I agree there's a point in it: ultimately it's the authenticity of delivered bits that matter, not the delivery box (of compression).
Yeah, that's it exactly - as a general principle, the digest/signature should cover some _canonical form_ of the data. That way other people can transform/store/etc. the data however they want, as long as there's a way to reliably transform it _back_ to the canonical form it can always be verified as authentic.
In other words: If you sign _uncompressed_ data, it's possible to verify _any_ compressed data, because every compression algorithm guarantees that it can recover the original data
Similarly: if you sign the data with a well-known ordering - like, say, signing a hash of the sorted list of individual file digests - then you can verify the data regardless of what order you examine the individual parts. (Which is kind of like the source file hash you're talking about, but connecting source and binaries is tricky, so let's not get into that yet...)
As an optimization, it definitely makes sense to include a digest (or multiple digests!) of uncompressed and compressed/archived data, so you can more quickly verify the integrity of common payload formats. (Solaris IPS does something like this - they have "hash" and "chash" keys/tags in their package metadata, so you can check the `chash` if you have compressed data, or uncompress it and you can check `hash`..)
Anyway, my interest here is more about compatibility between RPM and external tools, especially new repo/package formats. Generally: if I have some data store that contains (or can rebuild) a complete, intact RPM header, and I have all the files listed in that RPM header - and all their digests match, so I know I have the right files - what's the easiest way for me to get RPM to install/update/verify that package header and those files?
It turns out that given _just_ the RPM header and the file contents you can reconstruct the original RPM lead and uncompressed payload of nearly all modern RPMs - all the data in the lead and CPIO headers is also in the RPM headers, and the payload file ordering _almost_ always match the header order. But I still can't convince RPM that I have authentic data, because I'm using a slightly different version of xz, or I didn't store the original timestamp, or the payload file order sometimes doesn't match the RPM header file ordering, or whatever.
So: any solution that means that I can get RPM to accept that the uncompressed files are, in fact, the same as the compressed ones, would be pretty great.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint