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

["Robin H. Johnson" <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

On Thu, Nov 28, 2024 at 10:36:36AM -0500, Eli Schwartz wrote:
> This doesn't test a useful property.
> 
> People cannot "remove" compromised keys from a keyserver to begin with.
> If they did, then checking to build the package with GENTOO_MIRRORS=
> DISTDIR=$(mktemp -d) is a significantly more useful test.
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

The SKS server implementation is sufficiently unreliable** for
keys.gentoo.org that one node occasionally corrupts it's database, and I
have a script that rebuilds it. If a key is uploaded to a node, and NOT
yet propagated to other nodes before the corruption event, this could
lead to the appearance of a key being removed.

The SKS network, when it still ran, also provided an eventually
consistent behaviour, such that a series of rapid queries to the DNS
rotation might not always return the same data for a given key if
changes to that key were in flight.

** Yes, one of the gentoo nodes is running Hockeypuck now, and I hope to
replace all of SKS with Hockeypuck in future, but it's not quite the
same yet.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]