On 11/29/24 1:31 PM, Robin H. Johnson wrote: > From a technical perspective, that depends on the keyserver design. > > But the canonical "why" is GDPR Article 17 - right-to-erasure. > > Hockeypuck even ships a script to make it easy for admins to delete > keys: > https://github.com/hockeypuck/hockeypuck/blob/5cc0fffe46f44986cbf78a554ab482e3baaa5143/contrib/docker-compose/standalone/README.md?plain=1#L177-L190 > > There is another more obvious reason why a key might vanish from a > keyserver: ephemeral & eventually consistent state
Indeed, but that just reinforces my point that this doesn't represent a failing test. :) GDPR argumentation aside and practicalities alone, PGP keys for developers of software packaged in linux distributions *cannot* be forgotten, period, since they exist in tons of places including committed to git as *.asc files in multiple distros' package sources. And user-requested deletion would anyways not be a test failure as the package is plainly fine and can continue to be verified. It's possible for us to be independently asked to make a commit that removes the key in question from ::gentoo, but that's a separate story. Ephemeral state is an even greater indication of why refreshes should be expected to fail without failing the test :) since an ephemeral state that is not yet consistent does not mean the key has disappeared or that it needs to be updated. -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
