(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:
https://github.com/rpm-software-management/rpm/issues/861#issuecomment-536153480
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
