Open jreiser opened 2 years ago
There is a related project https://github.com/rpm-software-management/deltarpm with pull requests (~4 months old) that fix bugs. The changes look OK and should be propagated here.
Deltarpm is a transport mechanism for a repository in 'repomd' format. The repository metadata is signed, and the downloader of the deltarpm has to make sure that it matches the sha256 checksum contained in the metadata. So the deltarpm content can be considered safe.
Makedeltarpm is not run on the consumer side at all, it is run at repo creation time and the input are two trusted rpms. So there's no attack surface as well.
There are 3 open pull requests in https://github.com/rpm-software-management/deltarpm and they are open since 23 days.
Deltarpm is a transport mechanism for a repository in 'repomd' format. The repository metadata is signed, and the downloader of the deltarpm has to make sure that it matches the sha256 checksum contained in the metadata. So the deltarpm content can be considered safe.
Neither Fedora nor RHEL signs its repository metadata, so this assertion is false. The TLS to the server is not considered sufficient because anyone who compromised any of the hundreds of publicly-trusted CAs could perform a monster-in-the-middle attack.
I recommend deprecating v1 and v2 deltarpms, and verifying the signature of v3 deltarpms before applying them. v3 deltarpms have their own signature header, and include the lead and signature header in the deltarpm payland, This means that they can be signed and deltarpm can check their signatures.
I recommend using a distribution that signs its repository metadata.
I recommend using a distribution that signs its repository metadata.
Those are orthogonal concerns. DNF is expected to be secure even if repository metadata is not signed.
I can find no concise documentation relating to the security awareness of this code. Delta .rpms often are part of a supply chain for software that should be resistant to tampering. What threats against integrity of results (or their efficient creation and consumption) have been considered, and what design strategies and implementation techniques have been used to counter, deter, or mitigate such threats?
One recent post on suspected security problem areas within the deltarpm package by Demi Marie Obenour on 2022-03-06: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/42I5IQEHRBLKUIB6KIHTE46RYTUVNPHU/
Specific items for makedeltarpm:
-m
to limit memory usage must be a global limit that applies to peak memory usage for the entire duration of makedeltarpm, including all compression and de-compression subsystems. Also, either the same limit, or some other adjustable limit, must enable applydeltarpm to succeed.