Re: [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass

[Eli Schwartz <eschwartz@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1461 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]