From wk at gnupg.org Tue Jul 2 16:02:04 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2024 16:02:04 +0200 Subject: [Announce] Libgcrypt 1.11.0 released In-Reply-To: <87h6dbcl99.fsf@ra.horus-it.com> (Ralph Seichter via Gnupg-devel's message of "Sun, 30 Jun 2024 02:44:18 +0200") References: <87le31nn7k.fsf@jacob.g10code.de> <87h6dbcl99.fsf@ra.horus-it.com> Message-ID: <87v81nhoyr.fsf@jacob.g10code.de> Hi! See https://dev.gnupg.org/T7170 for a fix. Sorry, I only now linked this to the release ticket T7165. 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: 247 bytes Desc: not available URL: From ralph at ml.seichter.de Tue Jul 2 18:47:08 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 02 Jul 2024 18:47:08 +0200 Subject: [Announce] Libgcrypt 1.11.0 released In-Reply-To: <87v81nhoyr.fsf@jacob.g10code.de> References: <87le31nn7k.fsf@jacob.g10code.de> <87h6dbcl99.fsf@ra.horus-it.com> <87v81nhoyr.fsf@jacob.g10code.de> Message-ID: <871q4b3fn7.fsf@ra.horus-it.com> * Werner Koch via Gnupg-devel: > See https://dev.gnupg.org/T7170 for a fix. Thank you, Werner. I am currently using the following patch: --- a/acinclude.m4 2024-03-28 11:07:27 +++ b/acinclude.m4 2024-07-02 17:34:53 @@ -73,6 +73,9 @@ i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp) ac_cv_sys_symbol_underscore=yes ;; + *-apple-darwin*) + ac_cv_sys_symbol_underscore=yes + ;; *) if test "$cross_compiling" != yes; then tmp_do_check="yes" I have succesfully built binaries for both aarch64-apple-darwin and x86_64-apple-darwin, plus unified binaries based on the two, but I don't have access to any ARM based Mac for testing. The x86 version seems to work as expected. -Ralph From ralph at ml.seichter.de Fri Jul 5 21:04:10 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Fri, 05 Jul 2024 21:04:10 +0200 Subject: libassuan duplicate symbol (Re: Quick heads up: GnuPG 2.5.0 is now available) In-Reply-To: <875xtjhmdc.fsf@jacob.g10code.de> References: <875xtjhmdc.fsf@jacob.g10code.de> Message-ID: <8734onirth.fsf@ra.horus-it.com> * Werner Koch via Gnupg-users: > Latest released libaries are required. Yeah, about that: I had trouble building libgpg-error 1.50 on macOS, but found a workaround in https://dev.gnupg.org/T7169 , so that's good. Alas, I have not yet found a workaround for libassuan-3.0.1: libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libassuan.9.dylib .libs/libassuan_la-assuan.o .libs/libassuan_la-context.o .libs/libassuan_la-system.o .libs/libassuan_la-debug.o .libs/libassuan_la-conversion.o .libs/libassuan_la-sysutils.o .libs/libassuan_la-client.o .libs/libassuan_la-server.o .libs/libassuan_la-assuan-error.o .libs/libassuan_la-assuan-buffer.o .libs/libassuan_la-assuan-handler.o .libs/libassuan_la-assuan-inquire.o .libs/libassuan_la-assuan-listen.o .libs/libassuan_la-assuan-pipe-server.o .libs/libassuan_la-assuan-socket-server.o .libs/libassuan_la-assuan-pipe-connect.o .libs/libassuan_la-assuan-socket-connect.o .libs/libassuan_la-assuan-uds.o .libs/libassuan_la-assuan-logging.o .libs/libassuan_la-assuan-socket.o .libs/libassuan_la-system-posix.o .libs/libassuan_la-assuan-io.o .libs/memrchr.o -L/tmp/build-1720202282/x86_64-dist/lib /tmp/build-1720202282/x86_64-dist/lib/libgpg-error.dylib -arch x86_64 -m64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.12 -O0 -arch x86_64 -install_name /tmp/build-1720202282/x86_64-dist/lib/libassuan.9.dylib -compatibility_version 10 -current_version 10.1 duplicate symbol '___sputc' in: /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-server.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-error.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-debug.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-sysutils.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-client.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-listen.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-context.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-buffer.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-conversion.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-socket-server.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-pipe-server.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-inquire.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-pipe-connect.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-system.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-socket-connect.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-io.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-uds.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-handler.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-system-posix.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-logging.o /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-socket.o ld: 1 duplicate symbols clang: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: *** [libassuan.la] Error 1 Do you guys have any suggestions how to overcome this issue? -Ralph From noloader at gmail.com Sat Jul 6 00:26:20 2024 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 5 Jul 2024 18:26:20 -0400 Subject: libassuan duplicate symbol (Re: Quick heads up: GnuPG 2.5.0 is now available) In-Reply-To: <8734onirth.fsf@ra.horus-it.com> References: <875xtjhmdc.fsf@jacob.g10code.de> <8734onirth.fsf@ra.horus-it.com> Message-ID: On Fri, Jul 5, 2024 at 3:04?PM Ralph Seichter via Gnupg-devel wrote: > > * Werner Koch via Gnupg-users: > > > Latest released libaries are required. > > Yeah, about that: I had trouble building libgpg-error 1.50 on macOS, but > found a workaround in https://dev.gnupg.org/T7169 , so that's good. Alas, > I have not yet found a workaround for libassuan-3.0.1: > > libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libassuan.9.dylib .libs/libassuan_la-assuan.o .libs/libassuan_la-context.o .libs/libassuan_la-system.o .libs/libassuan_la-debug.o .libs/libassuan_la-conversion.o .libs/libassuan_la-sysutils.o .libs/libassuan_la-client.o .libs/libassuan_la-server.o .libs/libassuan_la-assuan-error.o .libs/libassuan_la-assuan-buffer.o .libs/libassuan_la-assuan-handler.o .libs/libassuan_la-assuan-inquire.o .libs/libassuan_la-assuan-listen.o .libs/libassuan_la-assuan-pipe-server.o .libs/libassuan_la-assuan-socket-server.o .libs/libassuan_la-assuan-pipe-connect.o .libs/libassuan_la-assuan-socket-connect.o .libs/libassuan_la-assuan-uds.o .libs/libassuan_la-assuan-logging.o .libs/libassuan_la-assuan-socket.o .libs/libassuan_la-system-posix.o .libs/libassuan_la-assuan-io.o .libs/memrchr.o -L/tmp/build-1720202282/x86_64-dist/lib /tmp/build-1720202282/x86_64-dist/lib/libgpg-error.dylib -arch x86_64 -m64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.12 -O0 -arch x86_64 -install_name /tmp/build-1720202282/x86_64-dist/lib/libassuan.9.dylib -compatibility_version 10 -current_version 10.1 > > duplicate symbol '___sputc' in: > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-server.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-error.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-debug.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-sysutils.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-client.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-listen.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-context.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-buffer.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-conversion.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-socket-server.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-pipe-server.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-inquire.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-pipe-connect.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-system.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-socket-connect.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-io.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-uds.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-handler.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-system-posix.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-logging.o > /private/tmp/build-1720202282/x86_64-build/libassuan-3.0.1/src/.libs/libassuan_la-assuan-socket.o > ld: 1 duplicate symbols > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[4]: *** [libassuan.la] Error 1 > > Do you guys have any suggestions how to overcome this issue? It smells a lot like . Was everything built with `-stdlib=libc++`? libc++ is LLVM's standard C++ library. libstdc++ is GNU's standard C++ library. It sounds like both libraries are trying to provide the symbol. Another interesting discussion is at . I've never seen the option they discuss, though. (adding the `-system-libX` option). Jeff From wk at gnupg.org Mon Jul 8 11:30:01 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Jul 2024 11:30:01 +0200 Subject: libassuan duplicate symbol In-Reply-To: <8734onirth.fsf@ra.horus-it.com> (Ralph Seichter via Gnupg-devel's message of "Fri, 05 Jul 2024 21:04:10 +0200") References: <875xtjhmdc.fsf@jacob.g10code.de> <8734onirth.fsf@ra.horus-it.com> Message-ID: <87tth0fcyu.fsf_-_@jacob.g10code.de> On Fri, 5 Jul 2024 21:04, Ralph Seichter said: > found a workaround in https://dev.gnupg.org/T7169 , so that's good. Alas, > I have not yet found a workaround for libassuan-3.0.1: > > libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o > .libs/libassuan.9.dylib .libs/libassuan_la-assuan.o Take care: The SO name changed for libassuan. Do you have an old version also installed (should be libassuan.0.dylib) and this is accidently used in the build? 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: 247 bytes Desc: not available URL: From ralph at ml.seichter.de Sun Jul 7 03:44:39 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Sun, 07 Jul 2024 03:44:39 +0200 Subject: libassuan duplicate symbol In-Reply-To: References: <875xtjhmdc.fsf@jacob.g10code.de> <8734onirth.fsf@ra.horus-it.com> Message-ID: <87y16eht6g.fsf@ra.horus-it.com> * Jeffrey Walton: > Was everything built with `-stdlib=libc++`? libc++ is LLVM's standard > C++ library. libstdc++ is GNU's standard C++ library. It sounds like > both libraries are trying to provide the symbol. I found neither string "libc++" nor "libstdc++" in the full build logs [1]. That log shows all library builds up to and including libassuan 3.0.2. I use Xcode 15.4, which I should have mentioned right away: $ xcodebuild -version Xcode 15.4 Build version 15F31d The same build process succeeds with libassuan 2.5.7 and libgpg-error 1.49, by the way. Bumping these libraries to versions 3.0.2 and 1.50, respectively, to satisfy the requirements of GnuPG 2.5.0, were the only changes I made. That leads me to the hypothesis that modifications in one or both of these libraries are causing problems. The libgpg-error build works for 1.49 and 1.50, but as mentioned in a previous message I had to incorporate a small patch. One can find my complete build process on SourceForge [2]. [1] https://seichter.de/tmp/build-1720202282.log [2] https://sourceforge.net/p/gpgosx/source/ci/v2.5.0/tree/ -Ralph From wk at gnupg.org Mon Jul 8 12:13:42 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Jul 2024 12:13:42 +0200 Subject: [Announce] GnuPG 2.5.0 released for public testing Message-ID: <87cynofay1.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.0. This release is the first of a series of public testing releases eventually leading to a new stable version 2.6. The main features in the 2.6 series are improvements for 64 bit Windows and the introduction of a PQC algorithms. 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. The risk of regressions is thus lower than it was with the introduction of 2.4 in 2021. 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.0 (2024-07-05) ================================================ [compared to version 2.4.5] * gpg: Support composite Kyber+ECC public key algorithms. This is experimental due to the yet outstanding FIPS-203 specification. [T6815] * gpg: Allow algo string "pqc" for --quick-gen-key. [rG12ac129a70] * gpg: New option --show-only-session-key. [rG1695cf267e] * gpg: Print designated revokers also in non-colon listing mode. [rG9d618d1273] * gpg: Make --with-sig-check work with --show-key in non-colon listing mode. [rG0c34edc443] * tpm: Rework error handling and fix key import [T7129, T7186] * Varous fixes to improve robustness on 64 bit Windows. [T7139] Changes which will also show up in the firthcoming 2.4.6: * gpg: New command --quick-set-ownertrust. [rG967678d972] * gpg: Indicate disabled keys in key listings and add list option "show-ownertrust". [rG2a0a706eb2] * gpg: Make sure a DECRYPTION_OKAY is never issued for a bad OCB tag. [T7042] * gpg: Do not allow to accidently set the RENC usage. [T7072] * gpg: Accept armored files without CRC24 checksum. [T7071] * gpg: New --import-option "only-pubkeys". [T7146] * gpg: Repurpose the AKL mechanism "ldap" to work like the keyserver mechnism but only for LDAP keyservers. [rG068ebb6f1e] * gpg: ADSKs are now configurable for new keys. [T6882] * gpgsm: Emit user IDs with an empty Subject also in colon mode. [T7171] * agent: Consider an empty pattern file as valid. [rGc27534de95] * agent: Fix error handling of READKEY. [T6012] * agent: Avoid random errors when storing key in ephemeral mode. [T7129, rGfdc5003956] * agent: Make "SCD DEVINFO --watch" more robust. [T7151] * scd: Improve KDF data object handling for OpenPGP cards. [T7058] * scd: Avoid buffer overrun with more than 16 PC/SC readers. [T7129, rG4c1b007035] * scd: Fix how the scdaemon on its pipe connection finishes. [T7160] * gpgconf: Check readability of some files with -X and change its output format. [rG98e287ba6d] * gpg-mail-tube: New tool to apply PGP/MIME encryption to a mail. [rG28a080bc9f] * Fix some uninitialized variables and double frees in error code paths. [T7129] Release-info: https://dev.gnupg.org/T7189 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.0.tar.bz2 (7946k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.0.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.0_20240705.exe (5297k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.0_20240705.exe.sig The source used to build this Windows installer can be found in the same directory with a ".tar.xz" suffix. Note that these Windows binaries are exceptionally not AuthentiCode signed and not well tested. 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.0.tar.bz2 you would use this command: gpg --verify gnupg-2.5.0.tar.bz2.sig gnupg-2.5.0.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.0.tar.bz2, you run the command like this: sha1sum gnupg-2.5.0.tar.bz2 and check that the output matches the next line: eb33777782b1d5c766f449a26126ab1d9cef25ef gnupg-2.5.0.tar.bz2 bc4ff3b8b1b850eb18068f116d9d134583fdd92e gnupg-w32-2.5.0_20240705.tar.xz 35caef9965b10eed53b8d09b48fba5d1479f3512 gnupg-w32-2.5.0_20240705.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, 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. In case of build problems specific to this release please first check https://dev.gnupg.org/T7189 for updated information. In particular you may want to apply the Speedo patch mentioned there to avoid a glitch with building the bzip2 library. 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. 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 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. List of Release Signing Keys: To guarantee that a downloaded GnuPG 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 four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) 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. -- 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: 247 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 ralph at ml.seichter.de Mon Jul 8 20:46:32 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Mon, 08 Jul 2024 20:46:32 +0200 Subject: libassuan duplicate symbol In-Reply-To: <87tth0fcyu.fsf_-_@jacob.g10code.de> References: <875xtjhmdc.fsf@jacob.g10code.de> <8734onirth.fsf@ra.horus-it.com> <87tth0fcyu.fsf_-_@jacob.g10code.de> Message-ID: <87ed83u3g7.fsf@ra.horus-it.com> * Werner Koch via Gnupg-devel: > The SO name changed for libassuan. Do you have an old version also > installed (should be libassuan.0.dylib) and this is accidently used > in the build? There was an older libassuan version in /opt/local/lib, courtesy of dependencies pulled in by MacPorts' "wget" port: ---> Computing dependencies for wget The following dependencies will be installed: gnupg2 gpgme libassuan Although the old library did not seem to be referenced by my own build, I removed the listed ports including libassuan, just to be sure. Alas, my build still breaks due to duplicate symbols. I don't see any mention of the old name in my build logs (line breaks added for improved readability): $ grep -E .libassuan\..+\.dylib' intel-2.5.0.log libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libassuan.9.dylib .libs/libassuan_la-assuan.o .libs/libassuan_la-context.o .libs/libassuan_la-system.o .libs/libassuan_la-debug.o .libs/libassuan_la-conversion.o .libs/libassuan_la-sysutils.o .libs/libassuan_la-client.o .libs/libassuan_la-server.o .libs/libassuan_la-assuan-error.o .libs/libassuan_la-assuan-buffer.o .libs/libassuan_la-assuan-handler.o .libs/libassuan_la-assuan-inquire.o .libs/libassuan_la-assuan-listen.o .libs/libassuan_la-assuan-pipe-server.o .libs/libassuan_la-assuan-socket-server.o .libs/libassuan_la-assuan-pipe-connect.o .libs/libassuan_la-assuan-socket-connect.o .libs/libassuan_la-assuan-uds.o .libs/libassuan_la-assuan-logging.o .libs/libassuan_la-assuan-socket.o .libs/libassuan_la-system-posix.o .libs/libassuan_la-assuan-io.o .libs/memrchr.o -L/tmp/gpgosx-2.5.0/x86_64-dist/lib /tmp/gpgosx-2.5.0/x86_64-dist/lib/libgpg-error.dylib -arch x86_64 -m64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.12 -O0 -arch x86_64 -install_name /tmp/gpgosx-2.5.0/x86_64-dist/lib/libassuan.9.dylib -compatibility_version 10 -current_version 10.1 See https://seichter.de/tmp/intel-2.5.0.log for the complete, unedited build log. -Ralph From noloader at gmail.com Mon Jul 8 22:36:47 2024 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 8 Jul 2024 16:36:47 -0400 Subject: libassuan duplicate symbol In-Reply-To: <87ed83u3g7.fsf@ra.horus-it.com> References: <875xtjhmdc.fsf@jacob.g10code.de> <8734onirth.fsf@ra.horus-it.com> <87tth0fcyu.fsf_-_@jacob.g10code.de> <87ed83u3g7.fsf@ra.horus-it.com> Message-ID: On Mon, Jul 8, 2024 at 2:46?PM Ralph Seichter via Gnupg-devel wrote: > > * Werner Koch via Gnupg-devel: > > > The SO name changed for libassuan. Do you have an old version also > > installed (should be libassuan.0.dylib) and this is accidently used > > in the build? > > There was an older libassuan version in /opt/local/lib, courtesy of > dependencies pulled in by MacPorts' "wget" port: > > ---> Computing dependencies for wget > The following dependencies will be installed: > gnupg2 > gpgme > libassuan > > Although the old library did not seem to be referenced by my own build, > I removed the listed ports including libassuan, just to be sure. Alas, > my build still breaks due to duplicate symbols. > > I don't see any mention of the old name in my build logs (line breaks > added for improved readability): > > $ grep -E .libassuan\..+\.dylib' intel-2.5.0.log > libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o > .libs/libassuan.9.dylib > .libs/libassuan_la-assuan.o > .libs/libassuan_la-context.o > .libs/libassuan_la-system.o > .libs/libassuan_la-debug.o > .libs/libassuan_la-conversion.o > .libs/libassuan_la-sysutils.o > .libs/libassuan_la-client.o > .libs/libassuan_la-server.o > .libs/libassuan_la-assuan-error.o > .libs/libassuan_la-assuan-buffer.o > .libs/libassuan_la-assuan-handler.o > .libs/libassuan_la-assuan-inquire.o > .libs/libassuan_la-assuan-listen.o > .libs/libassuan_la-assuan-pipe-server.o > .libs/libassuan_la-assuan-socket-server.o > .libs/libassuan_la-assuan-pipe-connect.o > .libs/libassuan_la-assuan-socket-connect.o > .libs/libassuan_la-assuan-uds.o > .libs/libassuan_la-assuan-logging.o > .libs/libassuan_la-assuan-socket.o > .libs/libassuan_la-system-posix.o > .libs/libassuan_la-assuan-io.o > .libs/memrchr.o -L/tmp/gpgosx-2.5.0/x86_64-dist/lib > /tmp/gpgosx-2.5.0/x86_64-dist/lib/libgpg-error.dylib -arch x86_64 -m64 > -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk > -mmacosx-version-min=10.12 -O0 -arch x86_64 > -install_name /tmp/gpgosx-2.5.0/x86_64-dist/lib/libassuan.9.dylib > -compatibility_version 10 -current_version 10.1 > > See https://seichter.de/tmp/intel-2.5.0.log for the complete, unedited > build log. Looking at your build logs, these are the objects being linked: <...>/.libs/libassuan_la-server.o <...>/.libs/libassuan_la-sysutils.o <...>/.libs/libassuan_la-assuan-inquire.o <...>/.libs/libassuan_la-conversion.o <...>/.libs/libassuan_la-assuan-error.o <...>/.libs/libassuan_la-assuan-listen.o <...>/.libs/libassuan_la-assuan-pipe-server.o <...>/.libs/libassuan_la-assuan-socket-server.o <...>/.libs/libassuan_la-debug.o <...>/.libs/libassuan_la-assuan.o <...>/.libs/libassuan_la-context.o <...>/.libs/libassuan_la-assuan-buffer.o <...>/.libs/libassuan_la-system.o <...>/.libs/libassuan_la-client.o <...>/.libs/libassuan_la-assuan-socket-connect.o <...>/.libs/libassuan_la-assuan-uds.o <...>/.libs/libassuan_la-assuan-pipe-connect.o <...>/.libs/libassuan_la-assuan-handler.o <...>/.libs/libassuan_la-assuan-logging.o <...>/.libs/libassuan_la-assuan-io.o <...>/.libs/libassuan_la-system-posix.o <...>/.libs/libassuan_la-assuan-socket.o Can you create a Bash script, for-each over each lib, and perform: nm -g | c++filt | grep ' D ' | grep sputc The script should tell you which objects are defining the symbol. The ' D ' makes sure it is defined in the translation unit, and not just referenced (like with ' U '). Jeff From ralph at ml.seichter.de Mon Jul 8 23:12:15 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Mon, 08 Jul 2024 23:12:15 +0200 Subject: libassuan duplicate symbol In-Reply-To: References: <875xtjhmdc.fsf@jacob.g10code.de> <8734onirth.fsf@ra.horus-it.com> <87tth0fcyu.fsf_-_@jacob.g10code.de> <87ed83u3g7.fsf@ra.horus-it.com> Message-ID: <87bk37twpc.fsf@ra.horus-it.com> * Jeffrey Walton: > Can you create a Bash script, for-each over each lib, and perform: > nm -g | c++filt | grep ' D ' | grep sputc I get no match with "D". Here are the results of nm -g "$libfile" | c++filt | grep sputc when looping over the lib files: $ ./sputc-check.sh ./libassuan_la-assuan-buffer.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-error.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-handler.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-inquire.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-io.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-listen.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-logging.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-pipe-connect.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-pipe-server.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-socket-connect.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-socket-server.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-socket.o: 0000000000000000 T ___sputc ./libassuan_la-assuan-uds.o: 0000000000000000 T ___sputc ./libassuan_la-assuan.o: 0000000000000000 T ___sputc ./libassuan_la-client.o: 0000000000000000 T ___sputc ./libassuan_la-context.o: 0000000000000000 T ___sputc ./libassuan_la-conversion.o: 0000000000000000 T ___sputc ./libassuan_la-debug.o: 0000000000000000 T ___sputc ./libassuan_la-server.o: 0000000000000000 T ___sputc ./libassuan_la-system-posix.o: 0000000000000000 T ___sputc ./libassuan_la-system.o: 0000000000000000 T ___sputc ./libassuan_la-sysutils.o: 0000000000000000 T ___sputc -Ralph From lists at sapience.com Wed Jul 10 16:43:57 2024 From: lists at sapience.com (Genes Lists) Date: Wed, 10 Jul 2024 10:43:57 -0400 Subject: gpgme git - qt6 build fails - help Message-ID: <2e4b742d27930512f7f0beecedbbb36923313798.camel@sapience.com> In addition to regular release builds we also build git HEAD. Recently gpgme fails to build qt (neither qt5 nor qt6). Build on archlinux using: ? ?gcc - ?14.1 ? ?qt6 - 6.7.3 ? ?gpgme git commit - f6d020e24fb64cfba5e80cef7f80cad15f08cc3c Configured: git clean -fdx git fetch; git pull origin ./autogen.sh --force ? ?./configure --prefix=/usr --disable-fd-passing --disable-gpgsm-test --disable-gpg-test --enable-languages=cpp,qt6 cpp builds complete fine as does python. But qt6 now has: Any suggestions? thanks gene --- trimmed compile log --- libtool: compile: g++ -std=c++17 -DHAVE_CONFIG_H -I. -I../../../conf - I../../../lang/cpp/src -I../../../src -I/usr/include/qt6/QtCore - I/usr/include/qt6 -DQT_CORE_LIB -I/usr/lib/qt6/mkspecs/linux-g++ -fPIC -mno-direct-extern-access -fvisibility=hidden -DBUILDING_QGPGME - Wsuggest-override -Wzero-as-null-pointer-constant -g -O2 -Wall -Wextra -Wno-shadow -MT dataprovider.lo -MD -MP -MF .deps/dataprovider.Tpo -c dataprovider.cpp -fPIC -DPIC -o .libs/dataprovider.o In file included from ../../../lang/cpp/src/gpgme++/././././././././././././././././././././. /./././././././././././././././././././././././././././././././././././ ./././././././././././././././././././././././././././././././././././. /./././././././././././././././././././././././././././././././././././ ./././././././././././././././././././././././././././././././././././. /././././././././././././././././././././././././././././././././././er ror.h:1, from ../../../lang/cpp/src/gpgme++/././././././././././././././././././././. /./././././././././././././././././././././././././././././././././././ ./././././././././././././././././././././././././././././././././././. /./././././././././././././././././././././././././././././././././././ ./././././././././././././././././././././././././././././././././././. /./././././././././././././././././././././././././././././././././erro r.h:1, .. ? (repeats couple hundred times - each ?line similar but 1 shorter than previous. ?Finally followed by )? from ../../../lang/cpp/src/gpgme++/error.h:1, from dataprovider.cpp:31: ../../../lang/cpp/src/gpgme++/././././././././././././././././././././. /./././././././././././././././././././././././././././././././././././ ./././././././././././././././././././././././././././././././././././. /./././././././././././././././././././././././././././././././././././ ./././././././././././././././././././././././././././././././././././. /./././././././././././././././././././././././././././././././././././ error.h:1:21: error: #include nested depth 200 exceeds maximum of 200 (use -fmax-include-depth=DEPTH to increase the maximum) 1 | #include "./error.h" | ^ In file included from /usr/include/qt6/QtCore/qglobal.h:63, from /usr/include/qt6/QtCore/qnamespace.h:12, from /usr/include/qt6/QtCore/qbytearray.h:9, from /usr/include/qt6/QtCore/QByteArray:1, from ./dataprovider.h:33, from dataprovider.cpp:29: /usr/include/qt6/QtCore/qfloat16.h: In function 'constexpr bool operator<(const qfloat16&, const qfloat16&)': /usr/include/qt6/QtCore/qcomparehelpers.h:202:42: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] -- Gene -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From kloecker at kde.org Wed Jul 10 22:03:41 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 10 Jul 2024 22:03:41 +0200 Subject: gpgme git - qt6 build fails - help In-Reply-To: <2e4b742d27930512f7f0beecedbbb36923313798.camel@sapience.com> References: <2e4b742d27930512f7f0beecedbbb36923313798.camel@sapience.com> Message-ID: <2335226.ElGaqSPkdT@daneel> On Mittwoch, 10. Juli 2024 16:43:57 CEST Genes Lists via Gnupg-devel wrote: > In addition to regular release builds we also build git HEAD. > Recently gpgme fails to build qt (neither qt5 nor qt6). > > Build on archlinux using: > > gcc - 14.1 > qt6 - 6.7.3 > gpgme git commit - f6d020e24fb64cfba5e80cef7f80cad15f08cc3c > > Configured: > > git clean -fdx > git fetch; git pull origin > ./autogen.sh --force > > ./configure --prefix=/usr --disable-fd-passing --disable-gpgsm-test > --disable-gpg-test --enable-languages=cpp,qt6 > > cpp builds complete fine as does python. But qt6 now has: > > Any suggestions? Try an out-of-source build, i.e. ``` ./autogen.sh --force mkdir build cd build ../configure ... make ``` Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From lists at sapience.com Wed Jul 10 23:31:21 2024 From: lists at sapience.com (Genes Lists) Date: Wed, 10 Jul 2024 17:31:21 -0400 Subject: gpgme git - qt6 build fails - help In-Reply-To: <2335226.ElGaqSPkdT@daneel> References: <2e4b742d27930512f7f0beecedbbb36923313798.camel@sapience.com> <2335226.ElGaqSPkdT@daneel> Message-ID: On Wed, 2024-07-10 at 22:03 +0200, Ingo Kl?cker wrote: > > Try an out-of-source build, i.e. > ``` > ./autogen.sh --force > mkdir build > cd build > ../configure ... > make > ``` > > Regards, > Ingo Thank you Ingo - worked perfectly.? autogen.sh even says to do same - somehow I missed it. Sorry for noise - and thank you. -- Gene -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From kloecker at kde.org Wed Jul 10 23:50:00 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 10 Jul 2024 23:50:00 +0200 Subject: gpgme git - qt6 build fails - help In-Reply-To: References: <2e4b742d27930512f7f0beecedbbb36923313798.camel@sapience.com> <2335226.ElGaqSPkdT@daneel> Message-ID: <2948166.e9J7NaK4W3@daneel> On Mittwoch, 10. Juli 2024 23:31:21 CEST Genes Lists via Gnupg-devel wrote: > On Wed, 2024-07-10 at 22:03 +0200, Ingo Kl?cker wrote: > > Try an out-of-source build, i.e. > > ``` > > ./autogen.sh --force > > mkdir build > > cd build > > ../configure ... > > make > > ``` > > > > Regards, > > Ingo > > Thank you Ingo - worked perfectly. > autogen.sh even says to do same - somehow I missed it. in-source builds should now also work again. Thanks for the report! There was actually a wrong path to the real headers used in the generated headers. We still recommend out-of-source builds because that's what we use and test. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From ralph at ml.seichter.de Thu Jul 11 01:17:05 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Thu, 11 Jul 2024 01:17:05 +0200 Subject: libassuan duplicate symbol In-Reply-To: <87bk37twpc.fsf@ra.horus-it.com> References: <875xtjhmdc.fsf@jacob.g10code.de> <8734onirth.fsf@ra.horus-it.com> <87tth0fcyu.fsf_-_@jacob.g10code.de> <87ed83u3g7.fsf@ra.horus-it.com> <87bk37twpc.fsf@ra.horus-it.com> Message-ID: <87cynkdeha.fsf@ra.horus-it.com> I still have not been able to determine the root cause, although I have been going through the libraries and lib directories listed in my build logs. Could the Xcode linker [1] itself be an issue, I wonder? Has anybody subscribed to this mailing list successfully built libassuan 3.0.1 on macOS using Apple's Xcode toolchain? [1] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld -Ralph From lists at sapience.com Thu Jul 11 12:12:19 2024 From: lists at sapience.com (Genes Lists) Date: Thu, 11 Jul 2024 06:12:19 -0400 Subject: gpgme git - qt6 build fails - help In-Reply-To: <2948166.e9J7NaK4W3@daneel> References: <2e4b742d27930512f7f0beecedbbb36923313798.camel@sapience.com> <2335226.ElGaqSPkdT@daneel> <2948166.e9J7NaK4W3@daneel> Message-ID: <98efa2d917a40fa8961ad3154a0530bc29efa1df.camel@sapience.com> On Wed, 2024-07-10 at 23:50 +0200, Ingo Kl?cker wrote: > On Mittwoch, ... > in-source builds should now also work again. Thanks for the report! > There was > actually a wrong path to the real headers used in the generated > headers. > > We still recommend out-of-source builds because that's what we use > and test. > > Regards, > Ingo Great and thank you for fixing. I changed the package builder to use out-of-source builds. gene -- Gene -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From falko.strenzke at mtg.de Thu Jul 11 12:52:22 2024 From: falko.strenzke at mtg.de (Falko Strenzke) Date: Thu, 11 Jul 2024 12:52:22 +0200 Subject: DCO Falko Message-ID: GnuPG Developer's Certificate of Origin.? Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I ??? have the right to submit it under the free software license ??? indicated in the file; or (b) The contribution is based upon previous work that, to the ??? best of my knowledge, is covered under an appropriate free ??? software license and I have the right under that license to ??? submit that work with modifications, whether created in whole ??? or in part by me, under the same free software license ??? (unless I am permitted to submit under a different license), ??? as indicated in the file; or (c) The contribution was provided directly to me by some other ??? person who certified (a), (b) or (c) and I have not modified ??? it. (d) I understand and agree that this project and the contribution ??? are public and that a record of the contribution (including ??? all personal information I submit with it, including my ??? sign-off) is maintained indefinitely and may be redistributed ??? consistent with this project or the free software license(s) ??? involved. Signed-off-by: Falko Strenzke -- *MTG AG* Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: falko.strenzke at mtg.de Web: mtg.de Follow us ------------------------------------------------------------------------ MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany Commercial register: HRB 8901 Register Court: Amtsgericht Darmstadt Management Board: J?rgen Ruf (CEO), Tamer Kemer?z Chairman of the Supervisory Board: Dr. Thomas Milde This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error, please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted. Data protection information: Privacy policy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xlRE0b77dPYe5vpk.png Type: image/png Size: 4018 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7cfLJbPJ5uVgDNGq.png Type: image/png Size: 3755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wOBdEfh2CIQTY1cX.png Type: image/png Size: 13185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xD1AC7C9C72A60A61.asc Type: application/pgp-keys Size: 3139 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From falko.strenzke at mtg.de Thu Jul 11 12:36:48 2024 From: falko.strenzke at mtg.de (Falko Strenzke) Date: Thu, 11 Jul 2024 12:36:48 +0200 Subject: Patch for PQC algorithms Message-ID: We delivered with some delay our completed version of the integration of PQC algorithms into Libgcrypt from our project in an upload to this issue in phabricator . The code features the following algorithms: KMAC ML-KEM ML-DSA SLH-DSA For each algorithm, also tests are implemented. The patch is in the file all-pqc-dfa4150a-vs-master-dc1c916d.patch. This is a patch against the upstream master branch as indicated by the commit version in the file name. Rebasing our changes to current master was not possible as since the start of our development work, ML-KEM was introduced into Libgcrypt independently by the maintainers and thus an attempt to merge both branches would either feature two versions of the same algorithm or would have to remove one of them. Even though we do not expect that our ML-KEM implementation will still be used by the Libgcrypt project, we decided to provide the patch with our complete contribution. We would appreciate if the maintainers would follow up with comments as to in which form our patch is the most useful to them. Particularly, we are contributing PQC signature algorithms which to the best of our knowledge have so far not been in implemented in Libgcrypt and thus might be of interest to the project. If the maintainers prefer that these algorithms be submitted in a different form, please let us know and we will try to find the best possible solution so that the Libgcrypt project can benefit from our contribution. Note: my DCO form Sept. '23 applies to this patch. Signed-off-by: Falko Strenzke -- *MTG AG* Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: falko.strenzke at mtg.de Web: mtg.de ------------------------------------------------------------------------ MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany Commercial register: HRB 8901 Register Court: Amtsgericht Darmstadt Management Board: J?rgen Ruf (CEO), Tamer Kemer?z Chairman of the Supervisory Board: Dr. Thomas Milde This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error, please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted. Data protection information: Privacy policy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4813 bytes Desc: Kryptografische S/MIME-Signatur URL: From email at bevankay.me Sat Jul 13 03:30:39 2024 From: email at bevankay.me (Bevan Kay) Date: Sat, 13 Jul 2024 11:30:39 +1000 Subject: libassuan duplicate symbol Message-ID: We are seeing the same duplicate symbol build error when trying to build libassuan 3.0.1 at Homebrew. Here is a link to the PR: https://github.com/Homebrew/homebrew-core/pull/175003 Here is the build logs: https://github.com/Homebrew/homebrew-core/actions/runs/9677651011/job/26699991385?pr=175003#step:3:533 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at ml.seichter.de Sun Jul 14 21:55:00 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Sun, 14 Jul 2024 21:55:00 +0200 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: References: Message-ID: <8734ob6963.fsf@ra.horus-it.com> * Bevan Kay: > We are seeing the same duplicate symbol build error when trying to build > libassuan 3.0.1 at Homebrew. Your post reminded me of giving the MacPorts build a shot. I bumped the existing libassuan port [1] to version 3.0.1, and the build fails at the linking stage [2] with "duplicate symbol". [1] https://seichter.de/tmp/build-mp-1720985931.diff [2] https://seichter.de/tmp/build-mp-1720985931.log Is anybody among the libassuan developers able to look into this issue? I have not yet heard from anyone who was able to build libassuan 3.0.1 on macOS. Thank you. -Ralph From bjk at luxsci.net Sun Jul 14 23:28:51 2024 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 14 Jul 2024 14:28:51 -0700 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <8734ob6963.fsf@ra.horus-it.com> References: <8734ob6963.fsf@ra.horus-it.com> Message-ID: <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> I don't have an OSX install but I have looked around and found that adding -std=gnu89 to your CFLAGS may help. Or possibly even -std=c99. On Sun, Jul 14, 2024 at 09:55:00PM GMT, Ralph Seichter via Gnupg-devel wrote: > * Bevan Kay: > > > We are seeing the same duplicate symbol build error when trying to build > > libassuan 3.0.1 at Homebrew. > > Your post reminded me of giving the MacPorts build a shot. I bumped the > existing libassuan port [1] to version 3.0.1, and the build fails at the > linking stage [2] with "duplicate symbol". > > [1] https://seichter.de/tmp/build-mp-1720985931.diff > [2] https://seichter.de/tmp/build-mp-1720985931.log > > Is anybody among the libassuan developers able to look into this issue? > I have not yet heard from anyone who was able to build libassuan 3.0.1 > on macOS. Thank you. > > -Ralph > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- Ben Kibbey From ralph at ml.seichter.de Mon Jul 15 06:50:40 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Mon, 15 Jul 2024 06:50:40 +0200 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> References: <8734ob6963.fsf@ra.horus-it.com> <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> Message-ID: <87wmln45sv.fsf@ra.horus-it.com> * Ben Kibbey: > I don't have an OSX install but I have looked around and found that > adding -std=gnu89 to your CFLAGS may help. Or possibly even -std=c99. Thanks Ben, I'll give it a try. Would you consider sharing how you came to this idea? -Ralph From bjk at luxsci.net Mon Jul 15 07:33:28 2024 From: bjk at luxsci.net (Benjamin Kibbey) Date: Sun, 14 Jul 2024 22:33:28 -0700 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <87wmln45sv.fsf@ra.horus-it.com> References: <8734ob6963.fsf@ra.horus-it.com> <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> <87wmln45sv.fsf@ra.horus-it.com> Message-ID: <1721021612-5955477.81161058.f46F5XUXI3077925@rs6161.luxsci.com> On July 14, 2024 9:50:40 PM PDT, Ralph Seichter via Gnupg-devel wrote: >* Ben Kibbey: > >> I don't have an OSX install but I have looked around and found that >> adding -std=gnu89 to your CFLAGS may help. Or possibly even -std=c99. > >Thanks Ben, I'll give it a try. Would you consider sharing how you came >to this idea? > >-Ralph > >_______________________________________________ >Gnupg-devel mailing list >Gnupg-devel at gnupg.org >https://lists.gnupg.org/mailman/listinfo/gnupg-devel > Searched around for bug reports and found a couple of projects that have had the same problem. Though they are old bug reports the solution may still apply here. There is/was a quirk with the OSX sdk. -- Ben Kibbey From mhlavink at redhat.com Mon Jul 15 18:17:59 2024 From: mhlavink at redhat.com (Michal Hlavinka) Date: Mon, 15 Jul 2024 18:17:59 +0200 Subject: gpgme static analysis findings Message-ID: Hi, we've started to run static analysis on some system components including gpgme where the scanner reported a few issues: 1) in src/engine.c """ "Error: OVERRUN (CWE-119): src/engine.c:121: cond_between: Checking ""proto > 7UL"" implies that ""proto"" is between 0 and 7 (inclusive) on the false branch. src/engine.c:125: overrun-local: Overrunning array ""engine_ops"" of 7 8-byte elements at element index 7 (byte offset 63) using index ""proto"" (which evaluates to 7). # 123| # 124| if (engine_ops[proto] && engine_ops[proto]->get_req_version) # 125|-> return (*engine_ops[proto]->get_req_version) (); # 126| else # 127| return NULL;" """ 121: if (proto > DIM (engine_ops)) this checks if 'proto' is bigger than number of elements in engine_ops DIM is defined in util.h: 44: #define DIM(v) (sizeof(v)/sizeof((v)[0])) the above condition allows for proto = DIM(engine_ops) which later at: 125: return (*engine_ops[proto]->get_req_version) (); allows to access (proto+1)th element seems that the condition should actually be proto >= DIM(engine_ops) the same condition check is present several times: at engine_get_file_name (...) line 76, at engine_get_home_dir (...) line 90, at engine_get_version (...) line 106, at engine_get_req_version (...) line 121, at _gpgme_set_engine_info (...) line 406 2) in src/gpgme-tool.c simple list assignment as used at gt_get_keylist_mode () does not prevent out of bound access. """ Error: OVERRUN (CWE-119): src/gpgme-tool.c:1445: assignment: Assigning: ""idx"" = ""0"". src/gpgme-tool.c:1449: incr: Incrementing ""idx"". The value of ""idx"" is now 1. src/gpgme-tool.c:1451: incr: Incrementing ""idx"". The value of ""idx"" is now 2. src/gpgme-tool.c:1453: incr: Incrementing ""idx"". The value of ""idx"" is now 3. src/gpgme-tool.c:1455: incr: Incrementing ""idx"". The value of ""idx"" is now 4. src/gpgme-tool.c:1457: incr: Incrementing ""idx"". The value of ""idx"" is now 5. src/gpgme-tool.c:1459: incr: Incrementing ""idx"". The value of ""idx"" is now 6. src/gpgme-tool.c:1461: incr: Incrementing ""idx"". The value of ""idx"" is now 7. src/gpgme-tool.c:1463: incr: Incrementing ""idx"". The value of ""idx"" is now 8. src/gpgme-tool.c:1464: overrun-local: Overrunning array ""modes"" of 7 8-byte elements at element index 8 (byte offset 71) using index ""idx++"" (which evaluates to 8). # 1462| if (mode & GPGME_KEYLIST_MODE_FORCE_EXTERN) # 1463| modes[idx++] = ""force_extern""; # 1464|-> modes[idx++] = NULL; # 1465| # 1466| gt_write_status (gt, STATUS_KEYLIST_MODE, modes[0], modes[1], modes[2], """ Let me know if you need more information. Cheers, Michal Hlavinka From ralph at ml.seichter.de Mon Jul 15 20:22:43 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Mon, 15 Jul 2024 20:22:43 +0200 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <1721021612-5955477.81161058.f46F5XUXI3077925@rs6161.luxsci.com> References: <8734ob6963.fsf@ra.horus-it.com> <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> <87wmln45sv.fsf@ra.horus-it.com> <1721021612-5955477.81161058.f46F5XUXI3077925@rs6161.luxsci.com> Message-ID: <87ttgqikgc.fsf@ra.horus-it.com> * Benjamin Kibbey: > Though they are old bug reports the solution may still apply > here. There is/was a quirk with the OSX sdk. I am glad to report that your suggestion worked. With '-std=gnu89' appended, I have been able to build libassuan 3.0.1 on my machine, which is quite a relief. Thank you! -Ralph From ralph at ml.seichter.de Mon Jul 15 21:42:30 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Mon, 15 Jul 2024 21:42:30 +0200 Subject: exechelp-posix.c:527:5: error: use of undeclared identifier 'environ' Message-ID: <87plreigrd.fsf@ra.horus-it.com> I see the following error when trying to build GnuPG 2.5.0 on macOS: exechelp-posix.c:527:5: error: use of undeclared identifier 'environ' environ = act->environ; ^ 1 error generated. make[3]: *** [libcommon_a-exechelp-posix.o] Error 1 Similar to the suggestion in https://dev.gnupg.org/T7169 , I was able to temporarily work around the issue by creating a crude patch (attached). -Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.5.0-macos.patch Type: text/x-patch Size: 351 bytes Desc: macOS patch URL: From kloecker at kde.org Mon Jul 15 22:50:28 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 15 Jul 2024 22:50:28 +0200 Subject: gpgme static analysis findings In-Reply-To: References: Message-ID: <3304055.aeNJFYEL58@daneel> On Montag, 15. Juli 2024 18:17:59 CEST Michal Hlavinka via Gnupg-devel wrote: > Hi, > > we've started to run static analysis on some system components including > gpgme where the scanner reported a few issues: Thanks. > 1) in src/engine.c > """ > "Error: OVERRUN (CWE-119): > src/engine.c:121: cond_between: Checking ""proto > 7UL"" implies that > ""proto"" is between 0 and 7 (inclusive) on the false branch. > src/engine.c:125: overrun-local: Overrunning array ""engine_ops"" of 7 > 8-byte elements at element index 7 (byte offset 63) using index > ""proto"" (which evaluates to 7). > # 123| > # 124| if (engine_ops[proto] && engine_ops[proto]->get_req_version) > # 125|-> return (*engine_ops[proto]->get_req_version) (); > # 126| else > # 127| return NULL;" > """ > > 121: if (proto > DIM (engine_ops)) > > this checks if 'proto' is bigger than number of elements in engine_ops > > DIM is defined in util.h: > 44: #define DIM(v) (sizeof(v)/sizeof((v)[0])) > > the above condition allows for proto = DIM(engine_ops) > which later at: > 125: return (*engine_ops[proto]->get_req_version) (); > allows to access (proto+1)th element > > seems that the condition should actually be proto >= DIM(engine_ops) I agree. There's no real danger of an overrun because the enum enumerating the protocols only lists 7 values (0-6) and the two additional enum values 254 and 255 which are much > DIM (engine_ops). Of course, this should still be fixed. > 2) in src/gpgme-tool.c > simple list assignment as used at gt_get_keylist_mode () does not > prevent out of bound access. > > """ > Error: OVERRUN (CWE-119): > src/gpgme-tool.c:1445: assignment: Assigning: ""idx"" = ""0"". > src/gpgme-tool.c:1449: incr: Incrementing ""idx"". The value of ""idx"" > is now 1. > src/gpgme-tool.c:1451: incr: Incrementing ""idx"". The value of ""idx"" > is now 2. > src/gpgme-tool.c:1453: incr: Incrementing ""idx"". The value of ""idx"" > is now 3. > src/gpgme-tool.c:1455: incr: Incrementing ""idx"". The value of ""idx"" > is now 4. > src/gpgme-tool.c:1457: incr: Incrementing ""idx"". The value of ""idx"" > is now 5. > src/gpgme-tool.c:1459: incr: Incrementing ""idx"". The value of ""idx"" > is now 6. > src/gpgme-tool.c:1461: incr: Incrementing ""idx"". The value of ""idx"" > is now 7. > src/gpgme-tool.c:1463: incr: Incrementing ""idx"". The value of ""idx"" > is now 8. > src/gpgme-tool.c:1464: overrun-local: Overrunning array ""modes"" of 7 > 8-byte elements at element index 8 (byte offset 71) using index > ""idx++"" (which evaluates to 8). > # 1462| if (mode & GPGME_KEYLIST_MODE_FORCE_EXTERN) > # 1463| modes[idx++] = ""force_extern""; > # 1464|-> modes[idx++] = NULL; > # 1465| > # 1466| gt_write_status (gt, STATUS_KEYLIST_MODE, modes[0], > modes[1], modes[2], > """ This has been fixed. And while at it I have added support for some more keylist modes. https://dev.gnupg.org/rMaa15a664b3cf9bf578ba6d22c1c0c327af68b1b4 Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From bjk at luxsci.net Tue Jul 16 01:28:05 2024 From: bjk at luxsci.net (Ben Kibbey) Date: Mon, 15 Jul 2024 16:28:05 -0700 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <87ttgqikgc.fsf@ra.horus-it.com> References: <8734ob6963.fsf@ra.horus-it.com> <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> <87wmln45sv.fsf@ra.horus-it.com> <1721021612-5955477.81161058.f46F5XUXI3077925@rs6161.luxsci.com> <87ttgqikgc.fsf@ra.horus-it.com> Message-ID: <1721086087-1676834.30882635.f46FNS691107697@rs6161.luxsci.com> Good news! I wonder if it is a quirk with all versions of the OSX sdk or not? Appending to CFLAGS in configure.ac would be the thing to do but I am unsure to add it for *-apple-darwin* or make a compile time test to test for linking failure then append to CFLAGS, then. On Mon, Jul 15, 2024 at 08:22:43PM GMT, Ralph Seichter via Gnupg-devel wrote: > I am glad to report that your suggestion worked. With '-std=gnu89' > appended, I have been able to build libassuan 3.0.1 on my machine, > which is quite a relief. Thank you! -- Ben Kibbey From ralph at ml.seichter.de Tue Jul 16 02:40:32 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 16 Jul 2024 02:40:32 +0200 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <1721086087-1676834.30882635.f46FNS691107697@rs6161.luxsci.com> References: <8734ob6963.fsf@ra.horus-it.com> <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> <87wmln45sv.fsf@ra.horus-it.com> <1721021612-5955477.81161058.f46F5XUXI3077925@rs6161.luxsci.com> <87ttgqikgc.fsf@ra.horus-it.com> <1721086087-1676834.30882635.f46FNS691107697@rs6161.luxsci.com> Message-ID: <87sewa6uf3.fsf@ra.horus-it.com> * Ben Kibbey: > I wonder if it is a quirk with all versions of the OSX sdk or not? You mentioned old bug reports tied to the issue, and I am using the latest stable of Apple's Xcode toolchain, still experiencing similar problems. That leads me to suspect it could be a widespread quirk. Unfortunately I don't have different generations of Xcode available, so I cannot test on a larger scale. Perhaps the MacPorts or Homebrew teams could be of assistance in this regard? -Ralph From wk at gnupg.org Tue Jul 23 12:22:28 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Jul 2024 12:22:28 +0200 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <87sewa6uf3.fsf@ra.horus-it.com> (Ralph Seichter via Gnupg-devel's message of "Tue, 16 Jul 2024 02:40:32 +0200") References: <8734ob6963.fsf@ra.horus-it.com> <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> <87wmln45sv.fsf@ra.horus-it.com> <1721021612-5955477.81161058.f46F5XUXI3077925@rs6161.luxsci.com> <87ttgqikgc.fsf@ra.horus-it.com> <1721086087-1676834.30882635.f46FNS691107697@rs6161.luxsci.com> <87sewa6uf3.fsf@ra.horus-it.com> Message-ID: <87wmlcif17.fsf@jacob.g10code.de> Hi! Shall we add something to the README to help in case of that problem? 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: 247 bytes Desc: not available URL: From ralph at ml.seichter.de Wed Jul 24 02:01:05 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Wed, 24 Jul 2024 02:01:05 +0200 Subject: Same problem with MacPorts (Re: libassuan duplicate symbol) In-Reply-To: <87wmlcif17.fsf@jacob.g10code.de> References: <8734ob6963.fsf@ra.horus-it.com> <1720992533-5218801.98160978.f46ELSqK22521091@rs6161.luxsci.com> <87wmln45sv.fsf@ra.horus-it.com> <1721021612-5955477.81161058.f46F5XUXI3077925@rs6161.luxsci.com> <87ttgqikgc.fsf@ra.horus-it.com> <1721086087-1676834.30882635.f46FNS691107697@rs6161.luxsci.com> <87sewa6uf3.fsf@ra.horus-it.com> <87wmlcif17.fsf@jacob.g10code.de> Message-ID: <87frrzejzy.fsf@ra.horus-it.com> * Werner Koch via Gnupg-devel: > Shall we add something to the README to help in case of that problem? Good idea. A recommended set of CFLAGS etc. for different platforms and toolchains would be helpful, as would all other hints regarding quirks and oddities. I admit I am a bit weary whenever you fine folks announce new versions, because I expect to run into issues on macOS. Are any of you testing on macOS, by the way? It feels like this operating system is in need of a bit more love in terms of GnuPG, if you pardon my saying so. ;-) -Ralph From mail at matejamaric.com Wed Jul 24 17:24:52 2024 From: mail at matejamaric.com (Mateja Maric) Date: Wed, 24 Jul 2024 17:24:52 +0200 Subject: Bug Tracker Account Request Message-ID: <65228fc4-8987-4daa-b0a7-8529d2116c53@matejamaric.com> Hello, I would like to write a bug report on the GnuPG Development Hub (https://dev.gnupg.org). Currently, the registration is disabled entirely, so I would like to be provided with an account. Here's the info I was instructed to provide: Handle: mateja Shown name: Mateja Maric Mail address: mail at matejamaric.com Ideally, I would like to be able to login with my GitHub account, if that's possible. Here's the link to my GitHub profile: https://github.com/MatejaMaric/ Thanks a lot! Mateja Maric From fundawang at gmail.com Tue Jul 30 13:07:03 2024 From: fundawang at gmail.com (Funda Wang) Date: Tue, 30 Jul 2024 19:07:03 +0800 Subject: Question on sks-keyservers.netCA.pem Message-ID: Hello, Is sks-keyservers.netCA.pem currently useful? I've checked dirmngr source code, and found that it is of no use since 2.4.3. Maybe it should be removed from Makefile? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Tue Jul 30 15:12:17 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 30 Jul 2024 14:12:17 +0100 Subject: Question on sks-keyservers.netCA.pem In-Reply-To: References: Message-ID: On 30 Jul 2024, at 12:07, Funda Wang via Gnupg-devel wrote: > > Is sks-keyservers.netCA.pem currently useful? I've checked dirmngr source code, and found that it is of no use since 2.4.3. Maybe it should be removed from Makefile? That cert has been obsolete for several years now, you should definitely remove it. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: