verifySignature in mfer/openpgp.go accepts a signature whose key has expired, since a manifest outlives its key. The OpenPGP library checks key expiry first and, on finding the key expired, never looks at the signature's own expiry time. So a signature made with an expiry time (as gpg --sig-expire writes) was refused while its key was live and accepted once the key had expired too.
verifySignature now calls openpgp.VerifyDetachedSignature, which returns the signature packet with the error. When the only complaint is the expired key, it refuses the signature if the signature itself has expired. A live key with an expired signature was already refused by the library.
TestVerifySignatureKeyExpiredSince signs twice in 2020, with the library and a fixed clock, using a key that lasted a day: the signature with no expiry time still verifies, and the one that expired after an hour is refused. The second half failed before the fix.
docs/FORMAT.md Signature Scheme gains a short paragraph stating the rule.
Deviation: the issue suggested reading the signature packet in verifySignature; the library call above returns it, so nothing new parses it.
Not covered, beyond the issue: once the key has expired the library also skips the expiry checks on the key's self-signature and on a signing subkey's binding signatures, and nothing checks that the signature was made before the key expired.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/mfer/issues/193
`verifySignature` in `mfer/openpgp.go` accepts a signature whose key has expired, since a manifest outlives its key. The OpenPGP library checks key expiry first and, on finding the key expired, never looks at the signature's own expiry time. So a signature made with an expiry time (as `gpg --sig-expire` writes) was refused while its key was live and accepted once the key had expired too.
`verifySignature` now calls `openpgp.VerifyDetachedSignature`, which returns the signature packet with the error. When the only complaint is the expired key, it refuses the signature if the signature itself has expired. A live key with an expired signature was already refused by the library.
`TestVerifySignatureKeyExpiredSince` signs twice in 2020, with the library and a fixed clock, using a key that lasted a day: the signature with no expiry time still verifies, and the one that expired after an hour is refused. The second half failed before the fix.
`docs/FORMAT.md` Signature Scheme gains a short paragraph stating the rule.
Deviation: the issue suggested reading the signature packet in `verifySignature`; the library call above returns it, so nothing new parses it.
Not covered, beyond the issue: once the key has expired the library also skips the expiry checks on the key's self-signature and on a signing subkey's binding signatures, and nothing checks that the signature was made before the key expired.
Model: opus-5-5
verifySignature accepts a signature whose key has expired, since a
manifest outlives its key. The OpenPGP library stops at the expired key
without checking the signature's own expiry time, so a signature made
with one was refused while the key was live and accepted once the key
had expired as well. verifySignature now gets the signature packet from
openpgp.VerifyDetachedSignature and refuses it when it has expired.
docs/FORMAT.md Signature Scheme states the rule.
Model: opus-5-5
A signature dated after its key expired is still accepted: confirmed on next; this change leaves it as it was.
A key whose self-signature has expired, or a signing subkey whose binding signature has expired, is still accepted once that key or subkey has expired as well: confirmed on next; this change leaves it as it was.
Outside this issue: a signature dated before its key was made is accepted, on next as well, including when the key's creation date is still in the future.
Model: opus-5-5
Review passed.
- A signature dated after its key expired is still accepted: confirmed on `next`; this change leaves it as it was.
- A key whose self-signature has expired, or a signing subkey whose binding signature has expired, is still accepted once that key or subkey has expired as well: confirmed on `next`; this change leaves it as it was.
- Outside this issue: a signature dated before its key was made is accepted, on `next` as well, including when the key's creation date is still in the future.
Model: opus-5-5
clawbot
merged commit 24496880c5 into next2026-10-13 19:21:53 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #193
verifySignatureinmfer/openpgp.goaccepts a signature whose key has expired, since a manifest outlives its key. The OpenPGP library checks key expiry first and, on finding the key expired, never looks at the signature's own expiry time. So a signature made with an expiry time (asgpg --sig-expirewrites) was refused while its key was live and accepted once the key had expired too.verifySignaturenow callsopenpgp.VerifyDetachedSignature, which returns the signature packet with the error. When the only complaint is the expired key, it refuses the signature if the signature itself has expired. A live key with an expired signature was already refused by the library.TestVerifySignatureKeyExpiredSincesigns twice in 2020, with the library and a fixed clock, using a key that lasted a day: the signature with no expiry time still verifies, and the one that expired after an hour is refused. The second half failed before the fix.docs/FORMAT.mdSignature Scheme gains a short paragraph stating the rule.Deviation: the issue suggested reading the signature packet in
verifySignature; the library call above returns it, so nothing new parses it.Not covered, beyond the issue: once the key has expired the library also skips the expiry checks on the key's self-signature and on a signing subkey's binding signatures, and nothing checks that the signature was made before the key expired.
Model: opus-5-5
Review passed.
next; this change leaves it as it was.next; this change leaves it as it was.nextas well, including when the key's creation date is still in the future.Model: opus-5-5