Expired signatures break dotgpg

[viraptor]

Any encrypted file which was signed with a key that expired, stops dotgpg from working correctly. The message is:

$ dotgpg cat secrets/buildkite.yml.gpg
/opt/rubies/2.2.4/lib/ruby/gems/2.2.0/gems/dotgpg-0.7.0/lib/dotgpg/dir.rb:68:in `block in decrypt': signature was incorrect (Dotgpg::InvalidSignature)
	from /opt/rubies/2.2.4/lib/ruby/gems/2.2.0/gems/dotgpg-0.7.0/lib/dotgpg/dir.rb:59:in `open'
	from /opt/rubies/2.2.4/lib/ruby/gems/2.2.0/gems/dotgpg-0.7.0/lib/dotgpg/dir.rb:59:in `decrypt'

because the signature is tested with .valid?. This however includes the case of a valid signature from an expired key.

Since it breaks on every command, you can't dotgpg add ... ; dotgpg edit ... to fix the situation.

[ConradIrwin]

@viraptor There is a workaround you can use:

DOTGPG_ALLOW_INJECTION_ATTACKS=true dotgpg edit ...

Not sure what the usual way of handling this situation is with other crypto tools?

[viraptor]

I'd go with warn (to stderr) and allow. Possibly with another warning when the signature is close to expiry? For comparison, gpg itself doesn't explicitly warn in that case, but does show the key with an [expired] tag.

[viraptor]

To add more context on where it's a pain point: If you're relying on dotgpg in context of CI/CD, it's a pain when things stop working just because the signature is out of date. The DOTGPG_ALLOW_INJECTION_ATTACKS=true is not a possible long-term solution there, because it also drops the exceptions about signature being unknown/invalid.

Alternatively splitting it into a separate DOTGPG_ALLOW_EXPIRED_SIGNATURE would be a viable thing to permanently add in some context, but a warning sounds even better. That's all IMO, of course.