From me at maiyun.me Sat May 2 14:06:15 2026 From: me at maiyun.me (Zhang Maiyun) Date: Sat, 2 May 2026 08:06:15 -0400 Subject: [PATCH] build: Add AC_PROG_AR to configure.ac In-Reply-To: <20260502120128.89949-1-me@maiyun.me> References: <20260502120128.89949-1-me@maiyun.me> Message-ID: <202605029f94b93c2900@localnet.as211585.net> Hello all, I apologize for another trivial patch. This makes sure cross compilations use the correct `ar`. While previously `ar`/`ranlib` seemed to silently accept objects for another architecture, now, Darwin `ar` (macOS) discards unrecognized objects and causes the `libsecmem.a`/`libpinentry.a` linking steps to fail during a cross compilation: ``` $ aarch64-linux-gnu-gcc -c -o test.o -x c - <<< 'void f(){}' $ ar cr test.a test.o ranlib: warning: archive member 'test.o' not a mach-o file $ nm test.a $ ar t test.a __.SYMDEF SORTED ``` On Sat, May 02, 2026 at 08:01:20AM -0400, me at maiyun.me wrote: > From: Zhang Maiyun > > * configure.ac: add AC_PROG_AR. > > -- > > Signed-off-by: Zhang Maiyun > --- > configure.ac | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure.ac b/configure.ac > index a4f443d..3df11b3 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -81,6 +81,7 @@ AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) > AC_PROG_CC > AC_PROG_CPP > AC_PROG_INSTALL > +AC_PROG_AR > AC_PROG_RANLIB > # We need to check for cplusplus here because we may not do the test > # for Qt and autoconf does does not allow that. > -- > 2.54.0 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 325 bytes Desc: not available URL: From me at maiyun.me Sat May 2 14:12:16 2026 From: me at maiyun.me (Zhang Maiyun) Date: Sat, 2 May 2026 08:12:16 -0400 Subject: [PATCH pinentry] build: Add AC_PROG_AR to configure.ac In-Reply-To: <202605029f94b93c2900@localnet.as211585.net> References: <20260502120128.89949-1-me@maiyun.me> <202605029f94b93c2900@localnet.as211585.net> Message-ID: <202605020267ce26373b@localnet.as211585.net> Apologies. I did not mention that this patch is for pinentry. GnuPG already has `AC_CHECK_TOOL(AR, ar, :)`. On Sat, May 02, 2026 at 08:06:48AM -0400, Zhang Maiyun wrote: > Hello all, > > I apologize for another trivial patch. > > This makes sure cross compilations use the correct `ar`. > > While previously `ar`/`ranlib` seemed to silently accept objects for > another architecture, now, Darwin `ar` (macOS) discards unrecognized > objects and causes the `libsecmem.a`/`libpinentry.a` linking steps to > fail during a cross compilation: > > ``` > $ aarch64-linux-gnu-gcc -c -o test.o -x c - <<< 'void f(){}' > $ ar cr test.a test.o > ranlib: warning: archive member 'test.o' not a mach-o file > $ nm test.a > > $ ar t test.a > __.SYMDEF SORTED > ``` > > On Sat, May 02, 2026 at 08:01:20AM -0400, me at maiyun.me wrote: > > From: Zhang Maiyun > > > > * configure.ac: add AC_PROG_AR. > > > > -- > > > > Signed-off-by: Zhang Maiyun > > --- > > configure.ac | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/configure.ac b/configure.ac > > index a4f443d..3df11b3 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -81,6 +81,7 @@ AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) > > AC_PROG_CC > > AC_PROG_CPP > > AC_PROG_INSTALL > > +AC_PROG_AR > > AC_PROG_RANLIB > > # We need to check for cplusplus here because we may not do the test > > # for Qt and autoconf does does not allow that. > > -- > > 2.54.0 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 325 bytes Desc: not available URL: From me at maiyun.me Sat May 2 14:01:20 2026 From: me at maiyun.me (me at maiyun.me) Date: Sat, 2 May 2026 08:01:20 -0400 Subject: [PATCH] build: Add AC_PROG_AR to configure.ac Message-ID: <20260502120128.89949-1-me@maiyun.me> From: Zhang Maiyun * configure.ac: add AC_PROG_AR. -- Signed-off-by: Zhang Maiyun --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index a4f443d..3df11b3 100644 --- a/configure.ac +++ b/configure.ac @@ -81,6 +81,7 @@ AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) AC_PROG_CC AC_PROG_CPP AC_PROG_INSTALL +AC_PROG_AR AC_PROG_RANLIB # We need to check for cplusplus here because we may not do the test # for Qt and autoconf does does not allow that. -- 2.54.0 From andrewg at andrewg.com Sun May 3 14:17:24 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 3 May 2026 13:17:24 +0100 Subject: No v5 support in hockeypuck (Was: Undocumented novel Ed448 point encoding breaks interoperability) In-Reply-To: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com> References: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com> Message-ID: Hi, all. In reply to my previous email to gnupg-devel [0], but cross-posting for maximum audience: On 05/01/2026 13:55, Andrew Gallagher via Gnupg-devel wrote: > It has been brought to my attention that Ed448 keys are being encoded > without prefix octets in their MPIs/SOSes, which breaks compatibility > with go-crypto (and perhaps others) and is not documented anywhere that > I can find. The librepgp specification requires prefix octets for all > ECC curve point representations. After (finally!) enabling support for v5 keys in hockeypuck, I have discovered that ECDH curve448 encryption subkeys have the same curve point encoding issue as Ed448 signing (sub)keys. protonmail/go-crypto, the OpenPGP library that hockeypuck relies on, implemented v5 support according to the latest rfc4880bis [1] draft, which consistently specifies prefix octets of 0x04 or 0x40 for all ECC point curves, whether ECDSA, ECDH, or EdDSA. (protonmail/go-crypto was an early adopter of the rfc4880bis draft, and as such it is the only library available to hockeypuck that provides production v5 support of any kind; most of the alternatives never officially released v5 support) The change in the Ed448 point encoding since rfc4880bis, as mentioned in my previous email, has been (belatedly) acknowledged in the most recent version of draft-librepgp [2]. The discrepancy in the ECDH point encoding still has not. As a result, it is not now possible for hockeypuck to process *any* v5 key material that GnuPG generates, even if we include support for the v5 packet format as planned, since v5 is only generated in practice for x448 and type 8 kyber algorithms, neither of which are parseable. Note also that x448 key generation is gated behind expert mode in gnupg and type 8 "kyber" keys are not. This means that only a small fraction of the wild population of v5 keys would be fully usable even if this encoding discrepancy was addressed. Type 8 will not be implemented in pm/gc as the library is prioritising support for the upcoming standard draft-ietf-openpgp-pqc [3] and draft-ietf-openpgp-nist-bp-comp [4] PQC keys instead. At this point, even though it would be easy for me to claim a theoretical "v5 support" in hockeypuck 2.4, it would be a cruel and misleading prank on our users because none of them would be able to upload a real v5 key to any of the keyservers. Even if we were to patch in a hotfix for prefix-less code points (which would not be prohibitively difficult) it would still only serve a small number of expert users, and expert users are much more likely to prefer PQC encryption. So I am (as of today) dropping v5 support as a design goal of hockeypuck, and pausing work on it indefinitely. If and when a meaningful fraction of GnuPG-compatible algorithm code points are added to pm/gc, or if GnuPG added support for interoperable PQC algorithms [3][4], I would happily reconsider. I'm sorry that it has taken me three years to come to this conclusion. I could (in theory) have spotted this incompatibility earlier and saved users the false hope that v5 and v6 keys could coexist on the keyservers in the current state of the ecosystem. Thanks once again to Liz Fong-Jones for finding this issue and bringing it to my attention. A [0] https://lists.gnupg.org/pipermail/gnupg-devel/2026-January/036128.html [1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis#name-ecdsa-and-ecdh-conversion-p [2] https://author-tools.ietf.org/iddiff?url1=draft-koch-librepgp-04&url2=draft-koch-librepgp-05&difftype=--html#part-10 [3] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc [4] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-nist-bp-comp PS here's a hexdump of a v5 curve448 ECDH subkey that I generated this morning using gnupg 2.5.18 from macports, showing that there is no 0x40 or 0x04 octet present. The prefix octet would be expected at byte 0x12, immediately following the x448 curve OID 0x2b656f and the MPI length 0x01be. (It's an MPI length BTW, not an SOS length - SOS lengths are rounded up to the nearest multiple of 8) ``` 00000000 b8 CTB 00000001 4c length 00000002 05 version 00000003 69 f7 0a 31 12 00 00 00 42 03 2b 65 6f 00000010 01 be 37 69 62 e9 a7 a7 81 c5 7b c5 c7 5d da f6 00000020 d2 aa 26 e1 7e fc 35 ce 3c 11 d9 50 b9 c9 71 84 00000030 5d 61 60 84 93 af 60 fa db 59 aa 15 68 b4 3f 65 00000040 cd 1d fc 3d d6 34 c3 64 1a 49 03 01 0a 09 ``` From jernej.jakob at gmail.com Tue May 5 11:51:44 2026 From: jernej.jakob at gmail.com (Jernej Jakob) Date: Tue, 5 May 2026 11:51:44 +0200 Subject: Pinentry-mode loopback doesn't tell the user which PIN it's asking for Message-ID: <20260505115144.3abae0c6@gentoo.home> I have a GUI-less system that I use gpg on, I use it in GNU screen, I tried to set it to use pinentry-tty but that conflicts with screen and it breaks input (IIRC it doubles all characters or is otherwise unusable, it's been a while since I tested it). It works fine with pinentry-mode=loopback, but it doesn't say which PIN it's asking for, so I have to work from memory, knowing which PIN it's asking for which particular command. Is it possible to make gpg say which PIN it's asking for, the same way that pinentry does? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 265 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue May 5 13:45:17 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 May 2026 13:45:17 +0200 Subject: Pinentry-mode loopback doesn't tell the user which PIN it's asking for In-Reply-To: <20260505115144.3abae0c6@gentoo.home> (Jernej Jakob via Gnupg-devel's message of "Tue, 5 May 2026 11:51:44 +0200") References: <20260505115144.3abae0c6@gentoo.home> Message-ID: <871pfqqdv6.fsf@jacob.g10code.de> On Tue, 5 May 2026 11:51, Jernej Jakob said: > It works fine with pinentry-mode=loopback, but it doesn't say which PIN That is a kludge for unattended use. > Is it possible to make gpg say which PIN it's asking for, the same way > that pinentry does? No, it does not know. gpg-agent knows that. Either you write your own pinentry in a simialr manner as Emacs did it. Or if you have no GUI, just use a curses based Pinentry or the pinentry-tty. The curses mode is actually the fallback for the GUI pinentries if DISPLAY is not set. You may need to redraw the screen, as it is the case with many curses applications, but gpg supports this by emitting a PINENTRY_LAUNCHED status line. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: