[Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (#1470)

[Demi Marie Obenour]

> @DemiMarie : this is an excellent point. There is verification of the whole rpm file in librepo (see [rpm-software-management/librepo#222](https://github.com/rpm-software-management/librepo/pull/222)) and rpm signature verification is done after that, but there remains the possibility of a rogue mirror offering bad data into a compression library.
> 
> My answer for tonight is that this depends on whether you trust your mirrors. This proposal assumes you do, and I will update the linked proposal with this caveat tomorrow. The bottom line: this is opt in, and not intended to be enabled anywhere by default today.

Thank you.  I certainly do not trust my mirrors, so this would not work for me.

> In the immediate future, I will investigate potential solutions. The one I came up with tonight involves PAYLOADDIGESTALT or another header with a list of digests per reasonable sized block of compressed data, pre-decompression. Example: SHA256 with 1MiB block size would add a trivial overhead, but allow data to be verified before feeding into a decompression library. This would require support for a digest of the headers in the repodata's primary.xml[1], and would in turn be part of the checksum in repomd.xml and the metalink mirror infra. I am looking at [1] for related reasons.

This should be acceptable, but only if the repository metadata was signed and that signature was checked.  Currently, Fedora doesn’t sign its metadata, but this may be fixed in the future.  Signing the metadata is definitely a good idea for other reasons.

> I am definitely open to suggestions. Thank you for this very valuable feedback.

You’re welcome!  What if the RPM signature included a signature of the RPM header, and the RPM header included a list of hashes?  That would allow `rpmkeys -K` and the remaining RPM signature verification machinery to continue to work as normal, with essentially no loss of security.  It would also protect against decompression bomb denial of service attacks.

-- 
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/pull/1470#issuecomment-752339716
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20201229/071e4593/attachment.html>