From fabio.d.ortoli-galerneau at ens.fr Fri Apr 3 16:14:49 2026 From: fabio.d.ortoli-galerneau at ens.fr (Fabio d'ORTOLI-GALERNEAU) Date: Fri, 03 Apr 2026 16:14:49 +0200 Subject: Problem with verifying signatures in GPGME In-Reply-To: References: Message-ID: Hello, Retrying to send this as a list subscriber this time, hoping it gets somewhere. I'm having a problem with a C++ code using GPGME and I was advised to ask about my problem here. The program is supposed to verify some signatures inputed in it. Basically it works for keys generated with my computer but not for some reason on ones that are not (it returns a 0 summary), even if I tell it to ignore the trust database or to use tofu or whatever trust model. I have tested on two computer and for each the program runs as intended with a key generated on said computer, but not with the key generated by the other computer. I provided attached a toy version of the code that breaks, can you see anything wrong in it or is the problem somewhere else ? Best regards, Fabio -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: text/x-c++ Size: 2285 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Apr 3 19:03:16 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 3 Apr 2026 13:03:16 -0400 Subject: Problem with verifying signatures in GPGME In-Reply-To: References: Message-ID: <37386321-da92-4c0a-9ffe-257edbfe7daa@sixdemonbag.org> > I provided attached a toy version of the code that breaks, can you see > anything wrong in it or is the problem somewhere else ? As a fellow C++ nerd, I highly recommend using GPGMEPP, not GPGME. It'll make your life a lot easier. I have a not-quite-toy example of GPGMEPP up on GitHub: https://github.com/rjhansen/egon It does nothing except pull down Proton Mail keys from their web API and import them into GnuPG. As others have pointed out, there are better ways to do this, so I don't recommend using this tool for that purpose: but as a minimalist app to get someone started with the C++ bindings for GPGME, it might be useful to you. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From tmz at pobox.com Fri Apr 3 19:37:25 2026 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 3 Apr 2026 13:37:25 -0400 Subject: Problem with verifying signatures in GPGME In-Reply-To: <37386321-da92-4c0a-9ffe-257edbfe7daa@sixdemonbag.org> References: <37386321-da92-4c0a-9ffe-257edbfe7daa@sixdemonbag.org> Message-ID: Robert J. Hansen via Gnupg-devel wrote: > I have a not-quite-toy example of GPGMEPP up on GitHub: > > https://github.com/rjhansen/egon > > It does nothing except pull down Proton Mail keys from their web API and > import them into GnuPG. As others have pointed out, there are better ways to > do this, so I don't recommend using this tool for that purpose: but as a > minimalist app to get someone started with the C++ bindings for GPGME, it > might be useful to you. I noticed the README.md for egon says: Egon also uses [GnuPG](https//gnupg.org)?s GnuPG Made Easy library The colon is missing after https, which leads to the link being generated incorrectly. :) -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From kloecker at kde.org Fri Apr 3 21:24:48 2026 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Fri, 03 Apr 2026 21:24:48 +0200 Subject: Problem with verifying signatures in GPGME In-Reply-To: References: Message-ID: <2341963.vFx2qVVIhK@daneel> On Freitag, 3. April 2026 16:14:49 Mitteleurop?ische Sommerzeit Fabio d'ORTOLI-GALERNEAU via Gnupg-devel wrote: > I'm having a problem with a C++ code using GPGME and I was advised to > ask about my problem here. > > The program is supposed to verify some signatures inputed in it. > Basically it works for keys generated with my computer but not for some > reason on ones that are not (it returns a 0 summary), A 0 summary is a perfectly valid summary value. It indicates that none of the conditions for a specific bit apply, i.e. the signature is neither "green" (which mean it's good and the signer is at least fully trusted) nor "red" (signature is bad) nor is the signature or the signing key expired or revoked or ... In other words, a 0 summary means: The signature is good (otherwise the RED bit would be set), but the signer('s key) is not fully trusted. > even if I tell it > to ignore the trust database or to use tofu or whatever trust model. Did you try with trust model "always"? > I provided attached a toy version of the code that breaks, can you see > anything wrong in it or is the problem somewhere else ? I haven't looked at the code, but if you get a 0 summary for good signatures with not fully trusted keys then your code probably works. The only problem seems to be that you didn't expect 0 to be a valid summary value. (You are not the first person being confused about a 0 summary.) Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 265 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Sat Apr 4 09:23:23 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 4 Apr 2026 03:23:23 -0400 Subject: Problem with verifying signatures in GPGME In-Reply-To: References: <37386321-da92-4c0a-9ffe-257edbfe7daa@sixdemonbag.org> Message-ID: <4fa565fd-6a96-492b-85bf-49819c637115@sixdemonbag.org> > The colon is missing after https, which leads to the link > being generated incorrectly. :) Embarrassing error. Thanks for catching it. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From fabio.d.ortoli-galerneau at ens.fr Sat Apr 4 14:58:16 2026 From: fabio.d.ortoli-galerneau at ens.fr (Fabio d'ORTOLI-GALERNEAU) Date: Sat, 04 Apr 2026 14:58:16 +0200 Subject: Problem with verifying signatures in GPGME In-Reply-To: <2341963.vFx2qVVIhK@daneel> References: <2341963.vFx2qVVIhK@daneel> Message-ID: <9bb1f9b7b1f51f1c8bc474414f409bd9@ens.fr> Hello, Thank you for the clarification, the documentation was not fully clear to me to that matter, as I assumed the summary should display something when the signature is valid. If I understand correctly the example code given as the documentation # if ((sig.summary & GPGME_SIGSUM_VALID)) # { # ..do stuff if valid.. # } # else # { # ..do stuff if not fully valid.. # } should be modified as # if (!(sig.summary & GPGME_SIGSUM_RED)) for my purpose ? (which is just checking that a signed message is authentic, I will handle trust matters regarding the author separately). > Did you try with trust model "always"? I did, I checked all the options available as well as the special "no-auto-check-trustdb" flag, which is why I was confused it didn't work for foreign keys. I would also note it would be good to signify on the mailing list page whether there are active moderators for mail coming from non-subscribed authors. I spent a lot of time waiting for previous mails to be sent to the list when I was not yet subscribed. Best regards, Fabio Le 2026-04-03 21:24, Ingo Kl?cker a ?crit?: > On Freitag, 3. April 2026 16:14:49 Mitteleurop?ische Sommerzeit Fabio > d'ORTOLI-GALERNEAU via Gnupg-devel wrote: >> I'm having a problem with a C++ code using GPGME and I was advised to >> ask about my problem here. >> >> The program is supposed to verify some signatures inputed in it. >> Basically it works for keys generated with my computer but not for >> some >> reason on ones that are not (it returns a 0 summary), > > A 0 summary is a perfectly valid summary value. It indicates that none > of the > conditions for a specific bit apply, i.e. the signature is neither > "green" > (which mean it's good and the signer is at least fully trusted) nor > "red" > (signature is bad) nor is the signature or the signing key expired or > revoked > or ... > > In other words, a 0 summary means: The signature is good (otherwise the > RED > bit would be set), but the signer('s key) is not fully trusted. > >> even if I tell it >> to ignore the trust database or to use tofu or whatever trust model. > > Did you try with trust model "always"? > >> I provided attached a toy version of the code that breaks, can you see >> anything wrong in it or is the problem somewhere else ? > > I haven't looked at the code, but if you get a 0 summary for good > signatures > with not fully trusted keys then your code probably works. The only > problem > seems to be that you didn't expect 0 to be a valid summary value. (You > are not > the first person being confused about a 0 summary.) > > Regards, > Ingo > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From brad at comstyle.com Mon Apr 6 03:11:40 2026 From: brad at comstyle.com (Brad Smith) Date: Sun, 5 Apr 2026 21:11:40 -0400 Subject: [PATCH pinentry] build: Fix building Qt pinentry on Sparc Message-ID: build: Fix building Qt pinentry on Sparc On most archs lowercase and uppercase PIC flag does not matter, but it does on Sparc. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index a4f443d..c06496a 100644 --- a/configure.ac +++ b/configure.ac @@ -605,7 +605,7 @@ else AC_DEFINE(PINENTRY_QT5_X11, 0, [pinentry-qt5 shouldn't use x11.]) fi if test "$have_kf5waylandclient" = "yes"; then - PINENTRY_QT5_CFLAGS="$KF5WAYLANDCLIENT_CFLAGS $PINENTRY_QT5_CFLAGS -fpic" + PINENTRY_QT5_CFLAGS="$KF5WAYLANDCLIENT_CFLAGS $PINENTRY_QT5_CFLAGS -fPIC" PINENTRY_QT5_LIBS="$KF5WAYLANDCLIENT_LIBS $PINENTRY_QT5_LIBS" AC_DEFINE(PINENTRY_QT5_WAYLAND, 1, [pinentry-qt5 should use KF5WaylandClient.]) else -- 2.53.0 From peron.clem at gmail.com Mon Apr 13 12:23:55 2026 From: peron.clem at gmail.com (=?UTF-8?q?Cl=C3=A9ment=20P=C3=A9ron?=) Date: Mon, 13 Apr 2026 12:23:55 +0200 Subject: [PATCH/libgpg-error] syscfg: Add Emscript arch. Message-ID: <20260413102459.56270-1-peron.clem@gmail.com> * src/syscfg/lock-obj-pub.lock-obj-pub.wasm32-unknown-emscripten.h: New. * src/Makefile.am (lock_obj_pub): Add it. Signed-off-by: Cl?ment P?ron --- src/Makefile.am | 1 + .../lock-obj-pub.wasm32-unknown-emscripten.h | 23 +++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h diff --git a/src/Makefile.am b/src/Makefile.am index 7fd1d98..42004e1 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -68,6 +68,7 @@ lock_obj_pub = \ syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h \ syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h \ syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.wasm32-unknown-emscripten.h \ syscfg/lock-obj-pub.x86_64-apple-darwin.h \ syscfg/lock-obj-pub.x86_64-unknown-gnu.h \ syscfg/lock-obj-pub.x86_64-unknown-kfreebsd-gnu.h \ diff --git a/src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h b/src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h new file mode 100644 index 0000000..75a1e31 --- /dev/null +++ b/src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h @@ -0,0 +1,23 @@ +## lock-obj-pub.wasm32-unknown-emscripten.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.53.0 From tmz at pobox.com Mon Apr 13 14:33:39 2026 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 13 Apr 2026 08:33:39 -0400 Subject: Request to restore my access to dev.gnupg.org Message-ID: Hi, For the past few weeks or more, my very occasional attempts to fetch GnuPG source or view the ticket tracker have been met with HTTP 429 errors. I am able to view the pages via my mobile connection as well as via Tails / Tor. Using those, I've looked a bit to see who I should contact to request my IP be removed but did not find any direct contacts. I am most definitely not making many requests to the site nor do I have or want any association with AI scrapers (or anything else AI). If it turns out that excessive requests are coming from my IP, I'd very much like to know so I can root out whatever hardware has been compromised. ;) Thanks, -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gniibe at fsij.org Tue Apr 14 04:12:49 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 14 Apr 2026 11:12:49 +0900 Subject: [PATCH/libgpg-error] syscfg: Add Emscript arch. In-Reply-To: <20260413102459.56270-1-peron.clem@gmail.com> References: <20260413102459.56270-1-peron.clem@gmail.com> Message-ID: <874iles31a.fsf@haruna.fsij.org> Hello, Thank you for your challenge. Cl?ment P?ron wrote: > * src/syscfg/lock-obj-pub.lock-obj-pub.wasm32-unknown-emscripten.h: New. > * src/Makefile.am (lock_obj_pub): Add it. Great. I think that your intention is building gpg-error for the host of wasm32-unknown-emscripten. The files are src/syscfg/* are old ones by old method. We moved to the new method generating the header at build time, if possible. We use src/gen-lock-obj.sh for cross compiling. With the patch (to relax a constraint of section .bss): ========================== diff --git a/src/gen-lock-obj.sh b/src/gen-lock-obj.sh index 6e78c5f..a8d9352 100755 --- a/src/gen-lock-obj.sh +++ b/src/gen-lock-obj.sh @@ -73,7 +73,7 @@ pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER; EOF if $CC -c conftest.$ac_ext; then : - ac_mtx_size=$($OBJDUMP -j .bss -t conftest.$ac_objext \ + ac_mtx_size=$($OBJDUMP -t conftest.$ac_objext \ | $AWK $AWK_OPTION ' /mtx$/ { mtx_size = int("0x" $5) } END { print mtx_size }') ========================== The command line: LOCK_ABI_VERSION=1 host=wasm32-unknown-emscripten \ host_alias=wasm32_unknown-emscripten \ CC=emcc OBJDUMP=llvm-objdump ac_ext=c ac_objext=o AWK=gawk ./gen-lock-obj.sh works well for me. (I learned that wasm-objdump is not compatible to GNU objdump, so, I use llvm-objdump here.) So, I'm considering this patch to configure.ac: ========================== diff --git a/configure.ac b/configure.ac index d83e7e5..a339dba 100644 --- a/configure.ac +++ b/configure.ac @@ -632,7 +632,7 @@ if test x"$gl_use_threads" = xno; then AC_MSG_NOTICE([generated src/lock-obj-pub.native.h for $host]) elif test x$cross_compiling = xyes; then case $host in - *-*-gnu* | *-*-linux-gnu* | *-*-linux-musl*) + *-*-gnu* | *-*-linux-gnu* | *-*-linux-musl* | wasm*) AC_CHECK_TOOL(OBJDUMP, [objdump]) if test -n "$OBJDUMP"; then lock_obj_h_generated=yes ========================== With those patches, by supplying CC=emcc OBJDUMP=llvm-objdump to configure, we will be able to build for the host of wasm32_unknown-emscripten. --