> 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.
Perhaps the best solution is to ensure (by appropriate use of HSMs) that the
key cannot be leaked, and therefore does not need to be revoked.
--
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-873937456
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
