Maybe, my dearest @lone-cloud, the issue might be somewhat related to the fact that we're currently more or less one-and-a-half people at best maintaining pretty much the whole thing.
That's very much not optimal, true.
More importantly though: your approach to handling a packaging issue you've spotted is pretty much not helping, and would be disheartening, if it weren't for me being stubborn, I guess. (Also, I wouldn't want to leave the only other remaining core maintainer completely alone with the project, so "stepping down" is not an option.)
Way more words than I should've spent on this, so: on with more productive things.
Thanks for bringing this issue to my attention. Huge thanks to @DKMellow on Codeberg for the PR. I'll take care of merging it and updating the PKGBUILDs tomorrow, as soon as I've gotten a few hours of sleep.
Pinned Comments
lsf commented on 2021-11-10 12:14 (UTC) (edited on 2026-05-07 09:38 (UTC) by lsf)
https://wiki.archlinux.org/title/Arch_User_Repository#Acquire_a_PGP_public_key_if_needed
gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 031F7104E932F7BD7416E7F6D2845E1305D6E801/edit: starting with 112.0-1, the binaries are signed with the maintainers shared key, so
gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16should do the trick instead. I've also signed the key with the previously used key, so you have at least some guarantee that it's not a malicious attack :)/edit: (2026-05-07): The upstream signing sub-key was rotated, and the
.tar.xztarballs will now be signed with a new subkey. The main key id (0x662E3CDD6FE329002D0CA5BB40339DD82B12EF16) remains unchanged though, so should you get an error during signature verification about a missing (sub)key, all that's required would be to refresh the key(s) viagpg --refresh-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16.