> Also note that what dnf and friends do is only header signature verification,
> they do not actually verify the payload at all. They verify that the download
> matches what was in the repository, but that's not the same as being
> untampered with. Also, you do not want rpmReadPackageFile() to
@pmatilai so here is what I would *like* to see:
1. Duplicate tags in signature headers are not allowed.
2. Signature headers are not allowed to duplicate tags found in the immutable
header, after fixups.
3. Signatures are verified before headers are imported.
4. `rpmReadPackageFile` is
@pmatilai Taking a step back, the purpose of this ticket is to ensure that were
a vulnerability found in RPM’s header manipulation, it would not be possible to
exploit it. There are two paths that could help here:
1. Fuzz `rpmReadPackageFile` and friends.
2. Reduce the amount of code that
Also note that what dnf and friends do is only header signature verification,
they do not actually verify the payload at all. They verify that the download
matches what was in the repository, but that's not the same as being untampered
with. Also, you do not want rpmReadPackageFile() to
Closed #1484.
--
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/1484#event-4194448359___
Rpm-maint mailing list
Nope. It needs to be possible to *read* packages regardless of whether you can
verify their signatures or not, otherwise you can't read a package to figure
out what key you need to import to verify it.
What matters is verifying for *installation*, and this is *finally* enforced by
rpm since
`rpmReadPackageFile()` currently ignores the transaction verification level,
forcing clients such as DNF and libdnf to check after the fact if signatures
were present. Respecting the verification level in `rpmReadPackageFile` would
be cleaner. If backwards-compatibility precludes this, we