this is a recurring problem which that happens whenever a signing key is expired and renewed; such that renewed - it causes pacman rejects to reject packages signed by that key - the files are unmodified since being published; and the report indicates successful verification

the problem persists with verified signatures, even after the signing key is renewed, and even after the keyring package is rebuilt - it is not obvious why, nor why it should do so, or which software/interactions are involved, software is governing that behavior, eg: the keyring package or its build process, the packaging metadata, or some interaction between pacman/gpg

we have tried removing the identity of the person with the expired key from the keyring (the normal way, per hackers.git), then re-adding it; but that did not help - the next step down that path is to delete the entire hackers.git YAML file - IIRC the previous experiment, only the key entry was deleted

most of the experiments have been focussed on the keyring package build process - lately, lately i am looking toward towards other explanations

the current solution is to rebuild all afected packages from source - some experiments to try:
- 1) simply replace the signatures with new ones
- 2) run librerelease on the packages again
- 3) rebuild the keyring packages
4) rebuild the keyring, with the signing key specified in hackers.git, instead of, or in addition to, the master key

my current theory, is that perhaps this is all expected behavior, and pacman-key is doing the thing right, but doing the wrong thing, by considering (intentionally or not) valid signatures from a presently expired key to be unacceptable - that is presumably due to the gpg exit status, although the program reports that it is a "good signature" - however that still would not explain why the warning /rejection persists after the key is renewed then the keyring package is rebuilt

pacman-key should consider the "good signature" per gpg to be of greater significance than the expiry date, and sufficient for package signature verification, unless the key was revoked - the expiry notice is a less significant than a warning, indicating no problem with the primary functionality in question: verifying the integrity/authenticity of a file/signature pair - if it were an invalid signature, or any error condition at all, i would expect: "Note:", would be rather like "Warning:", "Important!:", "Error:", etc

worse though, pacman indicates to the user, that the key has "unknown trust", which is misleading - it has exactly the same trust as before the expiry date, because nothing has changed - gpg is not reporting any error, and is not indicating any fault with the package verification - it is entirely a web-of-trust concern

it is a friendly reminder to the user, to contact this person, asking for that signature to be renewed, if the file in question is still valuable - if that person does not respond, nor extend the expiry, only then would it have a potential to become problematic - again, purely a web-of-trust or team management problem though - the package will always be faithfully verifiable just as the day it was published