[SeriousCoding789]

What does this PR do?

For user experience, start.sh accepts for now a release jar signed by the release key after the key has expired. It still rejects the jar when the release key has been revoked, including a revoked key that has also expired.

• start.sh: checkSign accepts the release key's signature when gpg reports it as GOODSIG or EXPKEYSIG, and reads revocation from the key listing as well as from REVKEYSIG.
• shell.md: a signature made by a revoked release key fails verification; an expired release key is no longer mentioned.

Why are these changes required?

Since #7090, checkSign rejects a signature that gpg reports as EXPKEYSIG. gpg judges key expiry at verification time, not at signing time, so a signature made while the key was valid is reported as EXPKEYSIG once the key has expired. If the release signing subkey expires before its expiry is extended, the jars of all earlier releases fail verification, and --download, --upgrade, --release and the archive tool download no longer install them.

Accepting EXPKEYSIG is not enough on its own: gpg reports a signature made by a key that has been revoked and has also expired as EXPKEYSIG, not REVKEYSIG. So checkSign also reads revocation from gpg --with-colons --list-keys, from the records of the primary key and the release subkey, and rejects the jar if either has been revoked.

This PR has been tested by:

• Manual Testing: checkSign taken unchanged from start.sh before and after this change, run with real gpg 2.5.20 under macOS bash 3.2. The key server and the downloads are replaced by local fixtures, and the fixture keys are structured like the release key (a certify-only primary key with a signing subkey). Signatures made before and after the expiry of a key are created with gpg's clock set back (--faked-system-time).

Scenario	Before	After
Good signature	verified	verified
Signing subkey revoked	rejected	rejected
Primary key revoked	rejected	rejected
Another subkey of the release key revoked	verified	verified
Signing subkey expired, signature made before the expiry	rejected	verified
Signing subkey expired, signature made after the expiry	rejected	verified
Signing subkey expired and revoked	rejected, logged as expired	rejected, revocation logged
Signing subkey expired, primary key revoked	rejected, logged as expired	rejected, revocation logged
Signing subkey expired, jar modified	rejected	rejected
Jar modified, signature missing, or signed by another key only	rejected	rejected
Good signature plus a signature by an unknown key	verified	verified

• bash -n start.sh; shellcheck reports nothing new.
• Not run: gpg 2.2 on Linux, and the download of a real release.

Follow up

The release signing subkey F859BCB44A28290B expires on 2027-01-03. gpg does not sign with an expired key, so the subkey's expiry has to be extended, and published to keys.openpgp.org and keyserver.ubuntu.com, before a release is signed after that date. A new signing subkey would instead require RELEASE_KEY_FINGERPRINT in start.sh to be updated.

Extra details

• Signatures made before and after the expiry are treated the same. The signature time is set by whoever makes the signature, so comparing it with the expiry would not stop a holder of the key.
• While an expired release key is accepted, revoking the key is the only way to stop start.sh from accepting its signatures. Revoking needs the primary key or its revocation certificate.

[halibobo1205]

[DISCUSS] With EXPKEYSIG accepted, expiry no longer limits how long start.sh trusts the release subkey, and revocation becomes the only way to retire it, as the PR notes. Before merging, can we confirm that the primary key or a revocation certificate for 07B23298AEA4E006BD9A42DE785FB96D2C7C3CA5 is available offline? If neither is, the subkey could not be retired for any start.sh that pins it.

[NIT] An expired key is now accepted without any message. Keeping warn 'the release key has expired' on the accept path (while still verifying) would make a lapsed expiry visible in the logs, and shell.md could say that signatures by an expired release key are still accepted.