mirror of
https://github.com/archr-linux/Arch-R.git
synced 2026-07-12 18:19:42 -07:00
Douglas Teles
199e9a5ee4
Live diagnostic on a R36S running the 20260624 image showed:
archr:~ # gpg --version | head -1
gpg (GnuPG) 1.4.23
archr:~ # gpg --list-packets /usr/share/pacman/keyrings/archr.gpg
:public key packet:
...
unknown algorithm 22
GPG 1.4 is the "classic" branch, frozen before Ed25519 (algorithm 22)
was added in 2.1.x (2014). pacman-key 7.x also calls into gpg with
--check-signatures, a 2.x-only flag. With the ArchR master subkey
being Ed25519 the legacy 1.4 binary can neither parse nor verify the
keyring, so pacman -Sy fails with "no valid user IDs" and "signature
... is invalid" no matter how the user populates the keyring.
Fix the build, not the key. JELOS-era pacman packages cap GnuPG at
1.4.23 because that's the minimal-deps branch; ArchR is now an
Arch-family distro that ships pacman 7 as the user-facing update path,
so it has to ship the modern GnuPG runtime that pacman expects.
New packages:
- libksba 1.8.0
- npth 1.8
- pinentry 1.3.2 (built with --enable-pinentry-tty/curses only;
the GUI variants would pull GTK/Qt that the handheld doesn't have)
Updated:
- gnupg 1.4.23 -> 2.4.8 (latest LTS branch)
Configure trims to the bits pacman uses: gpg + gpgsm + gpgconf.
scdaemon, dirmngr, tofu, wks, gpg-card and the historical 1.4-era
ciphers (idea/cast5/md5/rmd160) are disabled to keep the image lean.
pinentry-tty is the configured pinentry program, since the handheld
has no graphical desktop session to use the other variants.
libassuan, libgcrypt and libgpg-error already live in projects/ArchR/
packages/security/ from earlier work — no new dep tree there.
This unblocks the pacman pipeline on R36S: archr-keyring populate will
parse the Ed25519 master, signature verification will accept the
ArchR-signed archr.db, and pacman -Sy lands at the package list.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>