sec-keys/openpgp-keys-gentoo-developers was designed to have extensive validation both for the confidence of those consuming it and also maintainability, so we don't need to trust the file we pull it down from on qa-reports.gentoo.org. This was and is the right decision, ofc. But it means that right now, we prune out expired signatures too, even if they were valid at the time of the ebuild being committed. Should we use e.g. libfaketime or something in the ebuild so that it reflects "as it was" at the time? I think gpg also has --fake-system-time or something like that. Maybe it should be a USE flag? Thoughts? Note that this won't help for verification if using it in repos.conf for gpg verification of say, gentoo.git, for commits after such a point (which is one of the use cases I had in mind for the package from the start)
I should say, the reason the status quo is arguably bad: nondeterminism in a package based on when it was installed isn't great, and it led to someone even being confused recently about why my key was missing when we'd forgot to bump the ebuild. But maybe that's a *feature* as it means we're reminded to bump the ebuild regularly, too.
Overall, this bears some similarities to my WIP eclass except for using the L1 key as the source of truth rather than requiring a maintained list of valid keys as an eclass variable. My eclass doesn't do anything with expired keys though. And it's not clear whether it should, since expired keys are still the key in question and could be relevant for archaeology etc. But keyring-mangler has comments: # If it's expired, drop the key, as we can't easily then # verify it because of gpg limitations. Maybe setting a fake time is a good thing because it ***works around this bug***, yeah. Not really about whether or not the key should "still be trusted". My eclass does error out in src_test if it finds a keyserver update etc which changes the exported key. It's not concerned about cross-checking against L1 trust. (In reply to Sam James from comment #1) > But maybe that's a *feature* as it means we're reminded to bump the ebuild > regularly, too. That feels like something useful to check in src_test instead.
Isn't that the conceptual difference between * expiry (the signature was valid when it was made, and stays valid) and * revocation (the signature should be treated as has never been valid) ?
