> There is another issue that is not covered by revocation at all. A software
> package is obsolete as soon as a new version of the package is signed,
> especially if there is a known vulnerability in the old version. However, the
> signature of the vulnerable version obviously stays valid. If the security of
> updates were just based on package signatures, an attacker could just give
> you an old package version with a known vulnerability.
> Signing on the package level is a nice extra feature, but it is only a piece
> in a working security concept. It is not even covering the update process.
> Even if key revocation worked (which in general it does not, Google does not
> even use it for TLS any more), a valid signature on the package level is no
> guarantee that the update is correct.
> This is of course solved by signing of update lists in short intervals, which
> makes signatures on the package level unnecessary in the first place.
The signature on an RPM by a vendor/distributor implies that the package has
indeed been provided by the vendor and an MITM attacker has not tampered with
it. It does not prove that the binaries in the package are non-malicious or
free from known/unknown security defects, those are different security
problems. Most likely someone who trusts his vendors signing keys would also
trust that the vendor is providing him with known good binaries.
--
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/1598#issuecomment-874388985
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
