gpgv: timestamps, validity, expiration, and revocation

[Bernhard Reiter]

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?

FWIW:
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 
issue.

Best,
Bernhard


-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160504/74ec8945/attachment.sig>