gpgv: timestamps, validity, expiration, and revocation
bernhard at intevation.de
Wed May 4 08:48:52 CEST 2016
Am Freitag, 22. April 2016 20:34:41 schrieb Daniel Kahn Gillmor:
> I think gpgv should check for revoked or expired keys; if it assumes
> that all keys in the keyring are trustworthy, then why would it not be
> willing to rely on those keys' stated (and self-certified) expiration
> dates or revocation certificates?
I agree that gpgv -- if it exists -- should behave consistently, check for
expiration and revokation.
My wild guess is that technically the current checks are done in a different
place, this is why they are done. They are an indicator that something
is not fully okay with the signatures.
> I'm particularly worried about this because i'm hoping that apt (and
> other package managers) will move to using gpgv for verification --
> there's no reason for a verification-only context (like verifying signed
> package manifests) to need to bundle in all the complexity that goes
> with secret key handling.
I'm unsure about this, the extra burden of maintaining a verification only
version may be higher than what you win by having it in some contexts.
So a valid solution could be to just remove gpgv completly.
> If gpgv doesn't handle these timestamp issues
> correctly, then package managers relying on gpgv can be subject to
> archive "freezing", slowing, or replay attacks.
> Is there a reason to keep the earlier, inconsistent behavior, or should
> i file a bug report tracking a fix for this?
I guess you should file a report, just to be able to refer to and track the
www.intevation.de/~bernhard +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel