From josh at quinlan.cloud Sat Oct 3 00:30:42 2026 From: josh at quinlan.cloud (Josh Quinlan) Date: Fri, 02 Oct 2026 23:30:42 +0100 Subject: scd:piv: Ed25519 and X25519 support for YubiKey 5.7, would a patch be welcome? Message-ID: Hi all, YubiKey firmware 5.7 supports Ed25519 and X25519 keys in the PIV applet, but scd/app-piv.c only handles RSA 2048/3072 and NIST P-256/P-384. With an Ed25519 key in slot 9A (tested with GnuPG 2.5.24 on a YubiKey 5.7.4): - readkey falls back to the certificate, so the public key comes through with the curve as its OID, 1.3.101.112 - gpg-agent with enable-ssh-support offers the key as the card's auth key, and the whole SSH listing then fails: "error fetching identities: invalid format" - get_key_algorithm_by_dobj rejects the curve, so signing fails as well Master as of 2026-09-16 has no Ed25519 code in app-piv.c, and I could not find an existing task on dev.gnupg.org. I'd like to write a patch for: 1. Key types 0xE0 (Ed25519) and 0xE1 (X25519) 2. readkey returning the key in the EdDSA form gpg-agent expects (curve Ed25519, flags eddsa) 3. Ed25519 signing: the message passed through unhashed, and the raw 64-byte signature returned 4. Key generation and import 5. X25519 decryption It would be tested on a real card, against master, with a DCO sign-off. Questions: - Is anyone already working on this? - Anything to know about how you'd want the curve handled, for example normalising it in app-help.c rather than app-piv.c? Thanks, Josh From vuori at notcom.org Sat Oct 3 20:57:42 2026 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Sat, 3 Oct 2026 21:57:42 +0300 Subject: Yubikey PIV and PIN Policy In-Reply-To: <87h5jp3fdr.fsf@haruna.fsij.org> References: <87h5jp3fdr.fsf@haruna.fsij.org> Message-ID: On Wed, Sep 16, 2026 at 03:00:00PM +0900, NIIBE Yutaka via Gnupg-devel wrote: > Hello, > > I'm currently creating a patch for: > > https://dev.gnupg.org/T8442 > > The problem is Yubikey PIV support. Currently, for the PIV.9C signing > key, PIN verification is always required and this restriction is forced > by scdaemon side (as well as the device itself). It is the default > behavior of the device and it conforms to the NIST SP 800-73-5. > > On the other hand, Yubikey supports PIV policy setting per key slot, and > a user can change the behavior, not requiring the PIN verification > always, but once. > > Currently, scdaemon doesn't care about the device setting, which should > be fixed. > > I don't have any experience with PIV. Could someone help to evaluate > the patch? Fixed PivApplet and the scdaemon patch works fine for me now with that. The GET METADATA command was broken for imported keys but working for on-card generated keys. It might be a good idea to preserve the old logic where slot 9C is hardcoded to always-ask to deal with old Yubikey 4 devices (firmware older than 5.3) that don't support GET METADATA and non-Yubico PIV cards. -valtteri From gniibe at fsij.org Wed Oct 7 03:06:35 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 07 Oct 2026 10:06:35 +0900 Subject: Yubikey PIV and PIN Policy In-Reply-To: References: <87h5jp3fdr.fsf@haruna.fsij.org> Message-ID: <87bj969v50.fsf@haruna.fsij.org> Hello, Thank you for your testing. It would make sense to extend GENKEY/WRITEKEY command of scdaemon, but currently, there is no way in GnuPG to configure this kind of device-specific metadata when it goes to GENKEY/WRITEKEY of scdaemon. (I assumed/assume that it is done by other tool.) It would also make sense to extend SETATTR command of scdaemon. Valtteri Vuorikoski wrote: > It might be a good idea to preserve the old logic where slot 9C is > hardcoded to always-ask to deal with old Yubikey 4 devices (firmware > older than 5.3) that don't support GET METADATA and non-Yubico PIV > cards. Thank you for your suggestion. Indeed, the patch I sent was not good for non-METADATA-supported device. Attached is an update. If no objections, this will be pushed to master. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-piv-Check-PIN-Policy-to-decide-about-the-verific.patch Type: text/x-diff Size: 5534 bytes Desc: not available URL: From vuori at notcom.org Thu Oct 8 09:50:36 2026 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Thu, 8 Oct 2026 10:50:36 +0300 Subject: Yubikey PIV and PIN Policy In-Reply-To: <87bj969v50.fsf@haruna.fsij.org> References: <87h5jp3fdr.fsf@haruna.fsij.org> <87bj969v50.fsf@haruna.fsij.org> Message-ID: On Wed, Oct 07, 2026 at 10:06:35AM +0900, NIIBE Yutaka wrote: > It would make sense to extend GENKEY/WRITEKEY command of scdaemon, but > currently, there is no way in GnuPG to configure this kind of > device-specific metadata when it goes to GENKEY/WRITEKEY of scdaemon. > (I assumed/assume that it is done by other tool.) > > It would also make sense to extend SETATTR command of scdaemon. Do you mean using SETATTR to set an internal state value in scdaemon to indicate "make the next generated/written key have _this_ pinpolicy"? I guess that would work too. > Valtteri Vuorikoski wrote: > > It might be a good idea to preserve the old logic where slot 9C is > > hardcoded to always-ask to deal with old Yubikey 4 devices (firmware > > older than 5.3) that don't support GET METADATA and non-Yubico PIV > > cards. > > Thank you for your suggestion. Indeed, the patch I sent was not good > for non-METADATA-supported device. > > Attached is an update. If no objections, this will be pushed to master. I didn't have time to test the new version yet but the logic for falling back to fixed decision looks good to me. -valtteri From torbjorn.svensson at foss.st.com Thu Oct 8 10:00:04 2026 From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON) Date: Thu, 8 Oct 2026 10:00:04 +0200 Subject: [PING]: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: <538262a6-4553-4a4c-84ae-9899c1798789@foss.st.com> References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> <877bktxko5.fsf@jacob.g10code.de> <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com> <87v78cw36k.fsf@jacob.g10code.de> <538262a6-4553-4a4c-84ae-9899c1798789@foss.st.com> Message-ID: <4527c6cc-f0f9-4f64-afd6-bf2da60fe556@foss.st.com> Gentle ping. :) Kind regards, Torbjörn On 2026-09-23 14:26, Torbjorn SVENSSON via Gnupg-devel wrote: > > > On 2026-09-11 18:34, Torbjorn SVENSSON via Gnupg-devel wrote: >> >> >> On 2026-09-11 11:24, Werner Koch wrote: >>> On Thu, 10 Sep 2026 16:40, Torbjorn SVENSSON said: >>> >>>> I'd love to do that, but every attempt that I've done to access >>>> https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR. >>> >>> Sorry for this.  Those ^%&%&% AI scrapers just drive us crazy and thus >>> we still need to blacklist most of the net.  But they have not yet taken >>> over mailing lists, thus please post bug reports here. >> I don't know what format you want this in, so I'll just use plain text. >> >> Bug report: >> >> If the host running gpg has no route to the Internet and the DNS does not >> resolve any public domains, gpg will fail to download the public key from a >> keyserver, even if configured to go through a proxy server. >> >> In https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036385.html, >> I attached a small docker setup where this can be verified. In the demo, >> there is no custom binary or anything alike. The input to the "run-test.sh" >> script is a path to a git clone of the gpg source tree and the tree will >> be copied into the container and built inside. >> I also added a patch in that email that I'm using below. >> >> >> If I run the demo on the 53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a commit, with >> >> debug ipc,network,dns >> log-file /tmp/dirmngr.log >> >> in $work/dirmngr.conf (as requested in >> https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036386.html), I >> get the following in the dirmngr.log file (I've taken the liberty to remove >> the timestamp): >> >> >> dirmngr[12] listening on socket '/tmp/tmp.lktzYbo0YT/S.dirmngr' >> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired >> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired >> dirmngr[13.0] permanently loaded certificates: 129 >> dirmngr[13.0]     runtime cached certificates: 0 >> dirmngr[13.0]            trusted certificates: 129 (129,0,0,0) >> dirmngr[13.0] failed to open cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt': No such file or directory >> dirmngr[13.0] creating directory '/tmp/tmp.lktzYbo0YT/crls.d' >> dirmngr[13.0] new cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt' created >> dirmngr[13.6] handler for fd 6 started >> dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.lktzYbo0YT >> dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.lktzYbo0YT/dirmngr.conf >> dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13 >> dirmngr[13.6] connection from process 1 (0:0) >> dirmngr[13.6] DBG: chan_6 <- GETINFO version >> dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6 >> dirmngr[13.6] DBG: chan_6 -> OK >> dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128 >> dirmngr[13.6] DBG: chan_6 -> OK >> dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com >> dirmngr[13.6] DBG: chan_6 -> OK >> dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4 >> dirmngr[13.6] DBG: dns: libdns initialized >> dirmngr[13.6] DBG: dns: getsrv(_pgpkey-https._tcp.keyserver.ubuntu.com): Server indicated a failure >> dirmngr[13.6] command 'KS_GET' failed: Server indicated a failure >> dirmngr[13.6] DBG: chan_6 -> ERR 219 Server indicated a failure >> dirmngr[13.6] DBG: chan_6 <- BYE >> dirmngr[13.6] DBG: chan_6 -> OK closing connection >> dirmngr[13.6] handler for fd 6 terminated >> >> >> With my patched applied on top, I instead get this: >> >> >> dirmngr[12] listening on socket '/tmp/tmp.1u46BWZXep/S.dirmngr' >> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired >> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired >> dirmngr[13.0] permanently loaded certificates: 129 >> dirmngr[13.0]     runtime cached certificates: 0 >> dirmngr[13.0]            trusted certificates: 129 (129,0,0,0) >> dirmngr[13.0] failed to open cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt': No such file or directory >> dirmngr[13.0] creating directory '/tmp/tmp.1u46BWZXep/crls.d' >> dirmngr[13.0] new cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt' created >> dirmngr[13.6] handler for fd 6 started >> dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.1u46BWZXep >> dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.1u46BWZXep/dirmngr.conf >> dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13 >> dirmngr[13.6] connection from process 1 (0:0) >> dirmngr[13.6] DBG: chan_6 <- GETINFO version >> dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6 >> dirmngr[13.6] DBG: chan_6 -> OK >> dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128 >> dirmngr[13.6] DBG: chan_6 -> OK >> dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com >> dirmngr[13.6] DBG: chan_6 -> OK >> dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4 >> dirmngr[13.6] DBG: dns: libdns initialized >> dirmngr[13.6] DBG: dns: resolve_dns_name(keyserver.ubuntu.com): Server indicated a failure >> dirmngr[13.6] resolving 'keyserver.ubuntu.com' failed: Server indicated a failure >> dirmngr[13.6] number of system provided CAs: 131 >> dirmngr[13.6] DBG: Using TLS library: GNUTLS 3.8.12 >> dirmngr[13.6] DBG: http.c:connect_server: trying name='172.28.0.2' port=3128 >> dirmngr[13.6] DBG: dns: resolve_dns_name(172.28.0.2): Success >> dirmngr[13.6] DBG: http.c:2893:socket_new: object 0x000075ca0435dcb0 for fd 7 created >> dirmngr[13.6] DBG: http.c:proxy:request: >> dirmngr[13.6] DBG: >> CONNECT keyserver.ubuntu.com:443 HTTP/1.1\r\n >> dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com:443\r\n >> dirmngr[13.6] DBG: >> Connection: keep-alive\r\n >> dirmngr[13.6] DBG: http.c:request-header:start_data: >> dirmngr[13.6] DBG: network read: 39/8192 >> dirmngr[13.6] DBG: http.c:response: >> dirmngr[13.6] DBG: >> HTTP/1.1 200 Connection established\r\n >> dirmngr[13.6] http.c:RESP: '' >> dirmngr[13.6] DBG: http.c:request: >> dirmngr[13.6] DBG: >> GET /pks/lookup?op=get&options=mr&search=0x1493269DE61F124AA69A316E3ADF34EBDBB200A4 HTTP/1.0\r\n >> dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com\r\n >> dirmngr[13.6] DBG: http.c:request-header:start_data: >> dirmngr[13.6] DBG: http.c:response: >> dirmngr[13.6] DBG: >> HTTP/1.1 200 OK\r\n >> dirmngr[13.6] http.c:RESP: 'Date: Fri, 11 Sep 2026 15:53:49 GMT' >> dirmngr[13.6] http.c:RESP: 'Server: Hockeypuck/2.2' >> dirmngr[13.6] http.c:RESP: 'Access-Control-Allow-Origin: *' >> dirmngr[13.6] http.c:RESP: 'Content-Type: application/pgp-keys' >> dirmngr[13.6] http.c:RESP: 'Content-Length: 948' >> dirmngr[13.6] http.c:RESP: 'Connection: close' >> dirmngr[13.6] http.c:RESP: '' >> dirmngr[13.6] DBG: chan_6 -> S SOURCE https://keyserver.ubuntu.com:443 >> dirmngr[13.6] DBG: (948 bytes sent via D lines not shown) >> dirmngr[13.6] DBG: chan_6 -> OK >> dirmngr[13.6] DBG: chan_6 <- BYE >> dirmngr[13.6] DBG: chan_6 -> OK closing connection >> dirmngr[13.6] handler for fd 6 terminated >> >> >> The command that was executed: >> >> gpg \ >>      --homedir "$work" \ >>      --batch \ >>      --keyserver hkps://keyserver.ubuntu.com \ >>      --keyserver-options "http-proxy=$http_proxy" \ >>      --recv-keys 1493269DE61F124AA69A316E3ADF34EBDBB200A4 >> >> Where "$work" is a temporary directory and "http_proxy" is the proxy >> server to connect to. >> In a real world scenario, the proxy server will likely also have >> authentication, but I skipped that in the demo to make it easier to follow. >> >> Obviously, they keyserver can be any URL and also the key to fetch. >> Above are just two examples. >> >> >> I've verified that issue exists in 2.4.5, 2.5.22 and on the master branch >> (53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a). >> >> >> -- >> >> Hope this covers all areas. If there is something that I'm missing, please >> don't hesitate to request more details. > > I've been able to see the index a few time over the past 2 weeks, but never > any report about my issue mentioned above. > > @Werner, do you have everything you need to create the bug report and > submit my patch for it? > > Kind regards, > Torbjörn > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From andrewg at andrewg.com Thu Oct 8 11:56:39 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 8 Oct 2026 10:56:39 +0100 Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> Message-ID: On 10/09/2026 09:40, Torbjorn SVENSSON via Gnupg-devel wrote: > Kind regards, > Torbjörn Hi, Torbjörn. (Keyserver hat on) I'd like to better understand the modified control flow here - does this patch skip SRV lookups entirely when a proxy is in use, or will the proxy do it eventually? This has subtle implications... Thanks, A > -- > > * dirmngr/ks-engine-hkp.c (make_host_part): Skip SRV lookups when > using an HTTP proxy. > (send_request): Do not apply keyserver address-family restrictions to > the proxy connection. > -- > > This lets the proxy resolve the destination and avoids restricting the > proxy connection based on the selected keyserver's address family. > > Signed-off-by: Torbjörn SVENSSON > --- >  dirmngr/ks-engine-hkp.c | 10 ++++++++++ >  1 file changed, 10 insertions(+) > > diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c > index 617b01a9f..320cd9057 100644 > --- a/dirmngr/ks-engine-hkp.c > +++ b/dirmngr/ks-engine-hkp.c > @@ -1075,6 +1075,11 @@ make_host_part (ctrl_t ctrl, >        protocol = KS_PROTOCOL_HKP; >      } > > +  /* Let the proxy resolve the destination; an SRV lookup here would > +   * require working local DNS before the proxy can be used.  */ > +  if (ctrl->http_proxy || opt.honor_http_proxy) > +    srvtag = NULL; > + >    if (npth_mutex_lock (&hosttable_lock)) >      log_fatal ("failed to acquire mutex\n"); > > @@ -1256,6 +1261,11 @@ send_request (ctrl_t ctrl, const char *request, > const char *hostportstr, >    http_session_set_log_cb (session, cert_log_cb); >    http_session_set_timeout (session, ctrl->timeout); > > +  /* These flags describe the keyserver, but http_open applies them to > +   * the proxy connection.  Explicitly disabled families are added > below.  */ > +  if (ctrl->http_proxy || opt.honor_http_proxy) > +    httpflags &= ~(HTTP_FLAG_IGNORE_IPv4 | HTTP_FLAG_IGNORE_IPv6); > + >    err = http_open (ctrl, &http, >                     post_cb? HTTP_REQ_POST : HTTP_REQ_GET, >                     request, > -- > 2.43.0 From wk at gnupg.org Thu Oct 8 14:32:07 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Oct 2026 14:32:07 +0200 Subject: [PING]: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: <4527c6cc-f0f9-4f64-afd6-bf2da60fe556@foss.st.com> (Torbjorn SVENSSON via Gnupg-devel's message of "Thu, 8 Oct 2026 10:00:04 +0200") References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> <877bktxko5.fsf@jacob.g10code.de> <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com> <87v78cw36k.fsf@jacob.g10code.de> <538262a6-4553-4a4c-84ae-9899c1798789@foss.st.com> <4527c6cc-f0f9-4f64-afd6-bf2da60fe556@foss.st.com> Message-ID: <871pa01igo.fsf@jacob.g10code.de> On Thu, 8 Oct 2026 10:00, Torbjorn SVENSSON said: >>> dirmngr[13.6] DBG: dns: >>> getsrv(_pgpkey-https._tcp.keyserver.ubuntu.com): Server indicated a >>> failure DNS is required despite of the proxy to handle round-robin DNS resolving in a useful way. There is no support for letting the server resolve the address. You may use Tor, though. Shalom-Salam, 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: From yselkowi at redhat.com Thu Oct 8 14:38:16 2026 From: yselkowi at redhat.com (Yaakov Selkowitz) Date: Thu, 8 Oct 2026 08:38:16 -0400 Subject: [PATCH gpgmepy] Drop Python 2 compatibility Message-ID: <20261008123816.1645575-1-yselkowi@redhat.com> SWIG 4.5 drops compatibility with Python 2, along with the macros that allowed this to build with Python 3. --- gpgme.i | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/gpgme.i b/gpgme.i index 2b4a0c0..fb2f04f 100644 --- a/gpgme.i +++ b/gpgme.i @@ -94,8 +94,8 @@ } $1[i] = PyBytes_AsString(pyVector[i]); } - else if (PyString_Check(o)) - $1[i] = PyString_AsString(o); + else if (PyBytes_Check(o)) + $1[i] = PyBytes_AsString(o); else { PyErr_Format(PyExc_TypeError, "arg %d: list must contain only str or bytes, got %s " @@ -315,10 +315,6 @@ %typemap(in) ssize_t, gpgme_error_t, gpgme_err_code_t, gpgme_err_source_t, gpg_error_t { if (PyLong_Check($input)) $1 = PyLong_AsLong($input); -#if PY_MAJOR_VERSION < 3 - else if (PyInt_Check($input)) - $1 = PyInt_AsLong($input); -#endif else { PyErr_SetString(PyExc_TypeError, "Numeric argument expected"); return NULL; @@ -339,10 +335,6 @@ $1 = PyLong_AsLongLong($input); #else $1 = PyLong_AsLong($input); -#endif -#if PY_MAJOR_VERSION < 3 - else if (PyInt_Check($input)) - $1 = PyInt_AsLong($input); #endif else { PyErr_SetString(PyExc_TypeError, "Numeric argument expected"); @@ -356,10 +348,6 @@ long tmp$argnum; if (PyLong_Check($input)) tmp$argnum = PyLong_AsLong($input); -#if PY_MAJOR_VERSION < 3 - else if (PyInt_Check($input)) - tmp$argnum = PyInt_AsLong($input); -#endif else { PyErr_SetString(PyExc_TypeError, "Numeric argument expected"); -- 2.55.0 From torbjorn.svensson at foss.st.com Thu Oct 8 17:11:45 2026 From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON) Date: Thu, 8 Oct 2026 17:11:45 +0200 Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> Message-ID: Hi Andrew, On 2026-10-08 11:56, Andrew Gallagher via Gnupg-devel wrote: > On 10/09/2026 09:40, Torbjorn SVENSSON via Gnupg-devel wrote: >> Kind regards, >> Torbjörn > > Hi, Torbjörn. > > (Keyserver hat on) > > I'd like to better understand the modified control flow here - does this patch skip SRV lookups entirely when a proxy is in use, or will the proxy do it eventually? This has subtle implications... I'd say that it depends on the proxy server implementation. In the scenario that I've set up in my reproducer (my real use-case also require authentication), the host that is acting as a keyserver client has no means to lookup any public records, including any SRV records. The clients are "air gaped" in the sense that only the proxy server has a way out to the Internet. I understand that some proxy solutions might allow DNS lookup, but the scenario that I have does not. Does this make sense to you? Kind regards, Torbjörn > > Thanks, > A > >> -- >> >> * dirmngr/ks-engine-hkp.c (make_host_part): Skip SRV lookups when >> using an HTTP proxy. >> (send_request): Do not apply keyserver address-family restrictions to >> the proxy connection. >> -- >> >> This lets the proxy resolve the destination and avoids restricting the >> proxy connection based on the selected keyserver's address family. >> >> Signed-off-by: Torbjörn SVENSSON >> --- >>   dirmngr/ks-engine-hkp.c | 10 ++++++++++ >>   1 file changed, 10 insertions(+) >> >> diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c >> index 617b01a9f..320cd9057 100644 >> --- a/dirmngr/ks-engine-hkp.c >> +++ b/dirmngr/ks-engine-hkp.c >> @@ -1075,6 +1075,11 @@ make_host_part (ctrl_t ctrl, >>         protocol = KS_PROTOCOL_HKP; >>       } >> >> +  /* Let the proxy resolve the destination; an SRV lookup here would >> +   * require working local DNS before the proxy can be used.  */ >> +  if (ctrl->http_proxy || opt.honor_http_proxy) >> +    srvtag = NULL; >> + >>     if (npth_mutex_lock (&hosttable_lock)) >>       log_fatal ("failed to acquire mutex\n"); >> >> @@ -1256,6 +1261,11 @@ send_request (ctrl_t ctrl, const char *request, const char *hostportstr, >>     http_session_set_log_cb (session, cert_log_cb); >>     http_session_set_timeout (session, ctrl->timeout); >> >> +  /* These flags describe the keyserver, but http_open applies them to >> +   * the proxy connection.  Explicitly disabled families are added below.  */ >> +  if (ctrl->http_proxy || opt.honor_http_proxy) >> +    httpflags &= ~(HTTP_FLAG_IGNORE_IPv4 | HTTP_FLAG_IGNORE_IPv6); >> + >>     err = http_open (ctrl, &http, >>                      post_cb? HTTP_REQ_POST : HTTP_REQ_GET, >>                      request, >> -- >> 2.43.0 > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From torbjorn.svensson at foss.st.com Thu Oct 8 17:18:42 2026 From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON) Date: Thu, 8 Oct 2026 17:18:42 +0200 Subject: [PING]: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: <871pa01igo.fsf@jacob.g10code.de> References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> <877bktxko5.fsf@jacob.g10code.de> <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com> <87v78cw36k.fsf@jacob.g10code.de> <538262a6-4553-4a4c-84ae-9899c1798789@foss.st.com> <4527c6cc-f0f9-4f64-afd6-bf2da60fe556@foss.st.com> <871pa01igo.fsf@jacob.g10code.de> Message-ID: <556c9b3b-b010-4d33-b707-9803c382c1f7@foss.st.com> Hi Werner, On 2026-10-08 14:32, Werner Koch wrote: > On Thu, 8 Oct 2026 10:00, Torbjorn SVENSSON said: > >>>> dirmngr[13.6] DBG: dns: >>>> getsrv(_pgpkey-https._tcp.keyserver.ubuntu.com): Server indicated a >>>> failure > > DNS is required despite of the proxy to handle round-robin DNS resolving > in a useful way. There is no support for letting the server resolve the > address. You may use Tor, though. Sorry, but Tor is not an alternative here. The problem at hand is that the client has no access to the external system, or even a way to identify where the external system is located, only the proxy server has this access. Thus, the DNS lookup must be deferred to the proxy server. I understand that not all setups works this way and that some might allow DNS lookups, but prevent connections, but it's not how my use-case works. Kind regards, Torbjörn From andrewg at andrewg.com Thu Oct 8 19:39:16 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 8 Oct 2026 18:39:16 +0100 Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> Message-ID: Hi, Torbjörn. On 08/10/2026 16:11, Torbjorn SVENSSON wrote: > I understand that some proxy solutions might allow DNS lookup, but the > scenario that I have does not. Got it, thanks. Would it not be better then to have a separate option for this, rather than modifying the behaviour of all proxied clients whether they need it or not?. We could add heavy caveats to the documentation of this new option ("beware that SRV and round-robin will not work") so that the change in behaviour does not take anyone by surprise. Thanks, A From torbjorn.svensson at foss.st.com Thu Oct 8 19:55:23 2026 From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON) Date: Thu, 8 Oct 2026 19:55:23 +0200 Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> Message-ID: Hi Andrew, On 2026-10-08 19:39, Andrew Gallagher wrote: > Hi, Torbjörn. > > On 08/10/2026 16:11, Torbjorn SVENSSON wrote: >> I understand that some proxy solutions might allow DNS lookup, but the scenario that I have does not. > > Got it, thanks. Would it not be better then to have a separate option for this, rather than modifying the behaviour of all proxied clients whether they need it or not?. We could add heavy caveats to the documentation of this new option ("beware that SRV and round-robin will not work") so that the change in behaviour does not take anyone by surprise. Sure, that could be done, but how would a user understand the difference between a proxy with local DNS lookup and a proxy that does the DNS lookup for the client? Also, not sure why round-robin would not work with a proxy server in the middle. The proxy server will still look up, at least, the A/AAAA record in order to know where to connect. What other type of round-robin are you talking about? If it's the explicit SRV record, then I suppose that will not be quivered... Since there were no response from this list, I managed to avoid the urgency with this workaround: https://github.com/SonarSource/sonarqube-scan-action/commit/6abe0a79df7d9decfbdd73f06e1a7cac404a8562#diff-c8da56253811b1775e3a73059d9b3caedb3c385029c8639c083b823dd0b47d8dR258 It's not pretty, but it avoids the failure in our CI at least. Note, the current version of gpg is still not working in our dev. environment since those computers have the same restriction, i.e., they only have access to the internet via a proxy server. So even with the workaround for our CI, the pain is still real from this bug. So, going back to your question; What would the option be named and how would a user be able to understand the difference? Kind regards, Torbjörn From steffen at sdaoden.eu Thu Oct 8 21:16:12 2026 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 08 Oct 2026 21:16:12 +0200 Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> Message-ID: <20261008191612._mzaRkB3@steffen%sdaoden.eu> Torbjorn SVENSSON via Gnupg-devel wrote in : |On 2026-10-08 19:39, Andrew Gallagher wrote: |> On 08/10/2026 16:11, Torbjorn SVENSSON wrote: |>> I understand that some proxy solutions might allow DNS lookup, but \ |>> the scenario that I have does not. |> |> Got it, thanks. Would it not be better then to have a separate option \ |> for this, rather than modifying the behaviour of all proxied clients \ |> whether they need it or not?. We could add heavy caveats to the document\ |> ation of this new option ("beware that SRV and round-robin will not \ |> work") so that the change in behaviour does not take anyone by surprise. | |Sure, that could be done, but how would a user understand the difference \ |between a proxy with local DNS lookup and a proxy that does the DNS \ |lookup for the client? |Also, not sure why round-robin would not work with a proxy server in \ |the middle. The proxy server will still look up, at least, the A/AAAA \ |record in order to know where to connect. What other type of round-robin \ |are you talking about? |If it's the explicit SRV record, then I suppose that will not be quivere\ |d... | |Since there were no response from this list, I managed to avoid the \ |urgency with this workaround: |https://github.com/SonarSource/sonarqube-scan-action/commit/6abe0a79df7d\ |9decfbdd73f06e1a7cac404a8562#diff-c8da56253811b1775e3a73059d9b3caedb3c38\ |5029c8639c083b823dd0b47d8dR258 |It's not pretty, but it avoids the failure in our CI at least. | |Note, the current version of gpg is still not working in our dev. enviro\ |nment since those computers have the same restriction, i.e., they only \ |have access to the internet via a proxy server. So even with the workaro\ |und for our CI, the pain is still real from this bug. | |So, going back to your question; What would the option be named and \ |how would a user be able to understand the difference? As far as i know, and Werner Koch said something so, gnupg does support wrapping via TOR. Now TOR is practically nothing but SOCKS5 aka RFC 1928, even restricted so, with as far as i know (from a file i downloaded on 2017-05-26) only mostly one extension, and that is: 2. Name lookup As an extension to SOCKS4A and SOCKS5, Tor implements a new command value, "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates a remote lookup of the hostname provided as the target address in the SOCKS request. The reply is either an error (if the address couldn't be resolved) or a success response. In the case of success, the address is stored in the portion of the SOCKS response reserved for remote IP address. (We support RESOLVE in SOCKS4 too, even though it is unnecessary.) For SOCKS5 only, we support reverse resolution with a new command value, "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with an IPv4 address as its target, Tor attempts to find the canonical hostname for that IPv4 record, and returns it in the "server bound address" portion of the reply. (This command was not supported before Tor 0.1.2.2-alpha.) I would think this is pretty easy to do, at least a normal SOCKS5 client can be done in less than 100 lines (you can have code from my MUA, or look at the lynx browser, which has similar). (I was then grep(1)ping gnupg code, and it seems they use that resolve extension.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From wk at gnupg.org Fri Oct 9 09:42:01 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Oct 2026 09:42:01 +0200 Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: (Torbjorn SVENSSON via Gnupg-devel's message of "Thu, 8 Oct 2026 19:55:23 +0200") References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> Message-ID: <87wlrrz5fa.fsf@jacob.g10code.de> On Thu, 8 Oct 2026 19:55, Torbjorn SVENSSON said: > Also, not sure why round-robin would not work with a proxy server in > the middle. The proxy server will still look up, at least, the A/AAAA > record in order to know where to connect. What other type of Many years ago we did it this way but it resulted in a lot of problems becuase the DNS tells you an address but the server is down. Thus you need to wait until a timeout. Thus the better approach is to do the round-robin yourself. This allows to mark dea servers and ignore them and also to pick a random server. There is a lot of code in dirmngr for that and for Tor handling. Adding another path is not easy but can be done. Your contstraints seem to be: - No DNS support for any client behind the proxy. - The proxy accepts only names and does the resolving itself. As Steffen already mentioned we have SOCKS support which alloows for that. However, the Tor (browser or client) internal resolver is pretty limited and thus we don't use that one. What about this: We allow to entirely disable DNS and in this case the whole keyserver selection code is bypassed. This may require a new option. BTW, I had a brief look at your JS code and it seems that you configure keyservers and option with gpg - this is deprecated. All network related configuraion belongs into dirmngr.conf. An override --keyserver when calling gpg is okay but everything else is dirmngr's responsibility. 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: From hi at looping.me Sat Oct 10 10:21:47 2026 From: hi at looping.me (Bryan Lee) Date: Sat, 10 Oct 2026 08:21:47 +0000 Subject: gpg 2.5.24 hangs in exit() after a trustdb error when keyboxd is in use Message-ID: <010001a124e7660a-5fb3dcb4-321e-41fb-b310-3c448249b00d-000000@email.amazonses.com> Hi, With use-keyboxd, gpg never exits after a fatal trustdb error during signature verification. It looks like a reproducer for the atexit lockup that libgpg-error 50f0c56 addressed and ff90817 reverted. GnuPG 2.5.24, libgpg-error 1.61, libgcrypt 1.12.4, libassuan 3.0.2, libksba 1.8.1, npth 1.8 (Homebrew, macOS 27.0.1 on arm64). To reproduce, as a normal user in an empty directory: export GNUPGHOME=$PWD/gh mkdir -m 700 gh && echo use-keyboxd > gh/common.conf gpg --batch --passphrase '' --quick-gen-key test at example.org ed25519 sign never echo hello > msg gpg --batch -u test at example.org --detach-sign msg gpg --verify msg.sig msg cp gh/trustdb.gpg tdb.gpg && chmod 000 tdb.gpg gpg --trustdb-name ./tdb.gpg --verify msg.sig msg The first --verify succeeds and exits. The second prints gpg: Signature made Sat Oct 10 15:04:04 2026 +08 gpg: using EDDSA key 088FF601942A662BE0DDFD2A18289422E990E6C2 gpg: issuer "test at example.org" gpg: Fatal: can't open './tdb.gpg': Permission denied and then hangs, in 5 of 5 runs. In a homedir that uses pubring.kbx instead of keyboxd, the same fatal error exits with status 2 right away. A macOS `sample` of the hung process shows (abridged): main thread: open_db -> gpgrt_log_fatal -> exit -> do_deinit -> _gpgrt_fflush -> _gpgrt_lock_lock second thread: datastream_thread -> _gpgrt_read -> es_readn -> do_read_fbf -> func_fd_read -> read My reading of the code: do_deinit calls _gpgrt_fflush (NULL, 1), which takes every stream's lock, while datastream_thread holds the lock on kcd->fp inside es_read as it waits for keyboxd. At the end of main(), gpg_deinit_default_ctrl releases the keyboxd session (the assuan connection first) before g10_exit (0), so the thread finishes. log_fatal calls exit() without that cleanup, and a g10_exit (2) on an error path skips it too. Continuing the recipe with chmod 400 gh/trustdb.gpg gpg --check-trustdb prints "trustdb: sync failed: Bad file descriptor" and hangs the same way, with do_sync -> g10_exit -> do_deinit on the main thread. Thanks, Bryan From hi at looping.me Sat Oct 10 10:22:00 2026 From: hi at looping.me (Bryan Lee) Date: Sat, 10 Oct 2026 08:22:00 +0000 Subject: gpg: open_db() does not fall back to read-only on EPERM Message-ID: <010001a124e79847-e5a30e08-5dbe-4200-a371-f6409cf5207c-000000@email.amazonses.com> Hi, open_db() in g10/tdbio.c falls back to O_RDONLY only when the O_RDWR open fails with EACCES or EROFS. The macOS sandbox (Seatbelt) refuses writes with EPERM, so a sandboxed gpg that may read the trustdb but not write it hits a fatal error on every verification that consults the trustdb. Could EPERM be added to that check? db_fd = gnupg_open (db_name, O_RDWR | MY_O_BINARY, 0); - if (db_fd == -1 && (errno == EACCES + if (db_fd == -1 && (errno == EACCES || errno == EPERM #ifdef EROFS || errno == EROFS #endif To reproduce with GnuPG 2.5.24 (Homebrew, macOS 27.0.1 on arm64), in an empty directory. sandbox-exec matches resolved paths, hence pwd -P: export GNUPGHOME=$(pwd -P)/gh mkdir -m 700 gh gpg --batch --passphrase '' --quick-gen-key test at example.org ed25519 sign never echo hello > msg gpg --batch -u test at example.org --detach-sign msg gpg --verify msg.sig msg sandbox-exec -p "(version 1)(allow default)(deny file-write* (literal \"$GNUPGHOME/trustdb.gpg\"))" \ gpg --verify msg.sig msg The first --verify succeeds. The sandboxed one ends with gpg: Fatal: can't open '/private/var/folders/.../gh/trustdb.gpg': Operation not permitted and exits with status 2. (With use-keyboxd it hangs instead; I reported that separately as "gpg 2.5.24 hangs in exit() after a trustdb error when keyboxd is in use".) With chmod 400 on gh/trustdb.gpg in place of the sandbox, gpg prints "Note: trustdb not writable" and the usual "Good signature" line. Even with that fallback, a read-only trustdb that is due for a check still fails. In a fresh directory, doing the chmod 400 right after the key generation, before any --verify, gives gpg: Note: trustdb not writable gpg: checking the trustdb gpg: trustdb rec 31: write failed (n=-1): Bad file descriptor gpg: Fatal: .../gh/trustdb.gpg: failed to append a record: Bad file descriptor unless --no-auto-check-trustdb is given, in which case the key shows as [unknown]. Perhaps a read-only open could skip the automatic check and accept stale or unknown validity rather than fail. Thanks, Bryan From torbjorn.svensson at foss.st.com Mon Oct 12 12:25:50 2026 From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON) Date: Mon, 12 Oct 2026 12:25:50 +0200 Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy In-Reply-To: <87wlrrz5fa.fsf@jacob.g10code.de> References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> <87wlrrz5fa.fsf@jacob.g10code.de> Message-ID: <9836cffd-88b2-43c7-a87c-436187d760d4@foss.st.com> On 2026-10-09 09:42, Werner Koch wrote: > On Thu, 8 Oct 2026 19:55, Torbjorn SVENSSON said: > >> Also, not sure why round-robin would not work with a proxy server in >> the middle. The proxy server will still look up, at least, the A/AAAA >> record in order to know where to connect. What other type of > > Many years ago we did it this way but it resulted in a lot of problems > becuase the DNS tells you an address but the server is down. Thus you > need to wait until a timeout. Thus the better approach is to do the > round-robin yourself. This allows to mark dea servers and ignore them > and also to pick a random server. There is a lot of code in dirmngr for > that and for Tor handling. Adding another path is not easy but can be > done. > > Your contstraints seem to be: > > - No DNS support for any client behind the proxy. > - The proxy accepts only names and does the resolving itself. The proxy accepts both names and IPs, but there is no means to lookup an external domain to retrieve the IP. Also, there is only http/https proxies available, no socks proxy! > As Steffen already mentioned we have SOCKS support which alloows for > that. However, the Tor (browser or client) internal resolver is pretty > limited and thus we don't use that one. What about this: > > We allow to entirely disable DNS and in this case the whole keyserver > selection code is bypassed. This may require a new option. I guess one option would be to do what is done today, and if all DNS lookup fails, then, in the proxy case, fall back to let the proxy do the DNS lookup and hope it works better. > BTW, I had a brief look at your JS code and it seems that you configure > keyservers and option with gpg - this is deprecated. All network > related configuraion belongs into dirmngr.conf. An override --keyserver > when calling gpg is okay but everything else is dirmngr's > responsibility. It's not my JS code, I just patched the part that was not working in our CI. The code is owned by Sonar Source (https://www.sonarsource.com/). Kind regards, Torbjörn