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. -- From devnoname120 at gmail.com Sat Apr 18 18:53:39 2026 From: devnoname120 at gmail.com (devnoname120) Date: Sat, 18 Apr 2026 18:53:39 +0200 Subject: LD_PRELOAD causes stack smashing error in gpg Message-ID: <21fdd26a-bb6f-4454-a110-b95c975681c9@Spark> For some reason gpg doesn?t seem to like when a RegEx is compiled in the constructor of a preloaded library. I haven?t seen this happen in other software, any ideas what could be causing this? Minimum repo: File `/tmp/repo.c`: ```c #define _GNU_SOURCE #include __attribute__((constructor)) static void init(void) { ?regex_t regex; ?regcomp(®ex, "", 0); } ``` Shell: ```sh gcc -shared -fPIC -o /tmp/repro.so /tmp/repro.c export LD_PRELOAD=/tmp/repro.so gpg --list-keys ``` Output: ``` *** stack smashing detected ***: terminated Aborted ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Mon Apr 20 06:26:38 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 20 Apr 2026 13:26:38 +0900 Subject: LD_PRELOAD causes stack smashing error in gpg In-Reply-To: <21fdd26a-bb6f-4454-a110-b95c975681c9@Spark> References: <21fdd26a-bb6f-4454-a110-b95c975681c9@Spark> Message-ID: <87pl3ul0jl.fsf@haruna.fsij.org> Hello, devnoname120 wrote: > For some reason gpg doesn?t seem to like when a RegEx is compiled in > the constructor of a preloaded library. Please see: https://dev/gnupg.org/T7668 We use the internal replacement of regex_* routines for GnuPG, so that we can support OS without regexp, and we can avoid interoperability problem among different implementations. The bug you encountered is a problem of using ABI difference of regex_*. The ones in system libc and the ones in the internal replacement are not ABI same, but use different regexp_t. GnuPG 2.6 has a fix (replacing the symbols with a prefix) for no conflict. BTW, today, I modified the wrong prefix in master. -- From koray.fra at gmail.com Tue Apr 21 01:09:17 2026 From: koray.fra at gmail.com (koraynilay) Date: Tue, 21 Apr 2026 01:09:17 +0200 Subject: Info before updating/fixing italian translation Message-ID: Hello, I'm looking at fixing some strings in the italian translation of GnuPG (po/it.po) but I noticed that when running make all translations get rearranged, would it be better to first make a commit like "resync translation(s)" and then do my modifications after, or would it be better to keep my changes before the po(s) get changed during make? Furthermore, if the "resync" commit is the better way, would it be best to commit all languages' files or only the one I'm interested in? Thanks in advance. P.S. sorry if it's the wrong list or there are other mistakes, I'm still new to this type of contribution style ahah. Best, koraynilay From wk at gnupg.org Tue Apr 21 12:28:09 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Apr 2026 12:28:09 +0200 Subject: [Announce] [Security fixes] Libgcrypt 1.12.2, 1.11.3, 1.10.x released Message-ID: <87jyu038w6.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of couple of new Libgcrypt versions: 1.12.2, 1.11.3, and 1.10.4 . It is suggested to use 1.12.2 which is fully compatible with all earlier versions. This version fixes a security bug [T8211] which can be used used to mount a DoS using ECDH encryption (with NIST, Brainpool, X448, or X25519 curves). Note that GnuPG versions since 2.5.7 are not affected by this bug due to the use of a different encryption API. Another security bug [T8208] was fixed in the Dilithium signing algorithm which is available since version 1.12.0. Noteworthy changes in version 1.12.2 (2026-04-15) ==================================== * Bug fixes: - Fix possible ECDH buffer overwrite with zeroes. [T8211] - Add a missing bounds check to the Dilithium context handling. Reported by Calif.io in collaboration with Claude and Anthropic Research. [T8208] - Add point validation when using the new KEM interface. [T8212] * Other: - Fix the dead-code of stronger_key_check for RSA. [T8171] For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T8114 . However, due to an ongoing AI scraper DDoS the site might not be reachable at all times or from all IPs. Noteworthy changes in version 1.11.3 (2026-04-21) ==================================== * Bug fixes: - Fix possible ECDH buffer overwrite with zeroes. [T8211] - Add point validation when using the new KEM interface. [T8212] - Fix compiler error on NetBSD. [T7633] - mceliece6688128f: Fix stack overflow crash on win64/wine [rCb17ed8d1af] - Apply a Kyber patch from upstream. [rC5ba143d51f] - Use CSIDL_COMMON_APPDATA instead of /etc on Windows. [rC995b870fd2] - Use secure MPI in _gcry_mpi_assign_limb_space. [rC520c699c82] - Fix a regression with disabled public-key algo for FIPS. [T7338,rCc6e0658004] * Other: - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN. [T7889] - Add stack burning for PQC algorithms. [rC289c0a596f] Release-info: https://dev.gnupg.org/T8232 Noteworthy changes in version 1.10.4 (2026-04-21) ==================================== NOTE: The 1.10 series reaches end-of-life in 6 weeks. * Bug fixes: - Fix possible ECDH buffer overwrite with zeroes. [T8211] - Fix AESWRAP padding length check. [T7130] * Other: - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN. [T7889] Release-info: https://dev.gnupg.org/T8233 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.gz.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.gz.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.12.2.tar.bz2 you would use this command: gpg --verify libgcrypt-1.12.2.tar.bz2.sig libgcrypt-1.12.2.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. - If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file libgcrypt-1.12.2.tar.bz2, you run the command like this: sha1sum libgcrypt-1.12.2.tar.bz2 and check that the output matches the first line from the this list: 7b8ff21966a0b6e7a735466b9b9b55d9dac9fa87 libgcrypt-1.12.2.tar.bz2 a1b1d5561e7b743e7e4460a49015053da1901124 libgcrypt-1.12.2.tar.gz d252f6b0a62fcacb8f82bcb61440b25d698a0a05 libgcrypt-1.11.3.tar.bz2 a89b597965a76bfbe0ad11e3d6153c3709c0b07e libgcrypt-1.11.3.tar.gz d824efa873ac210e84573564df4a99f4cd5cdf77 libgcrypt-1.10.4.tar.bz2 5a5bb8d4dd69a2c7828dbf31b12df5e21e604971 libgcrypt-1.10.4.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T8114 for updated information. Please also consult the archive of the gcrypt-devel mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html . We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html . Please see https://gnupg.org/documentation/security.html for information on how to report security issues and for our threat model. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have now established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helping with donations. *Thank you all* Your Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel'at'gnupg.org mailing list. * List of Release Signing Keys: To guarantee that a downloaded version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these five keys: ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) brainpoolP384r1 2026-02-23 [SC] [expires: 2034-02-23] 1493 269D E61F 124A A69A 316E 3ADF 34EB DBB2 00A4 GnuPG.com (Release Signing Key 2026) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. -- 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: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From devm23k73ju29h3r at dolce-energy.com Thu Apr 23 20:46:36 2026 From: devm23k73ju29h3r at dolce-energy.com (devm23k73ju29h3r at dolce-energy.com) Date: Thu, 23 Apr 2026 20:46:36 +0200 Subject: question to crypto experts Message-ID: <23461c76-ee04-4a1e-9717-695a04d0c94a@dolce-energy.com> Hi, not directly related to gpg... AFAIK short messages are weak to build a strong message, but my question is related to kbdx files, that are widely used by password managers the specs are available at : https://keepass.info/help/kb/kdbx.html basically, this is an encrypted xml file with an header my question is : knowing that the file will begin with " References: <23461c76-ee04-4a1e-9717-695a04d0c94a@dolce-energy.com> Message-ID: <82b21c55-4876-4c6b-815f-be526aba6541@sixdemonbag.org> > basically, this is an encrypted xml file with an header > > my question is : knowing that the file will begin with " make it weak to decryption attack, and can it be used to get the key? This is called a "known plaintext" attack. All modern encryption algorithms are highly resistant to known plaintext attacks. GnuPG as a whole is highly resistant to known plaintext attacks. -------------- 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 wk at gnupg.org Fri Apr 24 13:52:45 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Apr 2026 13:52:45 +0200 Subject: [Announce] GnuPG 2.5.19 released Message-ID: <87o6j8zib6.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: Version 2.5.19. This release adds a few new features and fixes a couple of bugs. The main features in the 2.5 series are improvements for 64 bit Windows and the introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. Note that the old 2.4 series reaches end-of-life in just two months. Thus update to 2.5.19 in time. As always with GnuPG new versions are fully compatible with previous versions. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.19 (2026-04-24) ================================================= [compared to version 2.5.18] * New and extended features: - gpg: New option --use-ocb-sym. [rGccdcdfbb37] - gpg: New options --show-[only-]session-hash. [rGecd0f7afa1] - gpgsm: Allow cipher mode to be part of the algo given to the --cipher-algo option. [T3979] - gpgsm: Emit more details when failing to check a crlDP. [T8221] - agent: Improve pinentry behavior and texts in smartcard context. [T6425] - dirmngr: New keyword "clear" for --keyserver. [rG2ab4cba36c] * Bug fixes: - gpg: Fix edge case in --refresh-keys. [T8197] - gpg: Don't call gcry_kdf_derive with empty passphrase. [T7739] - gpgsm: Skip the optional PKCS#12 PBES2 keyLength parameter to allow import of recently issued certificates by the German Telekom. [rGc8c9604bba] - gpgsm: Fix a bug so that a certificate can be signed using a different algo. [rG66fdafab3c] - gpgsm: Make GCM fully compliant in de-vs mode. [rG04fd775fce] - gpgsm: Add a certificate chain check for de-vs compliance. [T8188] - gpgsm: Show rsaPSS certificates as de-vs compliant in listings. [T8222] - agent: Rework the trustlist reading code to finally allow a trustlist.txt with a missing trailing LF. [T8078] - ssh: Fix RSA padding in signature handling. [T7882,T8202] - gpgtar: Fix -C (--directory) to check the output directory. [T8159] * Other changes: - agent: Raise an error when p >= q for RSA keys to detect incorrect generated *PGP keys. [T8171] Release-info: https://dev.gnupg.org/T7998 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary file server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.19.tar.bz2 (8127k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.19.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.19_20260424.exe (5627k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.19_20260424.exe.sig The source used to build this installer for 64-bit Windows is available as https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.19_20260424.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.19_20260424.tar.xz.sig This source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README. Debian Packages =============== We also provide Debian style packages for a couple of Debian variants. See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu to switch to other distros/releases. If you encounter packaging problems please report them to the gnupg-devel mailing list. Due to the holidays it may take a few days until the packages are available. Windows Installer ================= A new Version of Gpg4win is in planning. For those who are affected by one of the now fixed bugs, it is possible to install the simple Windows installer mentioned above on top of gpg4win 5.0.1. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.19.tar.bz2 you would use this command: gpg --verify gnupg-2.5.19.tar.bz2.sig gnupg-2.5.19.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.19.tar.bz2, you run the command like this: sha1sum gnupg-2.5.19.tar.bz2 and check that the output matches the next line: dbe9ce2aca9d553ed4367692575cee15204a95a6 gnupg-2.5.19.tar.bz2 e4de189d1310893b2f8e565781d25093944b883e gnupg-w32-2.5.19_20260424.tar.xz a2b9b2d0ad979209e1c74f28ff910ce6f97f0e41 gnupg-w32-2.5.19_20260424.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, Dutch, French, Georgian, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. If you are using cleartext signatures in your application please read https://gnupg.org/blog/20251226-cleartext-signatures.html and maybe https://gnupg.com/20260122-39C3_reply_gpg_fail.html In case of build problems specific to this release please first check https://dev.gnupg.org/T7998 for updated information. We are sorry that due to ongoing DoS on this service, you may end up at a "is under maintenance page". Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. A team of full-time employed developers and contractors are working exclusively on GnuPG and related software like Libgcrypt, GPGME, Kleopatra, Okular, and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. * List of Release Signing Keys: To guarantee that a downloaded version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these five keys: ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) brainpoolP384r1 2026-02-23 [SC] [expires: 2034-02-23] 1493 269D E61F 124A A69A 316E 3ADF 34EB DBB2 00A4 GnuPG.com (Release Signing Key 2026) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From bernhard at intevation.de Fri Apr 24 17:07:01 2026 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 24 Apr 2026 17:07:01 +0200 Subject: PATCH gnupg: doc:gpg.texi fix minor typo in --use-ocb-sym desc Message-ID: <202604241707.01446.bernhard@intevation.de> :) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-doc-gpg.texi-fix-minor-typo-in-use-ocb-sym-desc.patch Type: text/x-diff Size: 833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From devm23k73ju29h3r at dolce-energy.com Sat Apr 25 18:59:31 2026 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Sat, 25 Apr 2026 18:59:31 +0200 Subject: question to crypto experts In-Reply-To: <82b21c55-4876-4c6b-815f-be526aba6541@sixdemonbag.org> References: <23461c76-ee04-4a1e-9717-695a04d0c94a@dolce-energy.com> <82b21c55-4876-4c6b-815f-be526aba6541@sixdemonbag.org> Message-ID: <7c972b3a-1541-48ad-8608-af1a319494a4@dolce-energy.com> thanks, I learned something :) ok, it's interesting, I wonder how they achieve it, but seems that it's safe! Le 24/04/2026 ? 00:10, Robert J. Hansen a ?crit?: > "known plaintext" attack From rjh at sixdemonbag.org Sun Apr 26 03:39:16 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 25 Apr 2026 21:39:16 -0400 Subject: question to crypto experts In-Reply-To: <7c972b3a-1541-48ad-8608-af1a319494a4@dolce-energy.com> References: <23461c76-ee04-4a1e-9717-695a04d0c94a@dolce-energy.com> <82b21c55-4876-4c6b-815f-be526aba6541@sixdemonbag.org> <7c972b3a-1541-48ad-8608-af1a319494a4@dolce-energy.com> Message-ID: <02f1081b-6a56-4b00-962d-2de3ac27f339@sixdemonbag.org> > ok, it's interesting, I wonder how they achieve it, but seems that it's > safe! https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle If you design the system from the ground up with the assumption the attacker gets to choose everything except the key, that's a very very strong design. Compared to that, the situation of "the attacker gets to know some of the plaintext" is nothing at all. Or, put simply: If you play the cryptosystem design game on hard mode, easy mode challenges like "resistant to known plaintext attacks" get overcome for free. -------------- 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 ametzler at bebt.de Mon Apr 27 18:26:52 2026 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 27 Apr 2026 18:26:52 +0200 Subject: Please tag libgpg-error 1.60 in GIT Message-ID: Hello, could you pleae push the 1.60 tag to the repository? TIA, cu Andreas -- "You people are noisy," Nia said. I made the gesture of agreement.