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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
+;;
+;; 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 <https://www.gnu.org/licenses/>.
+
+(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: <CA+=ghCgbCQ6KnWOkD3CkXDRDzyNcJYSLEhVKzryTOOEr06u2TQ@mail.gmail.com>
 <874j0qcpcj.fsf@jacob.g10code.de>
Message-ID: <CA+=ghCgRB3_mRV-a9cAgb_s8efFw2QTs3iEya11h1Sp1HTkoqQ@mail.gmail.com>

Any news, please?

On Wed, Feb 19, 2025 at 9:25?AM Werner Koch <wk at gnupg.org> 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 <https://gnupg.org/download/> 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
<https://gnupg.org/download/mirrors.html>.  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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250307/a518c126/attachment-0001.sig>
-------------- 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: <Znmcwj8zwqMC_nRL@argenau.bebt.de>
References: <Znb5VZTrxZITQjyG@argenau.bebt.de>
 <87y16uk7a1.fsf@jacob.g10code.de> <Znmcwj8zwqMC_nRL@argenau.bebt.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 <wk at gnupg.org> 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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250307/4a1bc385/attachment.sig>

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: <Znb5VZTrxZITQjyG@argenau.bebt.de>
 <87y16uk7a1.fsf@jacob.g10code.de> <Znmcwj8zwqMC_nRL@argenau.bebt.de>
 <202503071721.15193.bernhard@intevation.de>
Message-ID: <87jz90loa7.fsf@josefsson.org>

Bernhard Reiter via Gnupg-devel <gnupg-devel at gnupg.org> 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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250307/2bb3f956/attachment.sig>

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: <D8ADLY3AUSYG.1AHYKR8YWPPNY@ml.seichter.de>

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: <D8ADLY3AUSYG.1AHYKR8YWPPNY@ml.seichter.de>
References: <D8ADLY3AUSYG.1AHYKR8YWPPNY@ml.seichter.de>
Message-ID: <Z8yBFDekdUFvJXdm@argenau.bebt.de>

On 2025-03-07 Ralph Seichter via Gnupg-devel <gnupg-devel at gnupg.org> 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: <Z8yBFDekdUFvJXdm@argenau.bebt.de>
References: <D8ADLY3AUSYG.1AHYKR8YWPPNY@ml.seichter.de>
 <Z8yBFDekdUFvJXdm@argenau.bebt.de>
Message-ID: <D8BBM2GHJXTD.1QELN04FMKP2A@ml.seichter.de>

* 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: <Znb5VZTrxZITQjyG@argenau.bebt.de>
 <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 <gnupg-devel at gnupg.org> 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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250310/d57af8be/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250313/94c9b8d8/attachment-0001.html>
-------------- 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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250313/94c9b8d8/attachment-0001.sig>

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: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250313/fdb21004/attachment.sig>

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: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250313/eae20c8c/attachment.sig>

From ramon.garcia.f at gmail.com  Sat Mar 15 16:57:20 2025
From: ramon.garcia.f at gmail.com (=?UTF-8?B?UmFtw7NuIEdhcmPDrWE=?=)
Date: Sat, 15 Mar 2025 16:57:20 +0100
Subject: Gpgsm should skip expired certificates when there is a valid one
In-Reply-To: <CA+=ghCgRB3_mRV-a9cAgb_s8efFw2QTs3iEya11h1Sp1HTkoqQ@mail.gmail.com>
References: <CA+=ghCgbCQ6KnWOkD3CkXDRDzyNcJYSLEhVKzryTOOEr06u2TQ@mail.gmail.com>
 <874j0qcpcj.fsf@jacob.g10code.de>
 <CA+=ghCgRB3_mRV-a9cAgb_s8efFw2QTs3iEya11h1Sp1HTkoqQ@mail.gmail.com>
Message-ID: <CA+=ghCh0mZVmrf_GT22S0QLb_YtsAR1T0yW7=Wp5RRC3LZsVeA@mail.gmail.com>

Any news? Is there something I can do?

On Wed, Mar 5, 2025 at 5:45?PM Ram?n Garc?a <ramon.garcia.f at gmail.com> wrote:
>
> Any news, please?
>
> On Wed, Feb 19, 2025 at 9:25?AM Werner Koch <wk at gnupg.org> 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 ramon.garcia.f at gmail.com  Sun Mar 16 21:37:33 2025
From: ramon.garcia.f at gmail.com (=?UTF-8?B?UmFtw7NuIEdhcmPDrWE=?=)
Date: Sun, 16 Mar 2025 21:37:33 +0100
Subject: Gpgsm should skip expired certificates when there is a valid one
In-Reply-To: <874j0qcpcj.fsf@jacob.g10code.de>
References: <CA+=ghCgbCQ6KnWOkD3CkXDRDzyNcJYSLEhVKzryTOOEr06u2TQ@mail.gmail.com>
 <874j0qcpcj.fsf@jacob.g10code.de>
Message-ID: <CA+=ghCgk7tSPAOazK4j=2kmyJwvB9y+KqHf6OSrvoTcMUD3UXg@mail.gmail.com>

Any news? Is there anything that I should do?

On Wed, Feb 19, 2025 at 9:25?AM Werner Koch <wk at gnupg.org> 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 dkg at fifthhorseman.net  Mon Mar 17 23:06:39 2025
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 17 Mar 2025 18:06:39 -0400
Subject: gpgme 1.24.2 git tag missing?
Message-ID: <877c4nuxao.fsf@fifthhorseman.net>

Hey folks--

I see a release of gpgme 1.24.2 at
https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.24.2.tar.bz2 but i don't see
any tag for it when i git clone https://dev.gnupg.org/source/gpgme.git

perhaps some tag failed to be pushed?

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250317/9f4aacf0/attachment.sig>

From wk at gnupg.org  Tue Mar 18 12:29:01 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Mar 2025 12:29:01 +0100
Subject: Gpgsm should skip expired certificates when there is a valid one
In-Reply-To: <CA+=ghCh0mZVmrf_GT22S0QLb_YtsAR1T0yW7=Wp5RRC3LZsVeA@mail.gmail.com>
 (=?utf-8?Q?=22Ram=C3=B3n_Garc=C3=ADa?= via Gnupg-devel"'s message of "Sat,
 15 Mar 2025 16:57:20 +0100")
References: <CA+=ghCgbCQ6KnWOkD3CkXDRDzyNcJYSLEhVKzryTOOEr06u2TQ@mail.gmail.com>
 <874j0qcpcj.fsf@jacob.g10code.de>
 <CA+=ghCgRB3_mRV-a9cAgb_s8efFw2QTs3iEya11h1Sp1HTkoqQ@mail.gmail.com>
 <CA+=ghCh0mZVmrf_GT22S0QLb_YtsAR1T0yW7=Wp5RRC3LZsVeA@mail.gmail.com>
Message-ID: <87v7s6bmrm.fsf@jacob.g10code.de>

Hi!

On Sat, 15 Mar 2025 16:57, Ram?n Garc?a said:
> Any news? Is there something I can do?

Alright, I pushed your changes.  It was quite a bit of work because your
patches were broken (indentation changes, extra line breaks and diff
structure corrupt).  If your mailer does not handle mails correctly, you
shold better put the output of git format-patch as an attachment to your
mail.

I also took the opportunity to clean up a few things and changed the log
entries to the format used by GNU projects and described in doc/HACKING
;-).  In any case many thanks for this patch and fixing a long standing
feature request.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250318/b5127f7a/attachment.sig>

From ramon.garcia.f at gmail.com  Tue Mar 18 13:51:37 2025
From: ramon.garcia.f at gmail.com (=?UTF-8?B?UmFtw7NuIEdhcmPDrWE=?=)
Date: Tue, 18 Mar 2025 13:51:37 +0100
Subject: Gpgsm should skip expired certificates when there is a valid one
In-Reply-To: <87v7s6bmrm.fsf@jacob.g10code.de>
References: <CA+=ghCgbCQ6KnWOkD3CkXDRDzyNcJYSLEhVKzryTOOEr06u2TQ@mail.gmail.com>
 <874j0qcpcj.fsf@jacob.g10code.de>
 <CA+=ghCgRB3_mRV-a9cAgb_s8efFw2QTs3iEya11h1Sp1HTkoqQ@mail.gmail.com>
 <CA+=ghCh0mZVmrf_GT22S0QLb_YtsAR1T0yW7=Wp5RRC3LZsVeA@mail.gmail.com>
 <87v7s6bmrm.fsf@jacob.g10code.de>
Message-ID: <CA+=ghCg=4AWi9t1-EnXJisd_yw9EMayce1Gk_W4u6hmoD+d1Nw@mail.gmail.com>

Thank you very much. I used the Gmail browser interface. Next time I
will try with Thunderbird.

On Tue, Mar 18, 2025 at 12:27?PM Werner Koch <wk at gnupg.org> wrote:
>
> Hi!
>
> On Sat, 15 Mar 2025 16:57, Ram?n Garc?a said:
> > Any news? Is there something I can do?
>
> Alright, I pushed your changes.  It was quite a bit of work because your
> patches were broken (indentation changes, extra line breaks and diff
> structure corrupt).  If your mailer does not handle mails correctly, you
> shold better put the output of git format-patch as an attachment to your
> mail.
>
> I also took the opportunity to clean up a few things and changed the log
> entries to the format used by GNU projects and described in doc/HACKING
> ;-).  In any case many thanks for this patch and fixing a long standing
> feature request.
>
>
> Shalom-Salam,
>
>    Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein


From tmz at pobox.com  Tue Mar 18 14:13:11 2025
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 18 Mar 2025 09:13:11 -0400
Subject: Gpgsm should skip expired certificates when there is a valid one
In-Reply-To: <CA+=ghCg=4AWi9t1-EnXJisd_yw9EMayce1Gk_W4u6hmoD+d1Nw@mail.gmail.com>
References: <CA+=ghCgbCQ6KnWOkD3CkXDRDzyNcJYSLEhVKzryTOOEr06u2TQ@mail.gmail.com>
 <874j0qcpcj.fsf@jacob.g10code.de>
 <CA+=ghCgRB3_mRV-a9cAgb_s8efFw2QTs3iEya11h1Sp1HTkoqQ@mail.gmail.com>
 <CA+=ghCh0mZVmrf_GT22S0QLb_YtsAR1T0yW7=Wp5RRC3LZsVeA@mail.gmail.com>
 <87v7s6bmrm.fsf@jacob.g10code.de>
 <CA+=ghCg=4AWi9t1-EnXJisd_yw9EMayce1Gk_W4u6hmoD+d1Nw@mail.gmail.com>
Message-ID: <Z9lxZ-Z6kKDSBelk@teonanacatl.net>

Ram?n Garc?a via Gnupg-devel wrote:
> Thank you very much. I used the Gmail browser interface. Next time I
> will try with Thunderbird.

https://git-scm.com/docs/git-format-patch#_mua_specific_hints
may be useful.

An alternative is to use `git send-email` with the output of
`git format-patch` to sidestep the many ways various MUA's
mangle text.

-- 
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250318/694d7706/attachment.sig>

From bernhard at intevation.de  Tue Mar 18 17:26:19 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 18 Mar 2025 17:26:19 +0100
Subject: Future of GpgME python bindings on PyPi
In-Reply-To: <5663542.rdbgypaU67@daneel>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <5663542.rdbgypaU67@daneel>
Message-ID: <202503181726.26125.bernhard@intevation.de>

Ingo, Werner,

what is the state of the python bindings and g10code's plan for it?

Paul and myself could try to get at least the current version
of https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgmepy.git;a=summary
up to Pypi. It seems helpful to show that the bindings still exist.

Technical: What is the python version number of current main branch?
setup.py will generate 2.0.0b4, is this correct or should it be
  2.0.0.dev4 or so?

(Background for others, Python modules' version numbering is different
from Semver, see 
https://packaging.python.org/en/latest/discussions/versioning/)

Am Donnerstag 13 M?rz 2025 22:28:16 schrieb Ingo Kl?cker:
> 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 am acting as interims holder of the access, until a new maintainer is found.

> > 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.

Would you grant Paul and myself write access?
We are planning some interims maintenance.
Are you okay with me giving Paul access to gpg's PyPi entry?

> > 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.

That means you are using gpgmepy, aka python3-gpg?
We saw that the last commits all came from you. :)

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250318/0059f4df/attachment.sig>

From wahern at akamai.com  Tue Mar 18 18:43:04 2025
From: wahern at akamai.com (Ahern, William)
Date: Tue, 18 Mar 2025 17:43:04 +0000
Subject: FIPS-mode keygen fails to include preferences subpackets
Message-ID: <A8576175-0536-45D1-9D74-4C99740383E8@akamai.com>

When libgcrypt is in FIPS mode GnuPG g10/keygen.c:keygen_set_std_prefs fails entirely in the absence of an explicit preference list, resulting in the symmetric cipher preference list and similar subpackets being omitted from the generated public key. It also effects the features subpacket. Additionally, for senders using releases before GPG 2.3.x this has the effect of causing GnuPG (in FIPS mode) to fail encryption as it defaults to 3DES in the absence of a public key preference list, regardless of runtime support.

The root cause is that 1) "S2" (i.e. 3DES) is unconditionally added to the default generated preference string causing 2) keygen_set_std_prefs to fail. keygen_set_stdprefs bails out entirely when any preference algorithm cannot be decoded using string_to_cipher_algo, even when all but one were successfully decoded. A simple fix is to use "3DES" instead of "S2" when generating the default preference list string (see top of keygen_set_std_prefs). That works because string_to_cipher_algo succeeds for "3DES" but not "S2", even in FIPS mode. The former takes a path through libgcrypt that simply maps the name to an identifier using the built-in algorithm table, whereas for "S2" a separate pathway is taken that actually queries runtime support, which will fail in FIPS mode.

Locally we're using the simple fix, but a better solution might be to 1) add "S2" conditionally, similar to how AES is treated, and 2) refactor the second half of keygen_set_std_prefs to continue processing algorithms, only failing later if none were matched in a set. I'd be happy to craft that patch if that seems like the better solution.

Regards,

- Bill




From kloecker at kde.org  Tue Mar 18 21:27:03 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Tue, 18 Mar 2025 21:27:03 +0100
Subject: Future of GpgME python bindings on PyPi
In-Reply-To: <202503181726.26125.bernhard@intevation.de>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <5663542.rdbgypaU67@daneel> <202503181726.26125.bernhard@intevation.de>
Message-ID: <2807036.QOukoFCf94@daneel>

On Dienstag, 18. M?rz 2025 17:26:19 Mitteleurop?ische Normalzeit Bernhard 
Reiter via Gnupg-devel wrote:
> Ingo, Werner,
> 
> what is the state of the python bindings and g10code's plan for it?

I cannot speak for g10 Code.

See the message you replied to for my "plan".

Regarding the state: I have no idea. When I split the repo I made sure that 
the bindings build with all versions of Python 3 provided by openSUSE 
Tumbleweed (which are all not EOL versions) and that the unit tests pass.

I think now that we have finally dropped support for Python 2 the build could 
be modernized. Patches are welcome.

> Paul and myself

Excuse my ignorance, but Paul who?

> could try to get at least the current version
> of https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgmepy.git;a=summary
> up to Pypi. It seems helpful to show that the bindings still exist.

+1 from me.

> Technical: What is the python version number of current main branch?
> setup.py will generate 2.0.0b4, is this correct or should it be
>   2.0.0.dev4 or so?

In general we use beta numbering so that 2.0.0b4 looks right.

> (Background for others, Python modules' version numbering is different
> from Semver, see
> https://packaging.python.org/en/latest/discussions/versioning/)
> 
> Am Donnerstag 13 M?rz 2025 22:28:16 schrieb Ingo Kl?cker:
> > 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 am acting as interims holder of the access, until a new maintainer is
> found.
>
> > > 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.
> 
> Would you grant Paul and myself write access?
> We are planning some interims maintenance.
> Are you okay with me giving Paul access to gpg's PyPi entry?
> 
> > > 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.
> 
> That means you are using gpgmepy, aka python3-gpg?

No, I'm not using the Python bindings. Therefore, I don't want to maintain 
them actively. I'd still review and apply patches if nobody else with write 
access to the repository does.

> We saw that the last commits all came from you. :)

I applied a few patches from others and made sure that it still builds after 
the split. It also shows that the bindings are barely alive and it gives me 
the impression that almost nobody cares.

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250318/e76b4001/attachment.sig>

From lucc at posteo.de  Wed Mar 19 00:17:18 2025
From: lucc at posteo.de (Lucas Hoffmann)
Date: Tue, 18 Mar 2025 23:17:18 +0000
Subject: Future of GpgME python bindings on PyPi
In-Reply-To: <2807036.QOukoFCf94@daneel>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <5663542.rdbgypaU67@daneel> <202503181726.26125.bernhard@intevation.de>
 <2807036.QOukoFCf94@daneel>
Message-ID: <174233983828.22902.2258499130036330260@yoga>

Quoting Ingo Kl?cker (2025-03-18 21:27:03)
> I think now that we have finally dropped support for Python 2 the build could
> be modernized. Patches are welcome.

Are you talking about the pyproject.toml file that emerged in the python
ecosystem?  I think it is possible to move some metadata from setup.py
to this file and also specify the minimum requirement for setuptools.
That could free the code of the distutils references.

If that is desired I can try to prepare a patch and send it to the list.

> > could try to get at least the current version
> > of https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgmepy.git;a=summary
> > up to Pypi. It seems helpful to show that the bindings still exist.
>
> +1 from me.

Also +1 from me. I am speaking on behalf of alot
(https://github.com/pazz/alot), a mail user agent that uses the gpg
python bindings.  We would greatly profit from an updated PyPI package.

Best Regards,
Lucas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250318/113b2de8/attachment-0001.sig>

From kloecker at kde.org  Wed Mar 19 10:03:18 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Wed, 19 Mar 2025 10:03:18 +0100
Subject: Future of GpgME python bindings on PyPi
In-Reply-To: <174233983828.22902.2258499130036330260@yoga>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <2807036.QOukoFCf94@daneel> <174233983828.22902.2258499130036330260@yoga>
Message-ID: <2739655.vuYhMxLoTh@daneel>

On Mittwoch, 19. M?rz 2025 00:17:18 Mitteleurop?ische Normalzeit Lucas Hoffmann 
via Gnupg-devel wrote:
> Quoting Ingo Kl?cker (2025-03-18 21:27:03)
> 
> > I think now that we have finally dropped support for Python 2 the build
> > could be modernized. Patches are welcome.
> 
> Are you talking about the pyproject.toml file that emerged in the python
> ecosystem?  I think it is possible to move some metadata from setup.py
> to this file and also specify the minimum requirement for setuptools.
> That could free the code of the distutils references.

I think that's what I had in mind. It's been some time since I last looked 
into Python packaging.

> If that is desired I can try to prepare a patch and send it to the list.

That would be great.

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250319/19a10fa6/attachment.sig>

From bernhard at intevation.de  Wed Mar 19 17:01:58 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 19 Mar 2025 17:01:58 +0100
Subject: Future of GpgME python bindings on PyPi
In-Reply-To: <2807036.QOukoFCf94@daneel>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <202503181726.26125.bernhard@intevation.de> <2807036.QOukoFCf94@daneel>
Message-ID: <202503191702.04713.bernhard@intevation.de>

Hi Ingo,

Am Dienstag 18 M?rz 2025 21:27:03 schrieb Ingo Kl?cker:
> On Dienstag, 18. M?rz 2025 17:26:19 Mitteleurop?ische Normalzeit Bernhard
>
> Reiter via Gnupg-devel wrote:
> > Ingo, Werner,
> >
> > what is the state of the python bindings and g10code's plan for it?
>
> I cannot speak for g10 Code.

that why I have also addressed Werner.
And it would have been possible that you were working
on the python bindings on behalf of g10code. :)

Thanks for your work on the python gpgme bindings!

> Excuse my ignorance, but Paul who?

The one you've replied to originally,
   Paul Schwabauer <pschwabauer at intevation.de>
he is an employee of my company Intevation.

(I forgot: These days the email address can only be seen
 in the reply-to header.)

> I applied a few patches from others and made sure that it still builds
> after the split. It also shows that the bindings are barely alive and it
> gives me the impression that almost nobody cares.

Beside Lucas who has meanwhile replied, I've also got a personal email
asking for the bindings and a technical analysis, and we've checked into the 
roundup issue. So there are at least three Free Software product that care a 
bit.

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250319/17fe2694/attachment.sig>

From bernhard at intevation.de  Wed Mar 19 17:24:38 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 19 Mar 2025 17:24:38 +0100
Subject: Version number of GpgME python bindings on PyPi
In-Reply-To: <2807036.QOukoFCf94@daneel>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <202503181726.26125.bernhard@intevation.de> <2807036.QOukoFCf94@daneel>
Message-ID: <202503191724.44578.bernhard@intevation.de>

Am Dienstag 18 M?rz 2025 21:27:03 schrieb Ingo Kl?cker:
> > Technical: What is the python version number of current main branch?
> > setup.py will generate 2.0.0b4, is this correct or should it be
> > ? 2.0.0.dev4 or so?
>
> In general we use beta numbering so that 2.0.0b4 looks right.

As gpgme is still 1.x where does the major bump to 2 come from?


-- 
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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250319/9707954b/attachment.sig>

From ametzler at bebt.de  Wed Mar 19 18:08:50 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 19 Mar 2025 18:08:50 +0100
Subject: Version number of GpgME python bindings on PyPi
In-Reply-To: <202503191724.44578.bernhard@intevation.de>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <202503181726.26125.bernhard@intevation.de>
 <2807036.QOukoFCf94@daneel>
 <202503191724.44578.bernhard@intevation.de>
Message-ID: <Z9r6IkGZMZcTl5yH@argenau.bebt.de>

On 2025-03-19 Bernhard Reiter via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> Am Dienstag 18 M?rz 2025 21:27:03 schrieb Ingo Kl?cker:
> > > Technical: What is the python version number of current main branch?
> > > setup.py will generate 2.0.0b4, is this correct or should it be
> > > ? 2.0.0.dev4 or so?
> >
> > In general we use beta numbering so that 2.0.0b4 looks right.

> As gpgme is still 1.x where does the major bump to 2 come from?

Hello,

The original plan for splitting of C++ QT and python bindings was to
make a quick release after the split without further changes and version
this as 2.0.0 to make clear that it was a bigger change (people will
need to adapt their packahing workflow) although the ABI/API was
going to be unchanged.

That did not happen, but the 2.x version number is still planned.
https://dev.gnupg.org/T7262

cu Andreas


From kloecker at kde.org  Wed Mar 19 20:55:05 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Wed, 19 Mar 2025 20:55:05 +0100
Subject: Future of GpgME python bindings on PyPi
In-Reply-To: <202503191702.04713.bernhard@intevation.de>
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <2807036.QOukoFCf94@daneel> <202503191702.04713.bernhard@intevation.de>
Message-ID: <2172702.9o76ZdvQCi@daneel>

On Mittwoch, 19. M?rz 2025 17:01:58 Mitteleurop?ische Normalzeit Bernhard 
Reiter via Gnupg-devel wrote:
> Am Dienstag 18 M?rz 2025 21:27:03 schrieb Ingo Kl?cker:
> > On Dienstag, 18. M?rz 2025 17:26:19 Mitteleurop?ische Normalzeit Bernhard
> > Reiter via Gnupg-devel wrote:
> > > Ingo, Werner,
> > > 
> > > what is the state of the python bindings and g10code's plan for it?
> > 
> > I cannot speak for g10 Code.
> 
> that why I have also addressed Werner.
> And it would have been possible that you were working
> on the python bindings on behalf of g10code. :)
> 
> Thanks for your work on the python gpgme bindings!

I'm working on gpgme (mostly gpgme++ and qgpgme) on behalf of g10code. My 
little work on the python bindings is just a byproduct.

> > I applied a few patches from others and made sure that it still builds
> > after the split. It also shows that the bindings are barely alive and it
> > gives me the impression that almost nobody cares.
> 
> Beside Lucas who has meanwhile replied, I've also got a personal email
> asking for the bindings and a technical analysis, and we've checked into the
> roundup issue. So there are at least three Free Software product that care
> a bit.

That's good to hear.

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250319/6e3f3e1b/attachment.sig>

From wk at gnupg.org  Thu Mar 20 13:10:07 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 20 Mar 2025 13:10:07 +0100
Subject: gpgme 2.0 ABI break (Re: Version number of GpgME python bindings on
 PyPi)
In-Reply-To: <Z9r6IkGZMZcTl5yH@argenau.bebt.de> (Andreas Metzler's message of
 "Wed, 19 Mar 2025 18:08:50 +0100")
References: <d01785c1-b64f-4e64-a3ed-59f72797d8c2@intevation.de>
 <202503181726.26125.bernhard@intevation.de>
 <2807036.QOukoFCf94@daneel>
 <202503191724.44578.bernhard@intevation.de>
 <Z9r6IkGZMZcTl5yH@argenau.bebt.de>
Message-ID: <871purc38g.fsf_-_@jacob.g10code.de>

Hi!

On Wed, 19 Mar 2025 18:08, Andreas Metzler said:

> The original plan for splitting of C++ QT and python bindings was to
> make a quick release after the split without further changes and version

We had the very first API still in GPGME although that it has been
decreated for >20 years.  I doubt that anyone still uses it but
technically removing this API is an ABI break and as such a bump of the
major version is required.  Given hat we wanted to bump the version
anyway, it seemed to be the Right Thing to also drop that old API.

 * Removed the gpgme_attr_t enums and their functions which were
   deprecated since 2003.  [rMd54d6eaa64]

 * Removed the never implemented or announced GPGME_EXPORT_MODE_NOUID
   flags.  [rMd54d6eaa64]

 * Removed the entire trustlist feature which worked anyway only for a
   short period in 2003.  [T4834]

I planned to talk with Ingo about the release yesterday but
unfortuantely I caught a flu and won't be able to do any serious work
the next days.  But doing a release next week should be possible.


Shalom-Salam,

   Werner


p.s.
I don't really care about PyPi because I consider these platforms to be
a major security problem.  YMMV, so Bernard or whoever may take care
of PyPi stuff for gpgmepy.

-- 
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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250320/26d0a593/attachment.sig>

From lucc at posteo.de  Sun Mar 23 23:47:14 2025
From: lucc at posteo.de (Lucas Hoffmann)
Date: Sun, 23 Mar 2025 22:47:14 +0000
Subject: [PATCH gnupgpy 0/5] Modernize python build for gpgmepy
Message-ID: <174277003465.373069.17602536947672357293@yoga>

These patches modernize the build process for the gpgmepy repository.
This was suggested in message 2807036.QOukoFCf94 at daneel
(https://lists.gnupg.org/pipermail/gnupg-devel/2025-March/035822.html).

Please note that this is my first contribution to any gnupg project. You
can find my DCO attached to this message.

Some notes about the individual patches:

- I tried to move as much metadata from the setup.py(.in) file to the
  pyproject.toml file because it is static in two senses:  It is not
  touched by configure and friends and it can be parsed without
  executing it.  I consider both of these advantages for project
  metadata.

- I specified the minimum python version as 3.6.  From the message of
  1a7b204dedaf99efa08915ee561523997175380c it seems that 3.6 was kept
  because it is supported by some Linux distros.  Otherwise a good list
  of versions to support would be the versions supported upstream:
  https://devguide.python.org/versions/ Is there some spelled out policy
  which python versions should be supported?  Should the project have
  one?

- I do not know the m4 macro language and just made the commit "Remove
  distutils related code from configure macros" based on my knowledge of
  shell and python.  I tested the change by running configure on my
  machine.

I tried to search for related issues and patches on the bug tracker but
only found https://dev.gnupg.org/D545 which seems to be partially
applied by a7cfdab46f853397794575307a817982cdd06880.  Did I miss any
important issues or patches that could be incorporated into this series?

I tested my changes on my machine by running `make distclean &&
./configure --enable-maintainer-mode && make check`.  All but one tests
pass; the test t-verify.py is reported twice as failure.  This is the
same on master and with these patches.  Is there some kind of CI or
defined testing environment (docker container, VM, etc) that I can use?
Is this test known to fail or is this a problem with my setup (I am on
nixos if it matters)?

Please reply with your feedback, I am happy to fix problems that these
patches might have.

Best regards,
Lucas

PS: Overview of the patches:

Lucas Hoffmann (5):
  build: Migrate project metadata to pyproject.toml
  build: Specify minimum required python version
  build: Drop distutils from setup.py
  build: Move long description from to pyproject.toml
  build: Remove distutils related code from configure macros

 m4/ax_python_devel.m4 | 66 ++++++++++++-------------------------------
 m4/python.m4          | 42 ++++++---------------------
 pyproject.toml        | 63 +++++++++++++++++++++++++++++++++++++++++
 setup.py.in           | 59 ++------------------------------------
 4 files changed, 92 insertions(+), 138 deletions(-)
 create mode 100644 pyproject.toml

--
2.48.1
-------------- next part --------------
GPGME Python Bindings Developer's Certificate of Origin.  Version 1.0
=====================================================================

By making a contribution to the GPGME Python Bindings 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: Lucas Hoffmann <lucc at posteo.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250323/695ad933/attachment-0001.sig>

From lucc at posteo.de  Sun Mar 23 23:49:07 2025
From: lucc at posteo.de (lucc at posteo.de)
Date: Sun, 23 Mar 2025 22:49:07 +0000
Subject: [PATCH gnupgpy 1/5] build: Migrate project metadata to pyproject.toml
In-Reply-To: <174277003465.373069.17602536947672357293@yoga>
References: <174277003465.373069.17602536947672357293@yoga>
Message-ID: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>


* pyproject.toml: New.
* setup.py.in: Migrate some static metadata to the new pyproject.toml
file
--

This commit just migrates the metadata without any further changes.  All
updates and modernisations follow in later commits.

Signed-off-by: Lucas Hoffmann <lucc at posteo.de>
---
 pyproject.toml | 37 +++++++++++++++++++++++++++++++++++++
 setup.py.in    | 25 -------------------------
 2 files changed, 37 insertions(+), 25 deletions(-)
 create mode 100644 pyproject.toml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-Migrate-project-metadata-to-pyproject.toml.patch
Type: text/x-patch
Size: 3470 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250323/8e74a8b8/attachment.bin>

From lucc at posteo.de  Sun Mar 23 23:49:08 2025
From: lucc at posteo.de (lucc at posteo.de)
Date: Sun, 23 Mar 2025 22:49:08 +0000
Subject: [PATCH gnupgpy 2/5] build: Specify minimum required python version
In-Reply-To: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
References: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
Message-ID: <4ba32f03fc3560430c1f29edc00e6c7066dfcdb0.1742770151.git.lucc@posteo.de>


* pyproject.toml: Specify minimum required python version, also drop
classifiers for old python versions.
--

Python 2 was dropped previously,
See-Commit 5fe5e7c5aa75509dd9d983a9bf0da3d3f09a9b53.

Signed-off-by: Lucas Hoffmann <lucc at posteo.de>
---
 pyproject.toml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-build-Specify-minimum-required-python-version.patch
Type: text/x-patch
Size: 838 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250323/3d4c2572/attachment.bin>

From lucc at posteo.de  Sun Mar 23 23:49:09 2025
From: lucc at posteo.de (lucc at posteo.de)
Date: Sun, 23 Mar 2025 22:49:09 +0000
Subject: [PATCH gnupgpy 3/5] build: Drop distutils from setup.py
In-Reply-To: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
References: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
Message-ID: <a5c5dd7b2b1dd88eb3a02de7645a03795b13e371.1742770151.git.lucc@posteo.de>


* setup.py.in: Drop fallback code for distutils in case setuptools is
not available
--

We are now using the pyproject.toml file to statically declare our build
time dependencies.  This ensures that a compatible version of setuptools
should be available by the time the setup.py file is executed.  For that
reason we do not need the fallback code any longer.

Also order imports according to PEP-8 and drop unused "glob" import.

Signed-off-by: Lucas Hoffmann <lucc at posteo.de>
---
 setup.py.in | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-build-Drop-distutils-from-setup.py.patch
Type: text/x-patch
Size: 786 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250323/6e4447b7/attachment.bin>

From lucc at posteo.de  Sun Mar 23 23:49:11 2025
From: lucc at posteo.de (lucc at posteo.de)
Date: Sun, 23 Mar 2025 22:49:11 +0000
Subject: [PATCH gnupgpy 5/5] build: Remove distutils related code from
 configure macros
In-Reply-To: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
References: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
Message-ID: <e328beb58d5b6ae8000fa923fb27355a03a04c10.1742770151.git.lucc@posteo.de>


* m4/ax_python_devel.m4, m4/python.m4: Remove all distutils related code
and only check for the stdlib sysconfig module instead.
--

Signed-off-by: Lucas Hoffmann <lucc at posteo.de>
---
 m4/ax_python_devel.m4 | 66 ++++++++++++-------------------------------
 m4/python.m4          | 42 ++++++---------------------
 2 files changed, 26 insertions(+), 82 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-build-Remove-distutils-related-code-from-configure-m.patch
Type: text/x-patch
Size: 8200 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250323/c1dc2873/attachment.bin>

From lucc at posteo.de  Sun Mar 23 23:49:10 2025
From: lucc at posteo.de (lucc at posteo.de)
Date: Sun, 23 Mar 2025 22:49:10 +0000
Subject: [PATCH gnupgpy 4/5] build: Move long description to pyproject.toml
In-Reply-To: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
References: <6eba00156c7671b9eb2646ad66d6313a7baefaff.1742770151.git.lucc@posteo.de>
Message-ID: <44d1e3fbff586e4c52cc475fd57c9895fc854e8c.1742770151.git.lucc@posteo.de>


* setup.py.in, pyproject.toml: Move long description from setup.py.in to
pyproject.toml file and add a content-type specification
--

This fixes a warning about the missing content-type key raised by
`python -m twine check --strict`.

Signed-off-by: Lucas Hoffmann <lucc at posteo.de>
---
 pyproject.toml | 31 ++++++++++++++++++++++++++++---
 setup.py.in    | 23 -----------------------
 2 files changed, 28 insertions(+), 26 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-build-Move-long-description-to-pyproject.toml.patch
Type: text/x-patch
Size: 3554 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250323/001846f5/attachment-0001.bin>

From wk at gnupg.org  Tue Mar 25 10:22:46 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Mar 2025 10:22:46 +0100
Subject: GnuPG dropped support of smart card version 1.0?
In-Reply-To: <153a0f74-2eb5-4495-8e70-ed7064075f16@free.fr> (Ludovic Rousseau
 via Gnupg-devel's message of "Fri, 27 Dec 2024 17:07:40 +0100")
References: <1a6dceea-2e6e-4045-a2f4-1c4e04c39b44@free.fr>
 <87h66pxhxx.fsf@jacob.g10code.de>
 <153a0f74-2eb5-4495-8e70-ed7064075f16@free.fr>
Message-ID: <8734f1a2hl.fsf@jacob.g10code.de>

Hi!

I found a 1.0 card and I also had a copy of the old test key:  the card
is displayed fine using gpg-card:

Reader ...........: 04E6:E003:51271922204260:0
Serial number ....: D27600012401010000010000000C0000
Application type .: OpenPGP
Version ..........: 1.0
Displayed s/n ....: 0001 0000000C
Manufacturer .....: PPC Card Systems (1)
Name of cardholder: [not set]
Language prefs ...: de
Salutation .......: 
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Max. PIN lengths .: 254 254 254
PIN retry counter : 3 2 3

I used an SPR332 reader and that card is actually one of the very first
cards ever produced.  No problem here using GnuPG 2.5.5 - well except
that I forgot the decryption PIN and better don't do any more tests.
Running on Linux using the the internal driver.  But that should not
matter.

The log showed:

scdaemon[24460]: Version-2+ .....: no
scdaemon[24460]: Version-3+ .....: no
scdaemon[24460]: Button .........: no
scdaemon[24460]: SM-Support .....: no
scdaemon[24460]: Get-Challenge ..: yes (0 bytes max)
scdaemon[24460]: Key-Import .....: yes
scdaemon[24460]: Change-Force-PW1: yes
scdaemon[24460]: Private-DOs ....: no
scdaemon[24460]: Algo-Attr-Change: no
scdaemon[24460]: Symmetric Crypto: no
scdaemon[24460]: KDF-Support ....: no
scdaemon[24460]: Max-Cert-Len ...: 0
scdaemon[24460]: Cmd-Chaining ...: no
scdaemon[24460]: Ext-Lc-Le ......: no
scdaemon[24460]: Status-Indicator: 00
scdaemon[24460]: GnuPG-No-Sync ..: no
scdaemon[24460]: GnuPG-Def-PW2 ..: no
scdaemon[24460]: Key-Attr-sign ..: RSA, n=1024, e=32, fmt=std
scdaemon[24460]: Key-Algo-sign ..: rsa1024
scdaemon[24460]: Key-Attr-encr ..: RSA, n=1024, e=32, fmt=std
scdaemon[24460]: Key-Algo-encr ..: rsa1024
scdaemon[24460]: Key-Attr-auth ..: RSA, n=1024, e=32, fmt=std
scdaemon[24460]: Key-Algo-auth ..: rsa1024

> One difference is that GnuPG 1.x uses:
> APDU: 00 CA 00 6E 00

Will also be read by current gnupg but I did not looked closer at the
APDUs.

> While GnuPG 2.x uses:
> APDU: 00 CA 7F 74 00

That is the feature flag for the confirmation button.  

> Maybe the easiest thing to do is to document that cards version 1.0
> are no more supported and report an understandable error message from
> GnuPG 2.x.

There might have been a regression.  I remember
https://dev.gnupg.org/T7058 with fixes released in July with 2.5.0 and
in October with 2.4.6

This my conclusion is th at 1.0 cards still work.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250325/7f4ca921/attachment.sig>

From kloecker at kde.org  Fri Mar 28 14:10:59 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Fri, 28 Mar 2025 14:10:59 +0100
Subject: [PATCH gnupgpy 0/5] Modernize python build for gpgmepy
In-Reply-To: <174277003465.373069.17602536947672357293@yoga>
References: <174277003465.373069.17602536947672357293@yoga>
Message-ID: <2693870.fDdHjke4Dd@daneel>

On Sonntag, 23. M?rz 2025 23:47:14 Mitteleurop?ische Normalzeit Lucas Hoffmann 
via Gnupg-devel wrote:
> These patches modernize the build process for the gpgmepy repository.
> This was suggested in message 2807036.QOukoFCf94 at daneel
> (https://lists.gnupg.org/pipermail/gnupg-devel/2025-March/035822.html).

Thanks! I have applied the first 4 patches. I haven't applied the fifth patch 
with changes of the m4 files because we want to keep those files as close as 
possible to the upstream versions (python.m4 from automake package and 
ax_python_devel.m4 from the GNU Autoconf Archive). Sorry!

> Some notes about the individual patches:
> 
> - I tried to move as much metadata from the setup.py(.in) file to the
>   pyproject.toml file because it is static in two senses:  It is not
>   touched by configure and friends and it can be parsed without
>   executing it.  I consider both of these advantages for project
>   metadata.

Agreed.

> - I specified the minimum python version as 3.6.  From the message of
>   1a7b204dedaf99efa08915ee561523997175380c it seems that 3.6 was kept
>   because it is supported by some Linux distros.  Otherwise a good list
>   of versions to support would be the versions supported upstream:
>   https://devguide.python.org/versions/ Is there some spelled out policy
>   which python versions should be supported?  Should the project have
>   one?

I don't think we have written down a policy for this. Maybe we should write it 
down somewhere. I think we want to support the versions that are supported 
upstream. Additionally, we may support versions that are shipped with some 
important LTS distros (RHEL? SLES?) in a best-effort manner, i.e. we won't 
actively remove those versions from the list of versions the configure script 
looks for.

> - I do not know the m4 macro language and just made the commit "Remove
>   distutils related code from configure macros" based on my knowledge of
>   shell and python.  I tested the change by running configure on my
>   machine.

Sorry for the work you put into this.

> I tried to search for related issues and patches on the bug tracker but
> only found https://dev.gnupg.org/D545 which seems to be partially
> applied by a7cfdab46f853397794575307a817982cdd06880.  Did I miss any
> important issues or patches that could be incorporated into this series?

I'm not aware of any.

> I tested my changes on my machine by running `make distclean &&
> ./configure --enable-maintainer-mode && make check`.  All but one tests
> pass; the test t-verify.py is reported twice as failure.  This is the
> same on master and with these patches.  Is there some kind of CI or
> defined testing environment (docker container, VM, etc) that I can use?

`make distcheck` usually works well.

> Is this test known to fail or is this a problem with my setup (I am on
> nixos if it matters)?

Here `make distcheck` passed with Python 3.11, 3.12, 3.13 and against master 
builds of libgpg-error and gpgme.

Thanks again for your contribution! I guess next I should look into merging 
the not yet applied changes from https://dev.gnupg.org/D545 . Or do you want 
to look into this? I would appreciate it.

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250328/53af5ff9/attachment.sig>

From fg.gnupg at shimps.de  Fri Mar 28 14:13:24 2025
From: fg.gnupg at shimps.de (Frank Guthausen)
Date: Fri, 28 Mar 2025 14:13:24 +0100
Subject: Compiling with Sqlite3
Message-ID: <20250328141324.7c638dfc@incubator.example.net>

Hello.

I try to compile GnuPG 2.5.5 with self compiled libraries from the
download webpage and support from Debian/Devuan stable libraries for
bzip2, gnutls and sqlite3. Without sqlite3 it works, even with the
environment variables for gnutls support:

LIBGNUTLS_CFLAGS="-I /usr/include/gnutls" LIBGNUTLS_LIBS="-L /usr/lib/x86_64-linux-gnu -l gnutls" ./configure --prefix=/tmp/canary/install


Using the environment variables to compile with sqlite3 support, the
linker doesn't find several symbols. The configure command is in an
attached file and the essential part of the `make' log is attached, too.


The command line variables as prefix relative to the line above are:

SQLITE3_CFLAGS="-I /usr/include" SQLITE3_LIBS="-L /usr/lib/x86_64-linux-gnu -l sqlite3"


The undefined references are (absolute path prefix stripped):

g10/gpg.c:3974: undefined reference to `assuan_control'
g10/pkglue.c:603: undefined reference to `gcry_kem_encap'
/usr/bin/ld: g10/pkglue.c:659: undefined reference to `gcry_kem_encap'
common/asshelp.c:542: undefined reference to `gpgrt_process_spawn'
common/kem.c:141: undefined reference to `gcry_md_hash_buffers_ext'

This should be rather trivial to solve but I don't see what I am
missing. Something with the order of libraries? Can you give me a
hint what needs to be checked?
-- 
kind regards
Frank
-------------- next part --------------
SQLITE3_CFLAGS="-I /usr/include" SQLITE3_LIBS="-L /usr/lib/x86_64-linux-gnu -l sqlite3" LIBGNUTLS_CFLAGS="-I /usr/include/gnutls" LIBGNUTLS_LIBS="-L /usr/lib/x86_64-linux-gnu -l gnutls" ./configure --prefix=/tmp/canary/install --disable-photo-viewers --disable-rpath
-------------- next part --------------
Making all in g10
make[2]: Entering directory '/tmp/canary/compile/gnupg-2.5.5/g10'
gcc -I /usr/include -I/tmp/canary/install/include -I/tmp/canary/install/include -I/tmp/canary/install/include -I/tmp/canary/install/include -Wall -Wno-format-zero-length -Wno-pointer-sign -Wpointer-arith -g -O2   -o gpg gpg.o keyedit.o server.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o expand-group.o call-keyboxd.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o rmd160.o openfile.o keyid.o parse-packet.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o objcache.o ecdh.o pkclist.o skclist.o pubkey-enc.o passphrase.o decrypt.o decrypt-data.o cipher-cfb.o cipher-aead.o encrypt.o sign.o verify.o revoke.o dearmor.o import.o export.o migrate.o delkey.o keygen.o helptext.o keyserver.o call-dirmngr.o photoid.o call-agent.o trust.o trustdb.o tdbdump.o tdbio.o tofu.o gpgsql.o card-util.o exec.o key-clean.o key-check.o ../kbx/libkeybox.a ../common/libcommonpth.a ../regexp/libregexp.a ../common/libgpgrl.a -lz -lbz2   -L /usr/lib/x86_64-linux-gnu -l sqlite3 -L/tmp/canary/install/lib -lgcrypt  -L/tmp/canary/install/lib -lassuan -L/tmp/canary/install/lib -lnpth -L/tmp/canary/install/lib -lgpg-error    
/usr/bin/ld: gpg.o: in function `main':
/tmp/canary/compile/gnupg-2.5.5/g10/gpg.c:3974: undefined reference to `assuan_control'
/usr/bin/ld: pkglue.o: in function `do_encrypt_kem':
/tmp/canary/compile/gnupg-2.5.5/g10/pkglue.c:603: undefined reference to `gcry_kem_encap'
/usr/bin/ld: /tmp/canary/compile/gnupg-2.5.5/g10/pkglue.c:659: undefined reference to `gcry_kem_encap'
/usr/bin/ld: ../common/libcommonpth.a(libcommonpth_a-asshelp.o): in function `start_new_service':
/tmp/canary/compile/gnupg-2.5.5/common/asshelp.c:542: undefined reference to `gpgrt_process_spawn'
/usr/bin/ld: ../common/libcommonpth.a(libcommonpth_a-kem.o): in function `compute_kmac256':
/tmp/canary/compile/gnupg-2.5.5/common/kem.c:141: undefined reference to `gcry_md_hash_buffers_ext'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:865: gpg] Error 1
make[2]: Leaving directory '/tmp/canary/compile/gnupg-2.5.5/g10'
make[1]: *** [Makefile:631: all-recursive] Error 1
make[1]: Leaving directory '/tmp/canary/compile/gnupg-2.5.5'
make: *** [Makefile:551: all] Error 2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250328/53810e8c/attachment.sig>

From jcb62281 at gmail.com  Sat Mar 29 00:43:38 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Fri, 28 Mar 2025 18:43:38 -0500
Subject: Compiling with Sqlite3
In-Reply-To: <20250328141324.7c638dfc@incubator.example.net>
References: <20250328141324.7c638dfc@incubator.example.net>
Message-ID: <d98ee42d-759d-478c-b2d4-b18742b7e8e4@gmail.com>

On 3/28/25 08:13, Frank Guthausen wrote:
> [...]
>
> The command line variables as prefix relative to the line above are:
>
> SQLITE3_CFLAGS="-I /usr/include" SQLITE3_LIBS="-L /usr/lib/x86_64-linux-gnu -l sqlite3"

Usually those options do not have spaces in my experience; could you try:

SQLITE3_CFLAGS="-I/usr/include" SQLITE3_LIBS="-L/usr/lib/x86_64-linux-gnu -lsqlite3"

...and similarly "close up" the spaces for the GnuTLS options.? I am 
unsure how, but this *might* be somehow confusing ld?

(In particular, was it actually linking GnuTLS or was configure 
rejecting that library after failing to link a test program?)


-- Jacob



From ametzler at bebt.de  Sat Mar 29 07:06:43 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 29 Mar 2025 07:06:43 +0100
Subject: Compiling with Sqlite3
In-Reply-To: <20250328141324.7c638dfc@incubator.example.net>
References: <20250328141324.7c638dfc@incubator.example.net>
Message-ID: <Z-eN82p719mqOyrO@argenau.bebt.de>

On 2025-03-28 Frank Guthausen <fg.gnupg at shimps.de> wrote:
> I try to compile GnuPG 2.5.5 with self compiled libraries from the
> download webpage and support from Debian/Devuan stable libraries for
> bzip2, gnutls and sqlite3. Without sqlite3 it works, even with the
> environment variables for gnutls support:

> LIBGNUTLS_CFLAGS="-I /usr/include/gnutls" LIBGNUTLS_LIBS="-L /usr/lib/x86_64-linux-gnu -l gnutls" ./configure --prefix=/tmp/canary/install

> Using the environment variables to compile with sqlite3 support, the
> linker doesn't find several symbols. The configure command is in an
> attached file and the essential part of the `make' log is attached, too.

> The command line variables as prefix relative to the line above are:

> SQLITE3_CFLAGS="-I /usr/include" SQLITE3_LIBS="-L /usr/lib/x86_64-linux-gnu -l sqlite3"
[...]

Why do you set these options at all? ./configure should find the libs in
their standard location without these hints. Did you perhaps forget to
install pkgconf?

cu Andreas


From fg.gnupg at shimps.de  Sat Mar 29 10:52:02 2025
From: fg.gnupg at shimps.de (Frank Guthausen)
Date: Sat, 29 Mar 2025 10:52:02 +0100
Subject: Compiling with Sqlite3
In-Reply-To: <Z-eN82p719mqOyrO@argenau.bebt.de>
References: <20250328141324.7c638dfc@incubator.example.net>
 <Z-eN82p719mqOyrO@argenau.bebt.de>
Message-ID: <20250329105202.43321a9b@incubator.example.net>

On Sat, 29 Mar 2025 07:06:43 +0100
Andreas Metzler <ametzler at bebt.de> wrote:
> On 2025-03-28 Frank Guthausen <fg.gnupg at shimps.de> wrote:
> > 
> > SQLITE3_CFLAGS="-I /usr/include" SQLITE3_LIBS="-L
> > /usr/lib/x86_64-linux-gnu -l sqlite3"  
> [...]
> 
> Why do you set these options at all?

I took this idea from:

$ ./configure --help

> ./configure should find the libs
> in their standard location without these hints. Did you perhaps
> forget to install pkgconf?

Indeed, I forgot. Thanks for pointing me to this direction.
With this package installed, it compiles straightforward with
usage of gnutls and sqlite3.
-- 
kind regards
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250329/81f5f837/attachment-0001.sig>

From fg.gnupg at shimps.de  Sat Mar 29 11:04:47 2025
From: fg.gnupg at shimps.de (Frank Guthausen)
Date: Sat, 29 Mar 2025 11:04:47 +0100
Subject: Compiling with Sqlite3
In-Reply-To: <d98ee42d-759d-478c-b2d4-b18742b7e8e4@gmail.com>
References: <20250328141324.7c638dfc@incubator.example.net>
 <d98ee42d-759d-478c-b2d4-b18742b7e8e4@gmail.com>
Message-ID: <20250329110418.3ffa63e0@incubator.example.net>

TL;DR

The issue was solved by installing the missing package `pkgconf'.

On Fri, 28 Mar 2025 18:43:38 -0500
Jacob Bachmeyer via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> On 3/28/25 08:13, Frank Guthausen wrote:
> > [...]
> >
> > The command line variables as prefix relative to the line above are:
> >
> > SQLITE3_CFLAGS="-I /usr/include" SQLITE3_LIBS="-L
> > /usr/lib/x86_64-linux-gnu -l sqlite3"  
> 
> Usually those options do not have spaces in my experience; could you
> try:
> 
> SQLITE3_CFLAGS="-I/usr/include"
> SQLITE3_LIBS="-L/usr/lib/x86_64-linux-gnu -lsqlite3"

No difference.

> ...and similarly "close up" the spaces for the GnuTLS options.? I am 
> unsure how, but this *might* be somehow confusing ld?

I checked this again, but I never noticed a difference before.
Sometimes it is easier to read with the space added, because
the options `-I' and `-l' can be confused depending on the font.

> (In particular, was it actually linking GnuTLS or was configure 
> rejecting that library after failing to link a test program?)

GnuTLS without Sqlite3 compiled and linked fine. The binary gpg was
created as expected, and dirmngr was created with gnutls usage as ldd
indicated.

Sqlite3 didn't link the gpg binary with or without GnuTLS.

Meanwhile...
With the installed package pkgconf neither of those
settings is required to create the output with both
active.
-- 
kind regards
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250329/6369da1a/attachment.sig>

From wk at gnupg.org  Mon Mar 31 09:29:40 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 31 Mar 2025 09:29:40 +0200
Subject: Compiling with Sqlite3
In-Reply-To: <Z-eN82p719mqOyrO@argenau.bebt.de> (Andreas Metzler's message of
 "Sat, 29 Mar 2025 07:06:43 +0100")
References: <20250328141324.7c638dfc@incubator.example.net>
 <Z-eN82p719mqOyrO@argenau.bebt.de>
Message-ID: <87wmc5psij.fsf@jacob.g10code.de>

Hi!

Short reminder on how to pass envars to configure:

  ./configure FOO=bla BAR="-l abc"

Is the correct way to pass FOO abd BAR.  This allows configure to record
the values of the envvars.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250331/4efdaa74/attachment.sig>

From fg.gnupg at shimps.de  Mon Mar 31 15:56:37 2025
From: fg.gnupg at shimps.de (Frank Guthausen)
Date: Mon, 31 Mar 2025 15:56:37 +0200
Subject: Compiling with Sqlite3
In-Reply-To: <87wmc5psij.fsf@jacob.g10code.de>
References: <20250328141324.7c638dfc@incubator.example.net>
 <Z-eN82p719mqOyrO@argenau.bebt.de>
 <87wmc5psij.fsf@jacob.g10code.de>
Message-ID: <20250331155637.318fea14@incubator.example.net>

On Mon, 31 Mar 2025 09:29:40 +0200
Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> 
> Short reminder on how to pass envars to configure:
> 
>   ./configure FOO=bla BAR="-l abc"
> 
> Is the correct way to pass FOO abd BAR.  This allows configure to
> record the values of the envvars.

This is good to know. However, even this syntax requires the package
pkgconf to be installed. Compilation without it leads to the same error
as mentioned before.

I'll summarize the insights with a script to provide
the packages required to set the environment up which
is used to compile (to be eventually published in the
do it yourself repository diy-gnupg at Codeberg).
-- 
kind regards
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250331/a08aa44d/attachment.sig>