From dkg at fifthhorseman.net Wed Mar 5 16:19:36 2025 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 5 Mar 2025 10:19:36 -0500 Subject: [PATCH GnuPG] gpg: Verify Text mode Signatures over binary Literal Data Packets Message-ID: <20250305151936.4017011-1-dkg@fifthhorseman.net> * tests/openpgp/issue7539{.scm,-signer.asc,message.asc}: Add test with text-mode Signature over binary Literal Data Packet. * tests/openpgp/Makefile.am: include 7539 test materials. * g10/filter.h: add textmode and seen_cr members to md_filter_context_t * g10/mainproc.c (proc_plaintext): set mfx.textmode if the signature is over a text document. * g10/mdfilter.c (md_filter): when mfx.textmode is set, normalize line endings to CRLF. (free_md_filter_context): clean up textmode and seen_cr * g10/plaintext.c (handle_plaintext): when mfx.textmode is set, normalize line endings to CRLF. -- GnuPG does not produce text signatures over binary literal data packets, but the OpenPGP standard permits them, and other OpenPGP implementations may produce them. See the discussion starting at https://mailarchive.ietf.org/arch/msg/openpgp/RLMBugGhg_c9xT7zmDrkBklRZB8/ This fix still doesn't handle the even-more-obscure struture where there are both text and binary signatures over a binary literal data packet, like so: OPS0 OPS1 LITb SIG1 SIG0 But a more complete fix would be more complex (it would require, for instance, multiple message digest handles), and this initial fix is still a substantial improvement over the status quo. GnuPG-bug-id: 7539 Signed-off-by: Daniel Kahn Gillmor --- g10/filter.h | 2 ++ g10/mainproc.c | 20 +++++++++++++++----- g10/mdfilter.c | 15 +++++++++++++-- g10/plaintext.c | 28 ++++++++++++++++++++++++++-- tests/openpgp/Makefile.am | 7 +++++-- tests/openpgp/issue7539-message.asc | 8 ++++++++ tests/openpgp/issue7539-signer.asc | 9 +++++++++ tests/openpgp/issue7539.scm | 29 +++++++++++++++++++++++++++++ 8 files changed, 107 insertions(+), 11 deletions(-) create mode 100644 tests/openpgp/issue7539-message.asc create mode 100644 tests/openpgp/issue7539-signer.asc create mode 100644 tests/openpgp/issue7539.scm diff --git a/g10/filter.h b/g10/filter.h index b15ce6aa5..c066898b2 100644 --- a/g10/filter.h +++ b/g10/filter.h @@ -27,6 +27,8 @@ typedef struct { gcry_md_hd_t md; /* catch all */ gcry_md_hd_t md2; /* if we want to calculate an alternate hash */ size_t maxbuf_size; + int textmode; /* 1 hashing needs to normalize line-endings to CRLF */ + int seen_cr; /* 1 if last octet hashed was '\r' */ } md_filter_context_t; typedef struct md_thd_filter_context *md_thd_filter_context_t; diff --git a/g10/mainproc.c b/g10/mainproc.c index ebbe4a6a7..ad615ff2c 100644 --- a/g10/mainproc.c +++ b/g10/mainproc.c @@ -993,9 +993,12 @@ proc_plaintext( CTX c, PACKET *pkt ) if (n->pkt->pkt.onepass_sig->digest_algo) { if (!opt.skip_verify) - gcry_md_enable (c->mfx.md, - n->pkt->pkt.onepass_sig->digest_algo); - + { + gcry_md_enable (c->mfx.md, + n->pkt->pkt.onepass_sig->digest_algo); + if (n->pkt->pkt.onepass_sig->sig_class == 0x01) + c->mfx.textmode = 1; + } any = 1; } } @@ -1014,7 +1017,10 @@ proc_plaintext( CTX c, PACKET *pkt ) clearsig = (*data == 0x01); for (data++, datalen--; datalen; datalen--, data++) if (!opt.skip_verify) - gcry_md_enable (c->mfx.md, *data); + { + gcry_md_enable (c->mfx.md, *data); + c->mfx.textmode = 1; + } any = 1; break; /* Stop here as one-pass signature packets are not expected. */ @@ -1023,7 +1029,11 @@ proc_plaintext( CTX c, PACKET *pkt ) { /* The SIG+LITERAL case that PGP used to use. */ if (!opt.skip_verify) - gcry_md_enable (c->mfx.md, n->pkt->pkt.signature->digest_algo); + { + gcry_md_enable (c->mfx.md, n->pkt->pkt.signature->digest_algo); + if (n->pkt->pkt.signature->sig_class == 0x01) + c->mfx.textmode = 1; + } any = 1; } } diff --git a/g10/mdfilter.c b/g10/mdfilter.c index a655d6d72..656661e49 100644 --- a/g10/mdfilter.c +++ b/g10/mdfilter.c @@ -41,7 +41,7 @@ md_filter( void *opaque, int control, { size_t size = *ret_len; md_filter_context_t *mfx = opaque; - int i, rc=0; + int i, rc=0, n; if( control == IOBUFCTRL_UNDERFLOW ) { if( mfx->maxbuf_size && size > mfx->maxbuf_size ) @@ -49,7 +49,16 @@ md_filter( void *opaque, int control, i = iobuf_read( a, buf, size ); if( i == -1 ) i = 0; if( i ) { - gcry_md_write(mfx->md, buf, i ); + if (!mfx->textmode) + gcry_md_write(mfx->md, buf, i ); + else + for (n = 0; n < i; n++) + { + if (buf[n] == '\n' && !mfx->seen_cr) + gcry_md_putc(mfx->md, '\r'); + gcry_md_putc(mfx->md, buf[n]); + mfx->seen_cr = (buf[n] == '\r'); + } if( mfx->md2 ) gcry_md_write(mfx->md2, buf, i ); } @@ -71,6 +80,8 @@ free_md_filter_context( md_filter_context_t *mfx ) mfx->md = NULL; mfx->md2 = NULL; mfx->maxbuf_size = 0; + mfx->textmode = 0; + mfx->seen_cr = 0; } diff --git a/g10/plaintext.c b/g10/plaintext.c index a96214994..8c2d2fcca 100644 --- a/g10/plaintext.c +++ b/g10/plaintext.c @@ -304,6 +304,7 @@ handle_plaintext (PKT_plaintext * pt, md_filter_context_t * mfx, while (pt->len) { int len = pt->len > temp_size ? temp_size : pt->len; + int n; len = iobuf_read (pt->buf, buffer, len); if (len == -1) { @@ -314,7 +315,18 @@ handle_plaintext (PKT_plaintext * pt, md_filter_context_t * mfx, goto leave; } if (mfx->md) - gcry_md_write (mfx->md, buffer, len); + { + if (!mfx->textmode) + gcry_md_write (mfx->md, buffer, len); + else + for (n = 0; n < len; n++) + { + if (buffer[n] == '\n' && !mfx->seen_cr) + gcry_md_putc(mfx->md, '\r'); + gcry_md_putc(mfx->md, buffer[n]); + mfx->seen_cr = (buffer[n] == '\r'); + } + } if (fp) { if (opt.max_output && (count += len) > opt.max_output) @@ -402,12 +414,24 @@ handle_plaintext (PKT_plaintext * pt, md_filter_context_t * mfx, * So, always assume EOF if iobuf_read returns less bytes * then requested */ int len = iobuf_read (pt->buf, buffer, temp_size); + int n; if (len == -1) break; if (len < temp_size) eof_seen = 1; if (mfx->md) - gcry_md_write (mfx->md, buffer, len); + { + if (!mfx->textmode) + gcry_md_write (mfx->md, buffer, len); + else + for (n = 0; n < len; n++) + { + if (buffer[n] == '\n' && !mfx->seen_cr) + gcry_md_putc(mfx->md, '\r'); + gcry_md_putc(mfx->md, buffer[n]); + mfx->seen_cr = (buffer[n] == '\r'); + } + } if (fp) { if (opt.max_output && (count += len) > opt.max_output) diff --git a/tests/openpgp/Makefile.am b/tests/openpgp/Makefile.am index d1f04e99b..a3c82bad8 100644 --- a/tests/openpgp/Makefile.am +++ b/tests/openpgp/Makefile.am @@ -104,7 +104,8 @@ XTESTS = \ issue2417.scm \ issue2419.scm \ issue2929.scm \ - issue2941.scm + issue2941.scm \ + issue7539.scm # XXX: Currently, one cannot override automake's 'check' target. As a @@ -177,7 +178,9 @@ TEST_FILES = pubring.asc secring.asc plain-1o.asc plain-2o.asc plain-3o.asc \ trust-pgp/david.sec.asc \ trust-pgp/frank.sec.asc \ trust-pgp/grace.sec.asc \ - trust-pgp/heidi.sec.asc + trust-pgp/heidi.sec.asc \ + issue7539-signer.asc \ + issue7539-message.asc data_files = data-500 data-9000 data-32000 data-80000 plain-large diff --git a/tests/openpgp/issue7539-message.asc b/tests/openpgp/issue7539-message.asc new file mode 100644 index 000000000..d9627e9de --- /dev/null +++ b/tests/openpgp/issue7539-message.asc @@ -0,0 +1,8 @@ +-----BEGIN PGP MESSAGE----- + +xA0DAQoWT96UsBf1XGsBywtiAAAAAAB0ZXN0CsJ1BAEWCgAdFiEE4nTJ+uve2SXH +vtD4T96UsBf1XGsFAme5OzsACgkQT96UsBf1XGtKWAEAjmR2dUu8Jsvq+j3QArUQ +J549CNsbbuHLLAhaE0C2zZMBAJD4hLT9KXxnpTINCAcgZfytWChkNP+qKqb4pV5N +ItsH +=OYzj +-----END PGP MESSAGE----- diff --git a/tests/openpgp/issue7539-signer.asc b/tests/openpgp/issue7539-signer.asc new file mode 100644 index 000000000..170498e1e --- /dev/null +++ b/tests/openpgp/issue7539-signer.asc @@ -0,0 +1,9 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- + +xjMEZ7k39xYJKwYBBAHaRw8BAQdAOfCju+pxXLXR2WU7ItL1LdlJFfubUeXQPk33 +sqDgebXNCHRlc3Qga2V5wo8EEBYIADcCGQEFAme5N/cCGwMICwkIBwoNDAsFFQoJ +CAsCFgIBJxYhBOJ0yfrr3tklx77Q+E/elLAX9VxrAAoJEE/elLAX9VxrJKcBAPzY +8Ct8qZ2xbzMXMtHrnR+a2kYLVDA9U8xPtrzQOUcOAPoDW17PxLj0IyZBS7ewb2Zt +bbZ7yHLYYKmrF2mAyBOiCA== +=UNOn +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/issue7539.scm b/tests/openpgp/issue7539.scm new file mode 100644 index 000000000..c84c40feb --- /dev/null +++ b/tests/openpgp/issue7539.scm @@ -0,0 +1,29 @@ +#!/usr/bin/env gpgscm + +;; Copyright (C) 2025 Daniel Kahn Gillmor +;; +;; This file is part of GnuPG. +;; +;; GnuPG is free software; you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation; either version 3 of the License, or +;; (at your option) any later version. +;; +;; GnuPG is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. +;; +;; You should have received a copy of the GNU General Public License +;; along with this program; if not, see . + +(load (in-srcdir "tests" "openpgp" "defs.scm")) +(setup-legacy-environment) + +(define keyfile (in-srcdir "tests" "openpgp" "issue7539-signer.asc")) +(define msg (in-srcdir "tests" "openpgp" "issue7539-message.asc")) + +(info "Checking text Signature over binary Literal Data Packet") + +(call-check `(, at gpg --import ,keyfile)) +(call-check `(, at gpg --verify ,msg)) -- 2.47.2 From ramon.garcia.f at gmail.com Wed Mar 5 17:45:49 2025 From: ramon.garcia.f at gmail.com (=?UTF-8?B?UmFtw7NuIEdhcmPDrWE=?=) Date: Wed, 5 Mar 2025 17:45:49 +0100 Subject: Gpgsm should skip expired certificates when there is a valid one In-Reply-To: <874j0qcpcj.fsf@jacob.g10code.de> References: <874j0qcpcj.fsf@jacob.g10code.de> Message-ID: Any news, please? On Wed, Feb 19, 2025 at 9:25?AM Werner Koch wrote: > > Hi! > > thanks for your patches. PLease give me some more time to check and > integrate them. > > > By the way, it would be much easier to contribute with an interface > > based on pull requests like Github/Bitbucket/Gitlab/... Preparing a > > Git is designed as a decentralized system and thus it works best with > email. "git format-patch" et al. are not really complicated to use and > you can stay in your editor. > > > Salam-Shalom, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein From wk at gnupg.org Fri Mar 7 15:21:21 2025 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Mar 2025 15:21:21 +0100 Subject: [Announce] GnuPG 2.5.5 released Message-ID: <878qpg6hwe.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.5. This release is another one in 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 Kyber (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. 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.5 (2025-03-07) ================================================ [compared to version 2.5.4] * gpg: Fix a verification DoS due to a malicious subkey in the keyring. [T7527] * dirmngr: Fix possible hangs due to blocking connection requests. [T6606, T7434] * w32: On socket nonce mismatch close the socket. [T7434] * w32: Print more detailed diagnostics for IPC errors. * GPGME is not any more distributed with the Windows installer. Please install gpg4win to get gpgme version. Release-info: https://dev.gnupg.org/T7530 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.5.tar.bz2 (7989k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.5.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.5_20250307.exe (5486k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.5_20250307.exe.sig The source used to build this installer for 64-bit Windows is available at https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.5_20250307.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.5_20250307.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. A new Beta version of Gpg4win, our full featured installer for Windows including this version of GnuPG as well as Kleopatra GUI and a PDF editor will soon be available at https://www.gpg4win.org/version5.html 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.5.tar.bz2 you would use this command: gpg --verify gnupg-2.5.5.tar.bz2.sig gnupg-2.5.5.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.5.tar.bz2, you run the command like this: sha1sum gnupg-2.5.5.tar.bz2 and check that the output matches the next line: b14ca751786112b3bb6686a462415c2896ceb73d gnupg-2.5.5.tar.bz2 552744d7f930c8905ad052c36b7ab06ce0d9ad25 gnupg-w32-2.5.5_20250307.tar.xz 0bfe05298d4f7953f4bb0361785003e859c39242 gnupg-w32-2.5.5_20250307.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, 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. In case of build problems specific to this release please first check https://dev.gnupg.org/T7530 for updated information. 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 bernhard at intevation.de Fri Mar 7 17:21:07 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 7 Mar 2025 17:21:07 +0100 Subject: ArchLinux libassuan upgrade problem (related to: libassuan 3.0.0 bumped the soname without bumping the symbol versioning) In-Reply-To: References: <87y16uk7a1.fsf@jacob.g10code.de> Message-ID: <202503071721.15193.bernhard@intevation.de> Hi, got a problem report via the fediverse. == Background libassuan-3.0.0.tar.bz2 came on 2024-06-18 and six days later there is 3.0.1 as quick-release upgrading the soname to what it should have been (see citation below). == Problem description Arch Linux packaged the 3.0.0 release and has problems upgrading from it now. Here is the problem description: " with the release of 3.0.0 the soname changed from libassuan.so.0 to libassuan.so.9. Only with 3.0.1 the symbols have been changed from LIBASSUAN_1.0 to LIBASSUAN_2.0 (which is the ABI breaking change that the soname change is supposed to indicate). Since #pacman requires the library transitively via #gpgme, there now is no clean way to upgrade this without patching all consumers in some intermediate step. (The staging build environment would otherwise have a broken pacman and thus not be functional). We are stuck on 3.0.0 because our packaging environment now requires libassuan.so.9 with symbols LIBASSUAN_1.0. " Does anybody have some ideas how to solve this for Arch Linux in an elegant and efficiant way? Best Regards, Bernhard On 2024-06-24 Werner Koch wrote: > On Sat, 22 Jun 2024 18:18, Andreas Metzler said: > > Could you do a quick 3.0.1 release to fix this before it has found its > > way into the major distributions? > > Just did this: > > #+macro: libassuan_ver 3.0.1 > #+macro: libassuan_date 2024-06-24 > #+macro: libassuan_size 578k > #+macro: libassuan_sha1 776aac6fe4a64f29406bb498e0b2b73f2622c799 > #+macro: libassuan_sha2 > c8f0f42e6103dea4b1a6a483cb556654e97302c7465308f58363778f95f194b1 > > 776aac6fe4a64f29406bb498e0b2b73f2622c799 libassuan-3.0.1.tar.bz2 -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- 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 simon at josefsson.org Fri Mar 7 18:54:24 2025 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 07 Mar 2025 18:54:24 +0100 Subject: ArchLinux libassuan upgrade problem (related to: libassuan 3.0.0 bumped the soname without bumping the symbol versioning) In-Reply-To: <202503071721.15193.bernhard@intevation.de> (Bernhard Reiter via Gnupg-devel's message of "Fri, 7 Mar 2025 17:21:07 +0100") References: <87y16uk7a1.fsf@jacob.g10code.de> <202503071721.15193.bernhard@intevation.de> Message-ID: <87jz90loa7.fsf@josefsson.org> Bernhard Reiter via Gnupg-devel writes: > Hi, > > got a problem report via the fediverse. > > == Background > > libassuan-3.0.0.tar.bz2 came on 2024-06-18 > and six days later there is 3.0.1 as quick-release upgrading the soname > to what it should have been (see citation below). > > == Problem description > > Arch Linux packaged the 3.0.0 release and has problems upgrading from it now. > Here is the problem description: > > " > with the release of 3.0.0 the soname changed from libassuan.so.0 to > libassuan.so.9. > Only with 3.0.1 the symbols have been changed from LIBASSUAN_1.0 to > LIBASSUAN_2.0 (which is the ABI breaking change that the soname change is > supposed to indicate). > > Since #pacman requires the library transitively via #gpgme, there now is no > clean way to upgrade this without patching all consumers in some intermediate > step. (The staging build environment would otherwise have a broken pacman and > thus not be functional). > > We are stuck on 3.0.0 because our packaging environment now requires > libassuan.so.9 with symbols LIBASSUAN_1.0. > " > > Does anybody have some ideas how to solve this for Arch Linux in an elegant > and efficiant way? How about a ArchLinux-specific patch to the libassuan 3.0.1 package to re-add so that the LIBASSUAN_1.0 symbol names are ALSO available? Then binaries linked against 3.0.0 will at least still behave the same with 3.0.1 as they did with 3.0.0, which may not be fully correct because some symbols may have changed their meaning compared to 2.x which presumably those packages were written to assume. All binaries built against 3.0.0 would then have to be rebuilt with 3.0.1 to start to use the LIBASSUAN_2.0 names. Then future upgrades should work. You have to keep the LIBASSUAN_1.0 symbol alias for as long as you want to support binaries built with the broken 3.0.0. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From ralph at ml.seichter.de Fri Mar 7 23:10:11 2025 From: ralph at ml.seichter.de (Ralph Seichter) Date: Fri, 07 Mar 2025 23:10:11 +0100 Subject: assuan.h:588:2 invalid preprocessing directive (Re: GnuPG 2.5.5 released) Message-ID: Here's an error I see when attempting to build on macOS: ---------- 8< ---------- 8< ---------- 8< ---------- /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in m4 make[3]: Nothing to be done for `all'. Making all in common /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/gnupg-2.5/share/locale\" -DGNUPG_BINDIR="\"/usr/local/gnupg-2.5/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/gnupg-2.5/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/gnupg-2.5/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/gnupg-2.5/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/gnupg-2.5/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/var\"" -DGNUPG_DEFAULT_AGENT="\"/usr/local/gnupg-2.5/bin/gpg-agent\"" -DGNUPG_DEFAULT_PINENTRY="\"/usr/local/gnupg-2.5/bin/pinentry\"" -DGNUPG_DEFAULT_SCDAEMON="\"/usr/local/gnupg-2.5/libexec/scdaemon\"" -DGNUPG_DEFAULT_DIRMNGR="\"/usr/local/gnupg-2.5/bin/dirmngr\"" -DGNUPG_DEFAULT_PROTECT_TOOL="\"/usr/local/gnupg-2.5/libexec/gpg-protect-tool\"" -DGNUPG_DEFAULT_DIRMNGR_LDAP="\"/usr/local/gnupg-2.5/libexec/dirmngr_ldap\"" -arch x86_64 -I/tmp/gpgosx-build-2.5.5/x86_64-dist/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.12 -Ofast -I/tmp/gpgosx-build-2.5.5/x86_64-dist/include -I/tmp/gpgosx-build-2.5.5/x86_64-dist/include -I/tmp/gpgosx-build-2.5.5/x86_64-dist/include -I/tmp/gpgosx-build-2.5.5/x86_64-dist/include -I/tmp/gpgosx-build-2.5.5/x86_64-dist/include -DWITHOUT_NPTH=1 -Wall -Wno-pointer-sign -Wpointer-arith -arch x86_64 -m64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.12 -Ofast -MT libcommon_a-sysutils.o -MD -MP -MF .deps/libcommon_a-sysutils.Tpo -c -o libcommon_a-sysutils.o `test -f 'sysutils.c' || echo './'`sysutils.c In file included from sysutils.c:84: /tmp/gpgosx-build-2.5.5/x86_64-dist/include/assuan.h:588:2: error: invalid preprocessing directive 588 | #defined ASSUAN_NO_NPTH_SYSTEM_HOOKS_ANY_MORE 1 | ^ 1 error generated. make[4]: *** [libcommon_a-sysutils.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 ---------- 8< ---------- 8< ---------- 8< ---------- Detailed build logs are available, should you need them. -Ralph From ametzler at bebt.de Sat Mar 8 18:40:36 2025 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 8 Mar 2025 18:40:36 +0100 Subject: assuan.h:588:2 invalid preprocessing directive (Re: GnuPG 2.5.5 released) In-Reply-To: References: Message-ID: On 2025-03-07 Ralph Seichter via Gnupg-devel wrote: > Here's an error I see when attempting to build on macOS: > ---------- 8< ---------- 8< ---------- 8< ---------- [...] > In file included from sysutils.c:84: > /tmp/gpgosx-build-2.5.5/x86_64-dist/include/assuan.h:588:2: error: invalid preprocessing directive > 588 | #defined ASSUAN_NO_NPTH_SYSTEM_HOOKS_ANY_MORE 1 > | ^ > 1 error generated. > make[4]: *** [libcommon_a-sysutils.o] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all] Error 2 > ---------- 8< ---------- 8< ---------- 8< ---------- > Detailed build logs are available, should you need them. Please upgrade to libassuan 3.0.2. See https://dev.gnupg.org/rAb8148b4f5735e1215eb72f208e1ae2891213247e cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ralph at ml.seichter.de Sun Mar 9 01:48:58 2025 From: ralph at ml.seichter.de (Ralph Seichter) Date: Sun, 09 Mar 2025 01:48:58 +0100 Subject: assuan.h:588:2 invalid preprocessing directive (Re: GnuPG 2.5.5 released) In-Reply-To: References: Message-ID: * Andreas Metzler: > https://dev.gnupg.org/rAb8148b4f5735e1215eb72f208e1ae2891213247e Thanks. I suspected a typo, but since I was able to build GnuPG 2.5.4 with libassuan 3.0.1, I was uncertain if there was perhaps more to it. -Ralph From bernhard at intevation.de Mon Mar 10 10:36:28 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Mar 2025 10:36:28 +0100 Subject: ArchLinux libassuan upgrade problem (related to: libassuan 3.0.0 bumped the soname without bumping the symbol versioning) In-Reply-To: <87jz90loa7.fsf@josefsson.org> References: <202503071721.15193.bernhard@intevation.de> <87jz90loa7.fsf@josefsson.org> Message-ID: <202503101036.37775.bernhard@intevation.de> https://chaos.social/@dvzrv/114125610003036424 notes that > It appears also Gentoo Linux is affected (see > https://social.treehouse.systems/@thesamesam/114120915949943686). > I believe that this situation could have been resolved by changing the > soname once more when changing the symbols in 3.0.1. > As is, I think another soname change should be made and the version 3.0.0, > 3.0.1 and 3.0.2 should be marked as "do not use". Okay, would bumping the soname again with 3.0.3 or be helpful? (At least this is what I understood is suggested. But I lack experience with all the packaging to estimate the consequences. All I want is Arch, Gentoo and others have a good paths forward.) Am Freitag 07 M?rz 2025 18:54:24 schrieb Simon Josefsson via Gnupg-devel: > Bernhard Reiter via Gnupg-devel writes: > > got a problem report via the fediverse. > > > > == Background > > > > libassuan-3.0.0.tar.bz2 came on 2024-06-18 > > and six days later there is 3.0.1 as quick-release upgrading the soname > > to what it should have been (see citation below). > > > > == Problem description > > > > Arch Linux packaged the 3.0.0 release and has problems upgrading from it > > now. Here is the problem description: > > > > " > > with the release of 3.0.0 the soname changed from libassuan.so.0 to > > libassuan.so.9. > > Only with 3.0.1 the symbols have been changed from LIBASSUAN_1.0 to > > LIBASSUAN_2.0 (which is the ABI breaking change that the soname change is > > supposed to indicate). > > > > Since #pacman requires the library transitively via #gpgme, there now is > > no clean way to upgrade this without patching all consumers in some > > intermediate step. (The staging build environment would otherwise have a > > broken pacman and thus not be functional). > > > > We are stuck on 3.0.0 because our packaging environment now requires > > libassuan.so.9 with symbols LIBASSUAN_1.0. > > " > > > > Does anybody have some ideas how to solve this for Arch Linux in an > > elegant and efficiant way? > > How about a ArchLinux-specific patch to the libassuan 3.0.1 package to > re-add so that the LIBASSUAN_1.0 symbol names are ALSO available? > > Then binaries linked against 3.0.0 will at least still behave the same > with 3.0.1 as they did with 3.0.0, which may not be fully correct > because some symbols may have changed their meaning compared to 2.x > which presumably those packages were written to assume. > > All binaries built against 3.0.0 would then have to be rebuilt with > 3.0.1 to start to use the LIBASSUAN_2.0 names. Then future upgrades > should work. You have to keep the LIBASSUAN_1.0 symbol alias for as > long as you want to support binaries built with the broken 3.0.0. Thanks Simon, I've forwarded to your suggestion (in a reply to the Fediverse post linked at the top). Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- 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 lists at sapience.com Thu Mar 13 12:45:45 2025 From: lists at sapience.com (Genes Lists) Date: Thu, 13 Mar 2025 07:45:45 -0400 Subject: libgcrypt little build fail in doc with latest git commit Message-ID: <91ac6f9d685199ab5b04ce0c113406499ae1001b.camel@sapience.com> FYI git commit 636f40cb78587635ef663bfc3430937cf140f245 Fils in doc with: for file in gcrypt.texi ; do \ ? ? ?./yat2m -I . --release "Libgcrypt 1.11.1-beta126" --source "Libgcrypt" --store \ ? ? ? ? ?`test -f '$file' || echo './'`$file ; done gcrypt.texi:1085: unknown command `endexample' gcrypt.texi:1087: `@end' expected `example', but saw `table' make[3]: *** [Makefile:449: gcrypt.info] Error 1 -- Gene -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 pschwabauer at intevation.de Thu Mar 13 14:13:26 2025 From: pschwabauer at intevation.de (Paul Schwabauer) Date: Thu, 13 Mar 2025 14:13:26 +0100 Subject: Future of GpgME python bindings on PyPi Message-ID: The current PyPi entry for the GpgMe bindings (https://pypi.org/project/gpg/) is unmaintained. Unfortunately, some projects, like Roundup for GPG support, still rely on this entry. The outdated version of the bindings contains an invalid code sequence that causes compatibility issues with newer Python versions (for more details, see the issue: https://issues.roundup-tracker.org/issue2551368). There are two potential courses of action: 1. *Declare the entry as unmaintained*: Notify all users that this package should no longer be used and recommend alternative, actively maintained bindings. 2. *Assign a maintainer to the PyPi entry*: Upload a new version and fix the build issues to ensure proper functionality. Currently, the existing Python bindings cannot correctly build a source distribution due to missing files in the package. I had to use workarounds to build the distribution. For reference, here are the steps I followed to successfully build the package: https://issues.roundup-tracker.org/msg8362. For testing purposes, I uploaded a version of the bindings to the PyPi testing index: https://test.pypi.org/project/gpg/. At present, Bernhard Reiter has access to the GPG entry. I would like to extend access to someone with write access to the |gpgmepy| repository who is interested in maintaining and uploading new versions of the bindings. Ideally, I hope this entry continues to be updated, as doing so could help identify issues that might affect users who do not directly use the bindings via PyPi. From wk at gnupg.org Thu Mar 13 18:07:21 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Mar 2025 18:07:21 +0100 Subject: libgcrypt little build fail in doc with latest git commit In-Reply-To: <91ac6f9d685199ab5b04ce0c113406499ae1001b.camel@sapience.com> (Genes Lists via Gnupg-devel's message of "Thu, 13 Mar 2025 07:45:45 -0400") References: <91ac6f9d685199ab5b04ce0c113406499ae1001b.camel@sapience.com> Message-ID: <87jz8s506u.fsf@jacob.g10code.de> On Thu, 13 Mar 2025 07:45, Genes Lists said: > gcrypt.texi:1085: unknown command `endexample' > gcrypt.texi:1087: `@end' expected `example', but saw `table' Thanks. Fixed. 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 kloecker at kde.org Thu Mar 13 22:28:16 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Thu, 13 Mar 2025 22:28:16 +0100 Subject: Future of GpgME python bindings on PyPi In-Reply-To: References: Message-ID: <5663542.rdbgypaU67@daneel> On Donnerstag, 13. M?rz 2025 14:13:26 Mitteleurop?ische Normalzeit Paul Schwabauer via Gnupg-devel wrote: > At present, Bernhard Reiter has access to the GPG entry. I would like to > extend access to someone with write access to the |gpgmepy| repository > who is interested in maintaining and uploading new versions of the > bindings. Ideally, I hope this entry continues to be updated, as doing > so could help identify issues that might affect users who do not > directly use the bindings via PyPi. I'm happy to review and apply patches for gpgmepy, but I'm not motivated to maintain a PyPI entry because I don't use the bindings and I prefer to maintain only stuff I'm using myself. 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: