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 how can you trust the signature date? An attacker could create a new
signature with a forged date. Therefore you need to add support for trusted
third-party timestamping to the signatures. Unless I am mistaken, there is no
such support in GPG:
https://dev.gnupg.org/T4108
https://dev.gnupg.org/T4537
The problem is not specific to RPM and package signatures. Git signatures, for
example, also have the same issue:
https://petertodd.org/2016/opentimestamps-git-integration
Short term, the simplest way to deal with a compromised key, is to remove it
from the RPM DB, just as @ffesti suggested. There should be a tested and
planned process for how to do this, for example by sending an emergency update,
perhaps signed with the disaster recovery key (in Red Hat case). It would also
require all packages are re-signed with a new key, since the old ones will be
invalidated after the key removal.
Long term, adding support for trusted timestamps would make key revokation much
easier.
--
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-873935952
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
