> @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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
