On 2024-02-19 20:56:12 (-0600), David C. Rankin wrote:
This is kind of the whole breakdown in gpg signing. In 2018, the keyservers were hit with a type of malware that effectively served as global DDOS on the keyservers (many of which were unmaintained and had simply been running for years unattended). After the attack much of the keyserver system was simply never restarted leading to difficulties in getting public keys to verify signatures. They are hit-of-miss at best now.
What happened in 2019 [1] (and likely plenty of times on and off before that) has nothing to do with "malware", but is the effect of "Certificate Spamming". OpenPGP certificates [2] could grow *very large*, as people wer able to just attach many (random) identity certifications [3]. In the set of OpenPGP key servers any server using the old Synchronizing Key Server (SKS) protocol and software was affected by this issue, as the server-side software did not verify whether a certification (aka. "signing someone's key") on an OpenPGP certificate is legitimate or not. The SKS key servers never had a way of getting around this problem, as the OpenPGP protocol up until now does not define a (ratified) way of doing so. However, there is an IETF draft [4] on this topic. Initial implementers of a solution are the hagrid key server [5] and sq [6]. The hockeypuck key server software [7] also allows to mitigate the issues (AFAIK), as certificates can be pruned or removed (I unfortunately don't know the details here).
As long as the AUR package makes the needed public keys available, then all is fine, but if users are left to "get the key from a keyserver" - the specific keyserver holding the key needs to be identified, as there is little or no sync of keys anymore.
Currently there are several options when it comes to (syncing or non-syncing) OpenPGP key servers: - hagrid [5] based, non-syncing, GDPR compliant: https://keys.openpgp.org - hockeypuck [7] based, non-syncing: https://keyserver.ubuntu.com - hockeypuck [7] based, syncing [8]: https://pgpkeys.eu Further, there is the possibility to retrieve OpenPGP certificates via Web Key Directory (WKD) [9]. This solution is not available to all, as it requires one to make available a directory structure with certificates in a well-known location for the host associated with the e-mail address of a User ID. Compared to a keyserver it grants a higher degree of receiving a certificate that is actually audited and made available by *someone* associated with that domain though. It is generally alright and a service to the user to make OpenPGP certificates available alongside your PKGBUILDs in the AUR (in ASCII armored form), as it *is* sometimes really hard to get to upstream's certificate (could be one of "it's on my website", "it's in my git forge profile", "it's in my WKD" or "it's on that one particular keyserver, but not the other") - perks of being a packager. Whether upstream then maintains an actual trust path between release signatures is yet another story. Closing I would like to add that with *any* sort of signature and authenticity claim it is on the consumer to verify, validate and trust this claim. The PKGBUILDs (and any verification scheme that may come along with it) offered in the AUR are "unsupported" for a reason. Best, David [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f [2] https://openpgp.dev/book/glossary.html#term-OpenPGP-Certificate [3] https://openpgp.dev/book/glossary.html#term-Identity-Certification [4] https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc/ [5] https://gitlab.com/keys.openpgp.org/hagrid/ [6] https://man.archlinux.org/man/sq-key-attest-certifications.1 [7] https://github.com/hockeypuck/hockeypuck [8] https://spider.pgpkeys.eu/sks-peers [9] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ -- https://sleepmap.de