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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
