> 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
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
@ffesti ping
--
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/1610#issuecomment-874242576___
Rpm-maint mailing list
@ffesti ping
--
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/1547#issuecomment-874223347___
Rpm-maint mailing list
@ffesti ping
--
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/1672#issuecomment-874223443___
Rpm-maint mailing list
@ffesti would you mind looking at this?
--
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/1613#issuecomment-874124913___
Rpm-maint
> But the risk is not completely eliminated, since the usage of the HSM itself
> may have become compromised. An attacker may have gained access to a system
> with HSM access and issued malicious signatures. If this should happen, a key
> replacement is most probably warranted.
Absolutely!
> Perhaps the best solution is to ensure (by appropriate use of HSMs) that the
> key cannot be leaked.
Yes, that comes a long way to mitigating the problem and is hopefully already
used by the major distributions.
But the risk is not completely eliminated, since the usage of the HSM itself
> I agree with @ffesti about key revokation being more complex than what it
> seems like. When you revoke, you don't want to invalidate the signatures
> created _before_ the revokation. That would require every existing package to
> be re-signed with the new key, which would be very disruptive.
I agree with @ffesti about key revokation being more complex than what it seems
like. When you revoke, you don't want to invalidate the signatures created
_before_ the revokation. That would require every existing package to be
re-signed with the new key, which would be very disruptive.
But
> @dmantipov Is there a CVE associated with this vulnerability?
> I'm asking so that I can keep an eye out for the fix.
>
> Also, on a different note, any idea if package managers that reply on rpm are
> vulnerable as well? Yum and Zypper for instance.
OK, as there is some confusion here: There
11 matches
Mail list logo
