What MD5? Besides being hopelessly outdated and vulnerable, nothing besides rpm
-K actually verifies it. Yum/dnf certainly does not. And it lives in the
signature header so you can just modify it at will.
Repository formats are just not relevant here, at all, no matter which way
they're
Okay, but that'd also be caught by MD5, right? So...do we expect every package
system to verify *both* the rpm-md checksum and this one? Running SHA256 or
whatever *is* pretty cheap, I know.
Perhaps enough people rely on "untrusted rpm-md fetched over http + GPG signed
RPMs" that we have to
What on earth does rpm-md have to do with this? It exists on an entirely
different level, and has checksums on the entire package file, at the time of
repository generation. Files can get corrupted and truncated in transit from
rpmbuild to a repository. That has happened in Fedora repos, people
In practice though, people shouldn't be using raw `rpm` to install RPMs. They
should (and 90% of the time are) using a higher level system like zypper, yum,
or rpm-ostree.
These systems all consume "rpm-md/yum" metadata, which obviously today has a
checksum over the content, which can be
Closed #163.
--
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/163#event-981848847___
Rpm-maint mailing list
Initial implementation in commit 91aa0786cf3b2e34de01c586427952de6d0d9b40.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thinking about it a bit more, there are many other challenges with the multiple
intermediate digest snapshots: the compression stream is created on
file-by-file basis which isn't well suited for this purpose, as one file might
be just a few bytes and the next one gigabytes, we'd presumably want
