From gniibe at fsij.org  Tue Dec  7 08:22:16 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 07 Dec 2021 16:22:16 +0900
Subject: [PATCH] configure.ac: do not hardcode gnu libc when generating
 lock-obj
In-Reply-To: <20211203110428.1102226-1-alex@linutronix.de>
References: <20211203110428.1102226-1-alex@linutronix.de>
Message-ID: <87mtlcdglz.fsf@akagi.fsij.org>

Hello,

Alexander Kanavin <alex at linutronix.de> wrote:
> This erroneously excluded e.g. musl libc.

Sorry, I don't think so.  Let me explain my viewpoint.

When writing this part, my intention was to identify GNU/Linux system.
(*-*-linux-gnu* is used to identify: GNU Operating System, which uses
Linux kernel.)

>From viewpoint of using GNU tools, it is unfortunate for systems having
different semantics for GNU triplet.


Well, anyhow, that's the reality, I know.

Could you please describe names of system which supports same ABI as GNU
system?

Then, let us add those (not changing existing case).
-- 


From gniibe at fsij.org  Mon Dec 13 06:27:04 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 13 Dec 2021 14:27:04 +0900
Subject: [PATCH] configure.ac: do  not hardcode gnu libc when generating
 lock-obj
In-Reply-To: <490-61af3180-11-14797900@141352260>
References: <490-61af3180-11-14797900@141352260>
Message-ID: <87pmq19is7.fsf@akagi.fsij.org>

"Alexander Kanavin" <alex at linutronix.de> wrote:
> The case which we (the Yocto project) would like to support is building for systems
> with Linux kernel and musl C library.

Thank you.

Applied in: e17cf023d894acc3932505f66fbd9c31ce56793f
-- 


From rjh at sixdemonbag.org  Thu Dec 16 21:25:33 2021
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 16 Dec 2021 15:25:33 -0500
Subject: GPGME 1.16 build error
Message-ID: <6a94cec3-22ba-506a-fdc3-9337fc096ac3@sixdemonbag.org>

make[1]: Entering directory '/home/rjh/Downloads/gpgme-1.16.0/src'
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../conf    -I/usr/local/include -I/usr/local/include  -g -O2 -Wall 
-Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k 
-Wno-missing-field-initializers -Wno-sign-compare 
-Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div 
-MT posix-io.lo -MD -MP -MF .deps/posix-io.Tpo -c -o posix-io.lo posix-io.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../conf 
-I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wcast-align 
-Wshadow -Wstrict-prototypes -Wno-format-y2k 
-Wno-missing-field-initializers -Wno-sign-compare 
-Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div 
-MT posix-io.lo -MD -MP -MF .deps/posix-io.Tpo -c posix-io.c  -fPIC 
-DPIC -o .libs/posix-io.o
posix-io.c: In function '_gpgme_io_spawn':
posix-io.c:577:23: error: void value not ignored as it ought to be
   577 |             while ((i = closefrom (fd)) && errno == EINTR)
       |                       ^

System is Pop!_OS 21.10 x64, with GCC 11.2.0.


From kloecker at kde.org  Fri Dec 17 12:22:10 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Fri, 17 Dec 2021 12:22:10 +0100
Subject: GPGME 1.16 build error
In-Reply-To: <6a94cec3-22ba-506a-fdc3-9337fc096ac3@sixdemonbag.org>
References: <6a94cec3-22ba-506a-fdc3-9337fc096ac3@sixdemonbag.org>
Message-ID: <2375341.EFjhcG1iGf@daneel>

On Donnerstag, 16. Dezember 2021 21:25:33 CET Robert J. Hansen via Gnupg-devel 
wrote:
> posix-io.c: In function '_gpgme_io_spawn':
> posix-io.c:577:23: error: void value not ignored as it ought to be
>    577 |             while ((i = closefrom (fd)) && errno == EINTR)
> 
>        |                       ^
> 
> System is Pop!_OS 21.10 x64, with GCC 11.2.0.

This was fixed with 
https://dev.gnupg.org/rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e

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/20211217/e074542d/attachment.sig>

From wk at gnupg.org  Fri Dec 17 14:04:24 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 17 Dec 2021 14:04:24 +0100
Subject: GPGME 1.16 build error
In-Reply-To: <6a94cec3-22ba-506a-fdc3-9337fc096ac3@sixdemonbag.org> (Robert
 J. Hansen via Gnupg-devel's message of "Thu, 16 Dec 2021 15:25:33
 -0500")
References: <6a94cec3-22ba-506a-fdc3-9337fc096ac3@sixdemonbag.org>
Message-ID: <87tuf7v0vb.fsf@wheatstone.g10code.de>

On Thu, 16 Dec 2021 15:25, Robert J. Hansen said:

> posix-io.c:577:23: error: void value not ignored as it ought to be
>   577 |             while ((i = closefrom (fd)) && errno == EINTR)
>       |                       ^

--8<---------------cut here---------------start------------->8---
commit 4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e
Author:     Jiri Kucera <sanczes at gmail.com>
AuthorDate: Sun Jul 25 11:35:54 2021 +0200

    core: Support closefrom also for glibc.
    
    * src/posix-io.c (_gpgme_io_spawn): Use glibc's closefrom.
    --
    
    Since 2.34, glibc introduces closefrom (the implementation
    follows *BSD standard).


diff --git a/src/posix-io.c b/src/posix-io.c
index e712ef28..2a3a81fc 100644
--- a/src/posix-io.c
+++ b/src/posix-io.c
@@ -570,7 +570,7 @@ _gpgme_io_spawn (const char *path, char *const argv[], unsigned int flags,
               if (fd_list[i].fd > fd)
                 fd = fd_list[i].fd;
             fd++;
-#if defined(__sun) || defined(__FreeBSD__)
+#if defined(__sun) || defined(__FreeBSD__) || defined(__GLIBC__)
             closefrom (fd);
             max_fds = fd;
 #else /*!__sun */
--8<---------------cut here---------------end--------------->8---

Yes, we should do a new release.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20211217/c80f7f24/attachment.sig>

From wk at gnupg.org  Mon Dec 20 23:26:35 2021
From: wk at gnupg.org (Werner Koch)
Date: Mon, 20 Dec 2021 23:26:35 +0100
Subject: [Announce] GnuPG 2.3.4 released
Message-ID: <87y24eq5es.fsf@wheatstone.g10code.de>

Hello!

24 years after the first public release we are pleased to announce the
availability of a new GnuPG release: version 2.3.4.  This is the fifth
release in the new 2.3 series which introduces a few new options and and
fixes some bugs.  See below for details.


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.

Three different series of GnuPG are actively maintained:

- Version 2.3 is the current stable version with a lot of new features
  compared to 2.2.  This announcement is about the latest release of
  this series.

- Version 2.2 is our LTS (long term support) version and guaranteed to
  be maintained at least until the end of 2024.
  See https://gnupg.org/download/index.html#end-of-life

- Version 1.4 is only maintained to allow decryption of very old data
  which is, for security reasons, not anymore possible with other GnuPG
  versions.


Noteworthy changes in version 2.3.4 (2021-12-20)
================================================

  * gpg: New option --min-rsa-length.  [rG5f39db70c0]

  * gpg: New option --forbid-gen-key.  [rGc397ba3ac0]

  * gpg: New option --override-compliance-check.  [T5655]

  * gpgconf: New command --show-configs.  [rGa0fb78ee0f]

  * agent,dirmngr,keyboxd: New option --steal-socket.
    [rGb0079ab39d,rGdd708f60d5]

  * gpg: Fix printing of binary notations.  [T5667]

  * gpg: Remove stale ultimately trusted keys from the trustdb.
    [T5685,T5742]

  * gpg: Fix indentation of --print-mds and --print-md sha512.  [T5679]

  * gpg: Emit gpg 2.2 compatible Ed25519 signature.  [T5331]

  * gpgsm: Detect circular chains in --list-chain.  [rG74c5b35062]

  * dirmngr: Make reading resolv.conf more robust.  [T5657]

  * dirmngr: Ask keyservers to provide the key fingerprints.  [T5741]

  * gpgconf: Allow changing gpg's deprecated keyserver option.  [T5462]

  * gpg-wks-server: Fix created file permissions.  [rG60be00b033]

  * scd: Support longer data for ssh-agent authentication with openpgp
    cards.  [T5682]

  * scd: Modify DEVINFO behavior to support looping forever.  [T5359]

  * Support gpgconf.ctl for NetBSD and Solaris.  [T5656,T5671]

  * Silence "Garbled console data" warning under Windows in most
    cases.  [rGe293da3b21]

  * Silence warning about the rootdir under Unices w/o a mounted /proc
    file system.  [T5656]

  * Fix possible build problems about missing include files.  [T5592]

  Release-info: https://dev.gnupg.org/T5654
  

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 FTP 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.3.4.tar.bz2 (7411k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.4.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.3.4_20211220.exe (4708k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.4_20211220.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.


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.3.4.tar.bz2 you would use this command:

     gpg --verify gnupg-2.3.4.tar.bz2.sig gnupg-2.3.4.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.3.4.tar.bz2, you run the command like this:

     sha1sum gnupg-2.3.4.tar.bz2

   and check that the output matches the next line:

436823f57b8387ece6053d9a395374243d64feff  gnupg-2.3.4.tar.bz2
c1443f71a2be02a4ab30027e2ec6336dd08fdc26  gnupg-w32-2.3.4_20211220.tar.xz
2af6d08717f5367f1e8c7306bd10f8a20ef9ebdc  gnupg-w32-2.3.4_20211220.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, 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/T5654 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.  Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.

Fortunately, and this is still not common with free software, we have
now established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademark
GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helping with donations.

*Thank you all*

   Your GnuPG hackers


p.s
Those of you with standing SEPA donations, please cancel them or
consider to redirect your funds to other projects which are more in
need of financial support.  The donations done via Stripe or PayPal
have already been canceled.

p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.

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

-- 
Please read

  Nils Melzer: Der Fall Julian Assange

It is really important to know the background of the Assange case to
understand the massive perils to free journalism.  The book is right
now only available in German: https://dev.gnupg.org/u/melzerassang
-------------- 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/20211220/8861f7b8/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From eric at bktus.com  Tue Dec 21 18:12:20 2021
From: eric at bktus.com (eric at bktus.com)
Date: 22 Dec 2021 01:12:20 +0800
Subject: Some problems between GnuPG and smart card
Message-ID: <20211221171220.98EFA5EEA05@bktus.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello everyone, this is my first time using the mailing list. If there is anything wrong, please point it out, thank you.

Now, I am here to raise a question.

Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I have used almost all mainstream systems to communicate between my smart card and GnuPG, and found that some settings need to be added to the scdaemon configuration, or some other related libraries need to be installed.

For some ordinary users who use smart cards, these unintuitive settings, or problems related to them, may undermine their confidence in continuing to use them. I found that there are many such solutions on the Internet, the problem I encountered has also been encountered by many others. Is there any way that scdaemon can automatically recognize these situations and add appropriate settings.  Or is there any mechanism that allows ordinary users to avoid these problems that they don't understand? I plug in the smart card and can edit card or move to card without doing any other operations.

The above work I have done is mainly to show the writing operation intuitively to users through a graphical interface in the future, instead of letting them use the command line. However, these additional settings make me have to think that even if I make a suitable graphical interface, it may not work properly due to some setting problems that I don't know about. I had to temporarily suspend my plan and then turn to you for help.
-----BEGIN PGP SIGNATURE-----

iQG1BAEWCAAdFiEECqFvrCYH4uLX2KtFxbhvNgGeUqcFAmHCClQACgkQxbhvNgGe
UqfriQX+IWD0SvlZbXZZp4y2Z+gKQMgNAtYQ3RUcmclNR48mMjAf6T45BXNnZnyY
szWbX21PV+Y9qZpZMfUwz81IGW/ijlez+J9i5Br4Qp1cJdG2uTS9UBUPt56Jb+jf
V70TBEboXZVw4fb8GdjMXpO1XE9aQogZsjEzkGP5JreGem9BunIoebQobrZSzGEn
q7yE53cYPln8W6usHmbsgjMd4j+PPJ/bNtukR9+JbNQHRA23J/mVB0tEfgfth7JE
JBZjtOsABgCrof28ecBJv/Ln4ypK6YoNP2DPDqv3jBT3OLAxg5azM/2L1KTB8OYB
ogpFjSFri/Bn9NBIDoc+YXuppKtGJZvaz2ppK4QEicQPVRkwiC3ZOhcOrYSl26ce
SUu2ojIYnKfezqFDeT0y2lGvf4e+eKMnXPCp/Iz1FyLWyPEONX2HExWfcuHJTpGG
UFDF5u1sxxI72/iNoHj9s3hj/rHh/9wPcPUwTcT2Q/8Rd9XQzP28+cR2G8AGqLMV
1WgJcIhoLo0=
=AhhN
-----END PGP SIGNATURE-----

From eric at bktus.com  Tue Dec 21 19:03:14 2021
From: eric at bktus.com (Saturneric)
Date: Wed, 22 Dec 2021 02:03:14 +0800
Subject: [PATCH gnupg] doc: Fix an error in the data type gpgme_tofu_info_t
In-Reply-To: <20211221175630.40431-1-eric@bktus.com>
References: <20211221175630.40431-1-eric@bktus.com>
Message-ID: <fd41ce81-c400-ae0f-57e6-67af55784a86@bktus.com>

This Patch is wrong, the title should be "Patch gpgme". I'm very sorry, 
everyone doesn't care about this Patch.

? 2021/12/22 ??1:56, Saturneric ??:
> --
> ---
>   doc/gpgme.texi | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/gpgme.texi b/doc/gpgme.texi
> index cc8ff5e5..02f985a1 100644
> --- a/doc/gpgme.texi
> +++ b/doc/gpgme.texi
> @@ -3662,7 +3662,7 @@ database pertaining to the user ID.
>   The tofu info structure has the following members:
>   
>   @table @code
> - at item gpgme_key_sig_t next
> + at item gpgme_tofu_info_t next
>   This is a pointer to the next tofu info structure in the linked
>   list, or @code{NULL} if this is the last element.
>   



From eric at bktus.com  Tue Dec 21 17:32:22 2021
From: eric at bktus.com (eric at bktus.com)
Date: Wed, 22 Dec 2021 00:32:22 +0800
Subject: Making contributions to the GPGME project
Message-ID: <007b01d7f688$54e8d850$feba88f0$@bktus.com>

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

 

GPGME Developer's Certificate of Origin.  Version 1.0

=====================================================

 

By making a contribution to the GPGME 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: Saturneric <eric at bktus.com <mailto:eric at bktus.com> >

-----BEGIN PGP SIGNATURE-----

 

iQIzBAEBCAAdFiEExEoeTMpVzDyCCrnkOlA5Ga/6SF8FAmHB/xcACgkQOlA5Ga/6

SF/FaRAAmNsBMG4hECj02NCeXkOF4XA9U5/D+22N85oaYeRKQNfSNGBGwnxHBakC

l9duWGT44hu+QL+rIN9EhCs6LD2JshmvrWtJnprcQLF103jD4M5p+bhW15c8oJBy

KkQ3pzg3nlFU9Uylp1Jo2jBsT0PhS2OCnSQTcJbIVaQr4onuajdbfjFOdNKYHJ5I

hMFY9TeKCpJgkyzZgERTH7W9407pVx/+GJtzKK8wzhpeUjO0yHJHqL/ixQwbQ2LO

IdI6u1uRGIIBAWbbRfa2oaMpef3Tz1XMIjLQEQPqxaBqUBpZEwnf8HEHscY570L1

84sh23MVUKmjzfgzcFeB4Mw2OknaZbt7pUhjF7gufAbaf3ZaWoQzGvk3NN+jcOs0

VnVbGEYFnyQrgsS3wQZSOmIvKxAyXz/iSxekUaWtDXNA+G4s0vtG2lEQViiw45Dw

vnR9chS5DkSCxDPsR2+tmaHNbFw3qcEaI0ydSXSZ+dP8iYMouPGODcwLbxgv29ZJ

DKRwtb2PGwq3FPKGue8eTIhc7Iu+KzJilxQPs/6L2BNcvd4qU2VQuDkJPs4lLKwK

I9nI78RTUQKCDs7R32P+LmfwJz4mEqJ34SWTWUHBhh4WWITtmuxLaLnsJEXTZeXp

dDQvhbkcgzaWYGeUJ2GEg0cfEN5P8LnvS6lfoxd3y6IeZFcPSM4=

=HZ+h

-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211222/374d3f33/attachment.html>

From eric at bktus.com  Tue Dec 21 18:14:12 2021
From: eric at bktus.com (saturneric)
Date: Wed, 22 Dec 2021 01:14:12 +0800
Subject: Some problems between GnuPG and smart card
Message-ID: <ed146cec-da67-55bd-ba16-57d6b06c6b13@bktus.com>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, this is my first time using the mailing list. If there is anything wrong, please point it out, thank you. Now, I am here to raise a question. Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I have used almost all mainstream systems to communicate between my smart card and GnuPG, and found that some settings need to be added to the scdaemon configuration, or some other related libraries need to be installed. For some ordinary users who use smart cards, these unintuitive settings, or problems related to them, may undermine their confidence in continuing to use them. I found that there are many such solutions on the Internet, the problem I encountered has also been encountered by many others. Is there any way that scdaemon can automatically recognize these situati

ons and add appropriate settings. Or is there any mechanism that allows ordinary users to avoid these problems that they don't understand? I plug in the smart card and can edit card or move to card without doing any other operations. The above work I have done is mainly to show the writing operation intuitively to users through a graphical interface in the future, instead of letting them use the command line. However, these additional settings make me have to think that even if I make a suitable graphical interface, it may not work properly due to some setting problems that I don't know about. I had to temporarily suspend my plan and then turn to you for help. -----BEGIN PGP SIGNATURE----- iQG1BAEWCAAdFiEECqFvrCYH4uLX2KtFxbhvNgGeUqcFAmHCClQACgkQxbhvNgGe UqfriQX+IWD0SvlZbXZZp4y2Z+gKQMgNAtYQ3RUcmclNR48mMjAf6T45BXNnZnyY szWbX21PV+Y9qZpZMfUwz81IGW/ijlez+J9i5Br4Qp1cJdG2uTS9UBUPt56Jb+jf V70TBEboXZVw4fb8GdjMXpO1XE9aQogZsjEzkGP5JreGem9BunIoebQobrZSzGEn q7yE53cYPln8W6usHmbsgjMd4j+PPJ/bNtukR9+

JbNQHRA23J/mVB0tEfgfth7JE JBZjtOsABgCrof28ecBJv/Ln4ypK6YoNP2DPDqv3jBT3OLAxg5azM/2L1KTB8OYB ogpFjSFri/Bn9NBIDoc+YXuppKtGJZvaz2ppK4QEicQPVRkwiC3ZOhcOrYSl26ce SUu2ojIYnKfezqFDeT0y2lGvf4e+eKMnXPCp/Iz1FyLWyPEONX2HExWfcuHJTpGG UFDF5u1sxxI72/iNoHj9s3hj/rHh/9wPcPUwTcT2Q/8Rd9XQzP28+cR2G8AGqLMV 1WgJcIhoLo0= =AhhN -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211222/ddbc745d/attachment-0001.html>

From eric at bktus.com  Tue Dec 21 18:56:30 2021
From: eric at bktus.com (Saturneric)
Date: Wed, 22 Dec 2021 01:56:30 +0800
Subject: [PATCH gnupg] doc: Fix an error in the data type gpgme_tofu_info_t
Message-ID: <20211221175630.40431-1-eric@bktus.com>

--
---
 doc/gpgme.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index cc8ff5e5..02f985a1 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -3662,7 +3662,7 @@ database pertaining to the user ID.
 The tofu info structure has the following members:
 
 @table @code
- at item gpgme_key_sig_t next
+ at item gpgme_tofu_info_t next
 This is a pointer to the next tofu info structure in the linked
 list, or @code{NULL} if this is the last element.
 
-- 
2.25.1




From eric at bktus.com  Tue Dec 21 17:22:19 2021
From: eric at bktus.com (eric at bktus.com)
Date: Wed, 22 Dec 2021 00:22:19 +0800
Subject: Making a contribution to the GPGME project
Message-ID: <006b01d7f686$ee1e6960$ca5b3c20$@bktus.com>

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

 

GPGME Developer's Certificate of Origin.  Version 1.0

=====================================================

 

By making a contribution to the GPGME 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: Saturneric <eric at bktus.com>

-----BEGIN PGP SIGNATURE-----

 

iQIzBAEBCAAdFiEExEoeTMpVzDyCCrnkOlA5Ga/6SF8FAmHB/xcACgkQOlA5Ga/6

SF/FaRAAmNsBMG4hECj02NCeXkOF4XA9U5/D+22N85oaYeRKQNfSNGBGwnxHBakC

l9duWGT44hu+QL+rIN9EhCs6LD2JshmvrWtJnprcQLF103jD4M5p+bhW15c8oJBy

KkQ3pzg3nlFU9Uylp1Jo2jBsT0PhS2OCnSQTcJbIVaQr4onuajdbfjFOdNKYHJ5I

hMFY9TeKCpJgkyzZgERTH7W9407pVx/+GJtzKK8wzhpeUjO0yHJHqL/ixQwbQ2LO

IdI6u1uRGIIBAWbbRfa2oaMpef3Tz1XMIjLQEQPqxaBqUBpZEwnf8HEHscY570L1

84sh23MVUKmjzfgzcFeB4Mw2OknaZbt7pUhjF7gufAbaf3ZaWoQzGvk3NN+jcOs0

VnVbGEYFnyQrgsS3wQZSOmIvKxAyXz/iSxekUaWtDXNA+G4s0vtG2lEQViiw45Dw

vnR9chS5DkSCxDPsR2+tmaHNbFw3qcEaI0ydSXSZ+dP8iYMouPGODcwLbxgv29ZJ

DKRwtb2PGwq3FPKGue8eTIhc7Iu+KzJilxQPs/6L2BNcvd4qU2VQuDkJPs4lLKwK

I9nI78RTUQKCDs7R32P+LmfwJz4mEqJ34SWTWUHBhh4WWITtmuxLaLnsJEXTZeXp

dDQvhbkcgzaWYGeUJ2GEg0cfEN5P8LnvS6lfoxd3y6IeZFcPSM4=

=HZ+h

-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211222/61281da9/attachment.html>

From eric at bktus.com  Tue Dec 21 19:00:01 2021
From: eric at bktus.com (Saturneric)
Date: Wed, 22 Dec 2021 02:00:01 +0800
Subject: [PATCH gpgme] doc: Fix an error in the data type gpgme_tofu_info_t
Message-ID: <20211221180001.40828-1-eric@bktus.com>

--
---
 doc/gpgme.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index cc8ff5e5..02f985a1 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -3662,7 +3662,7 @@ database pertaining to the user ID.
 The tofu info structure has the following members:
 
 @table @code
- at item gpgme_key_sig_t next
+ at item gpgme_tofu_info_t next
 This is a pointer to the next tofu info structure in the linked
 list, or @code{NULL} if this is the last element.
 
-- 
2.25.1




From eric at bktus.com  Thu Dec 23 09:48:57 2021
From: eric at bktus.com (Saturneric)
Date: Thu, 23 Dec 2021 16:48:57 +0800
Subject: Question on patch submitted.
Message-ID: <05793579-7cf4-ad7c-b574-8c3b9433a553@bktus.com>

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hello everyone,

I want to know if I submit a patch to this address via git send email, 
when and how the patch will be processed. Can I track the status of this 
patch?

-----BEGIN PGP SIGNATURE-----

iQG1BAEWCAAdFiEECqFvrCYH4uLX2KtFxbhvNgGeUqcFAmHEN6oACgkQxbhvNgGe

UqdjOwX/WU4KObL/6YamJNhf2djKBjcyDLJtUKOh+HHVftneeJPKuSmXLjQsrgMI

lCv93PHioyCAKwcXj2AkX3dMHyDlpzZDqnPAIg46FZGTIbMO6InKzrWmdn6f3rqS

1tIK7sA5t36uPcXYvl6+gfJDQVLyR6tGtqUfOxnyaDu95ZnsfmyNLlzYptGbRpM3

X8zhRjUM3OrXHNpPPG/+mD5nIdNINvahAKARZt0TJvIHmRpJ9VWyQxDIcC4uZ4sk

CQUThXLaBf4rgXiEwBMGlyNKETZ17gf6vp8IYU+EUCgnvddzbZ8utUR0LTLMEIWJ

KMS2SP7ZQgvV9FAxIG9MruoHzvFWjWHg3rZmTF0OTYXD6lnpjehx7TlXByaemkpd

vB+gdOFm+iwgygADnCZFFhiIVMfsCBei1ToIZYrnvn/ebUimZgMiTVEW9XwfKIXv

yXvO5qDCLjTOckRpsYPzNS0xCH1WsEYlOuk/1yyQH8mOfwPYASxqtBmrrjJTp10f

gaEjiCl11uo=

=G7qV

-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211223/7ca857bd/attachment.html>

From code at bnavigator.de  Thu Dec 23 16:33:23 2021
From: code at bnavigator.de (Ben Greiner)
Date: Thu, 23 Dec 2021 16:33:23 +0100
Subject: [PATCH gpgme 1/2] build: Support Python 3.10 version detection
 without distutils
Message-ID: <48167e34-3b78-4d22-dc05-9e57015e5b44@bnavigator.de>

* m4/ax_python_devel.m4: update to serial 23, remove distutils usage

-- 
This version removes the usage of Python distutils where possible.
Python 3.10 deprecated distutils and prints warnings that it will
be removed in Python 3.12

Keep GPGME overrides for finding multiple versions
---
 ?m4/ax_python_devel.m4 | 123 ++++++++++++++++++++++++++++--------------
 ?1 file changed, 84 insertions(+), 39 deletions(-)

diff --git a/m4/ax_python_devel.m4 b/m4/ax_python_devel.m4
index 55f0cfff..f4d20b33 100644
--- a/m4/ax_python_devel.m4
+++ b/m4/ax_python_devel.m4
@@ -1,5 +1,5 @@
 ?# 
===========================================================================
-#https://www.gnu.org/software/autoconf-archive/ax_python_devel.html
+#https://www.gnu.org/software/autoconf-archive/ax_python_devel.html
 ?# 
===========================================================================
 ?#
 ?# SYNOPSIS
@@ -12,8 +12,8 @@
 ?#?? in your configure.ac.
 ?#
 ?#?? This macro checks for Python and tries to get the include path to
-#?? 'Python.h'. It provides the $(PYTHON_CPPFLAGS) and $(PYTHON_LDFLAGS)
-#?? output variables. It also exports $(PYTHON_EXTRA_LIBS) and
+#?? 'Python.h'. It provides the $(PYTHON_CPPFLAGS) and $(PYTHON_LIBS) 
output
+#?? variables. It also exports $(PYTHON_EXTRA_LIBS) and
 ?#?? $(PYTHON_EXTRA_LDFLAGS) for embedding Python in your code.
 ?#
 ?#?? You can search for some particular version of Python by passing a
@@ -67,7 +67,7 @@
 ?#?? modified version of the Autoconf Macro, you may extend this special
 ?#?? exception to the GPL to apply to your modified version as well.

-#serial 17
+#serial 23

 ?AU_ALIAS([AC_PYTHON_DEVEL], [AX_PYTHON_DEVEL])
 ?AC_DEFUN([AX_PYTHON_DEVEL],[
@@ -99,7 +99,7 @@ AC_DEFUN([AX_PYTHON_DEVEL],[
 ?This version of the AC@&t at _PYTHON_DEVEL macro
 ?doesn't work properly with versions of Python before
 ?2.1.0. You may need to re-run configure, setting the
-variables PYTHON_CPPFLAGS, PYTHON_LDFLAGS, PYTHON_SITE_PKG,
+variables PYTHON_CPPFLAGS, PYTHON_LIBS, PYTHON_SITE_PKG,
 ?PYTHON_EXTRA_LIBS and PYTHON_EXTRA_LDFLAGS by hand.
 ?Moreover, to disable this check, set PYTHON_NOVERSIONCHECK
 ?to something else than an empty string.
@@ -135,16 +135,25 @@ variable to configure. See ``configure --help'' 
for reference.
 ???? #
 ???? # Check if you have distutils, else fail
 ???? #
-??? AC_MSG_CHECKING([for the distutils Python package])
-??? ac_distutils_result=`$PYTHON -c "import distutils" 2>&1`
-??? if test -z "$ac_distutils_result"; then
+??? AC_MSG_CHECKING([for the sysconfig Python package])
+??? ac_sysconfig_result=`$PYTHON -c "import sysconfig" 2>&1`
+??? if test $? -eq 0; then
 ???????? AC_MSG_RESULT([yes])
+??????? IMPORT_SYSCONFIG="import sysconfig"
 ???? else
 ???????? AC_MSG_RESULT([no])
-??????? AC_MSG_ERROR([cannot import Python module "distutils".
+
+??????? AC_MSG_CHECKING([for the distutils Python package])
+??????? ac_sysconfig_result=`$PYTHON -c "from distutils import 
sysconfig" 2>&1`
+??????? if test $? -eq 0; then
+??????????? AC_MSG_RESULT([yes])
+??????????? IMPORT_SYSCONFIG="from distutils import sysconfig"
+??????? else
+??????????? AC_MSG_ERROR([cannot import Python module "distutils".
 ?Please check your Python installation. The error was:
-$ac_distutils_result])
-??????? PYTHON_VERSION=""
+$ac_sysconfig_result])
+??????????? PYTHON_VERSION=""
+??????? fi
 ???? fi

 ???? #
@@ -152,10 +161,19 @@ $ac_distutils_result])
 ???? #
 ???? AC_MSG_CHECKING([for Python include path])
 ???? if test -z "$PYTHON_CPPFLAGS"; then
-??????? python_path=`$PYTHON -c "import distutils.sysconfig; \
-??????????? print (distutils.sysconfig.get_python_inc ());"`
-??????? plat_python_path=`$PYTHON -c "import distutils.sysconfig; \
-??????????? print (distutils.sysconfig.get_python_inc 
(plat_specific=1));"`
+??????? if test "$IMPORT_SYSCONFIG" = "import sysconfig"; then
+??????????? # sysconfig module has different functions
+??????????? python_path=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_path ('include'));"`
+??????????? plat_python_path=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_path ('platinclude'));"`
+??????? else
+??????????? # old distutils way
+??????????? python_path=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_python_inc ());"`
+??????????? plat_python_path=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_python_inc (plat_specific=1));"`
+??????? fi
 ???????? if test -n "${python_path}"; then
 ???????????? if test "${plat_python_path}" != "${python_path}"; then
 ???????????????? python_path="-I$python_path -I$plat_python_path"
@@ -172,14 +190,14 @@ $ac_distutils_result])
 ???? # Check for Python library path
 ???? #
 ???? AC_MSG_CHECKING([for Python library path])
-??? if test -z "$PYTHON_LDFLAGS"; then
+??? if test -z "$PYTHON_LIBS"; then
 ???????? # (makes two attempts to ensure we've got a version number
 ???????? # from the interpreter)
 ???????? ac_python_version=`cat<<EOD | $PYTHON -

 ?# join all versioning strings, on some systems
 ?# major/minor numbers could be in different list elements
-from distutils.sysconfig import *
+from sysconfig import *
 ?e = get_config_var('VERSION')
 ?if e is not None:
 ???? print(e)
@@ -197,7 +215,7 @@ EOD`
 ???????? # Make the versioning information available to the compiler

 ???????? # JW: We don't need it and it interferes with the hack
-??????? # to detect multiple Pyhton versions
+??????? # to detect multiple Python versions
 ???????? #AC_DEFINE_UNQUOTED([HAVE_PYTHON], ["$ac_python_version"],
 ???????????????? #????????????????? [If available, contains the Python 
version number currently in use.])

@@ -205,8 +223,8 @@ EOD`
 ???????? ac_python_libdir=`cat<<EOD | $PYTHON -

 ?# There should be only one
-import distutils.sysconfig
-e = distutils.sysconfig.get_config_var('LIBDIR')
+$IMPORT_SYSCONFIG
+e = sysconfig.get_config_var('LIBDIR')
 ?if e is not None:
 ???? print (e)
 ?EOD`
@@ -214,8 +232,8 @@ EOD`
 ???????? # Now, for the library:
 ???????? ac_python_library=`cat<<EOD | $PYTHON -

-import distutils.sysconfig
-c = distutils.sysconfig.get_config_vars()
+$IMPORT_SYSCONFIG
+c = sysconfig.get_config_vars()
 ?if 'LDVERSION' in c:
 ???? print ('python'+c[['LDVERSION']])
 ?else:
@@ -230,44 +248,67 @@ EOD`
 ???????? then
 ???????????? # use the official shared library
 ???????????? ac_python_library=`echo "$ac_python_library" | sed 
"s/^lib//"`
-??????????? PYTHON_LDFLAGS="-L$ac_python_libdir -l$ac_python_library"
+??????????? PYTHON_LIBS="-L$ac_python_libdir -l$ac_python_library"
 ???????? else
 ???????????? # old way: use libpython from python_configdir
 ???????????? ac_python_libdir=`$PYTHON -c \
-????????????? "from distutils.sysconfig import get_python_lib as f; \
+????????????? "from sysconfig import get_python_lib as f; \
 ?????????????? import os; \
 ?????????????? print (os.path.join(f(plat_specific=1, standard_lib=1), 
'config'));"`
-??????????? PYTHON_LDFLAGS="-L$ac_python_libdir 
-lpython$ac_python_version"
+??????????? PYTHON_LIBS="-L$ac_python_libdir -lpython$ac_python_version"
 ???????? fi

-??????? if test -z "PYTHON_LDFLAGS"; then
+??????? if test -z "PYTHON_LIBS"; then
 ???????????? AC_MSG_ERROR([
 ?? Cannot determine location of your Python DSO. Please check it was 
installed with
-? dynamic libraries enabled, or try setting PYTHON_LDFLAGS by hand.
+? dynamic libraries enabled, or try setting PYTHON_LIBS by hand.
 ???????????? ])
 ???????? fi
 ???? fi
-??? AC_MSG_RESULT([$PYTHON_LDFLAGS])
-??? AC_SUBST([PYTHON_LDFLAGS])
+??? AC_MSG_RESULT([$PYTHON_LIBS])
+??? AC_SUBST([PYTHON_LIBS])

 ???? #
 ???? # Check for site packages
 ???? #
 ???? AC_MSG_CHECKING([for Python site-packages path])
 ???? if test -z "$PYTHON_SITE_PKG"; then
-??????? PYTHON_SITE_PKG=`$PYTHON -c "import distutils.sysconfig; \
-??????????? print (distutils.sysconfig.get_python_lib(0,0));"`
+??????? if test "$IMPORT_SYSCONFIG" = "import sysconfig"; then
+??????????? PYTHON_SITE_PKG=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_path('purelib'));"`
+??????? else
+??????????? # distutils.sysconfig way
+??????????? PYTHON_SITE_PKG=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_python_lib(0,0));"`
+??????? fi
 ???? fi
 ???? AC_MSG_RESULT([$PYTHON_SITE_PKG])
 ???? AC_SUBST([PYTHON_SITE_PKG])

+??? #
+??? # Check for platform-specific site packages
+??? #
+??? AC_MSG_CHECKING([for Python platform specific site-packages path])
+??? if test -z "$PYTHON_SITE_PKG"; then
+??????? if test "$IMPORT_SYSCONFIG" = "import sysconfig"; then
+??????????? PYTHON_PLATFORM_SITE_PKG=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_path('platlib'));"`
+??????? else
+??????????? # distutils.sysconfig way
+??????????? PYTHON_PLATFORM_SITE_PKG=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? print (sysconfig.get_python_lib(1,0));"`
+??????? fi
+??? fi
+??? AC_MSG_RESULT([$PYTHON_PLATFORM_SITE_PKG])
+??? AC_SUBST([PYTHON_PLATFORM_SITE_PKG])
+
 ???? #
 ???? # libraries which must be linked in when embedding
 ???? #
 ???? AC_MSG_CHECKING(python extra libraries)
 ???? if test -z "$PYTHON_EXTRA_LIBS"; then
-?????? PYTHON_EXTRA_LIBS=`$PYTHON -c "import distutils.sysconfig; \
-??????????????? conf = distutils.sysconfig.get_config_var; \
+?????? PYTHON_EXTRA_LIBS=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????????? conf = sysconfig.get_config_var; \
 ???????????????? print (conf('LIBS') + ' ' + conf('SYSLIBS'))"`
 ???? fi
 ???? AC_MSG_RESULT([$PYTHON_EXTRA_LIBS])
@@ -278,8 +319,8 @@ EOD`
 ???? #
 ???? AC_MSG_CHECKING(python extra linking flags)
 ???? if test -z "$PYTHON_EXTRA_LDFLAGS"; then
-??????? PYTHON_EXTRA_LDFLAGS=`$PYTHON -c "import distutils.sysconfig; \
-??????????? conf = distutils.sysconfig.get_config_var; \
+??????? PYTHON_EXTRA_LDFLAGS=`$PYTHON -c "$IMPORT_SYSCONFIG; \
+??????????? conf = sysconfig.get_config_var; \
 ???????????? print (conf('LINKFORSHARED'))"`
 ???? fi
 ???? AC_MSG_RESULT([$PYTHON_EXTRA_LDFLAGS])
@@ -291,8 +332,10 @@ EOD`
 ???? AC_MSG_CHECKING([consistency of all components of python 
development environment])
 ???? # save current global flags
 ???? ac_save_LIBS="$LIBS"
+??? ac_save_LDFLAGS="$LDFLAGS"
 ???? ac_save_CPPFLAGS="$CPPFLAGS"
-??? LIBS="$ac_save_LIBS $PYTHON_LDFLAGS $PYTHON_EXTRA_LDFLAGS 
$PYTHON_EXTRA_LIBS"
+??? LIBS="$ac_save_LIBS $PYTHON_LIBS $PYTHON_EXTRA_LIBS 
$PYTHON_EXTRA_LIBS"
+??? LDFLAGS="$ac_save_LDFLAGS $PYTHON_EXTRA_LDFLAGS"
 ???? CPPFLAGS="$ac_save_CPPFLAGS $PYTHON_CPPFLAGS"
 ???? AC_LANG_PUSH([C])
 ???? AC_LINK_IFELSE([
@@ -303,15 +346,17 @@ EOD`
 ???? # turn back to default flags
 ???? CPPFLAGS="$ac_save_CPPFLAGS"
 ???? LIBS="$ac_save_LIBS"
+??? LDFLAGS="$ac_save_LDFLAGS"

 ???? AC_MSG_RESULT([$pythonexists])

 ???????? if test ! "x$pythonexists" = "xyes"; then
+??????? # gpgme: only warn here, no error, as we are looking for 
multiple versions
 ??????? AC_MSG_WARN([
 ?? Could not link test program to Python. Maybe the main Python library 
has been
 ?? installed in some non-standard library path. If so, pass it to 
configure,
-? via the LDFLAGS environment variable.
-? Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
+? via the LIBS environment variable.
+? Example: ./configure LIBS="-L/usr/non-standard-path/python/lib"
============================================================================
 ??? You probably have to install the development version of the Python 
package
 ??? for your distribution.? The exact name of this package varies among 
them.
@@ -323,4 +368,4 @@ EOD`
 ???? #
 ???? # all done!
 ???? #
-])
+])
\ No newline at end of file
-- 2.34.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211223/62297310/attachment-0001.sig>

From code at bnavigator.de  Thu Dec 23 16:37:13 2021
From: code at bnavigator.de (Ben Greiner)
Date: Thu, 23 Dec 2021 16:37:13 +0100
Subject: [PATCH gpgme 2/2] build: Find correct version string for Python >=
 3.10
In-Reply-To: <48167e34-3b78-4d22-dc05-9e57015e5b44@bnavigator.de>
References: <48167e34-3b78-4d22-dc05-9e57015e5b44@bnavigator.de>
Message-ID: <43631bb2-5cb3-0c74-8543-96921895e819@bnavigator.de>

* m4/python.m4: use version_info for Python 3.10 version string

--
Format sys.version_info[:2] instead of cutting it from sys.version[:3]
as Python versions >= 3.10 have more than 3 characters for their version
string. Bump minimum Python version to 2.1 because the new
ax_python_devel specifies this.
---
  configure.ac |  3 ++-
  m4/python.m4 | 15 +++++++--------
  2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4ce30677..bb124c54 100644
--- a/configure.ac
+++ b/configure.ac
@@ -425,11 +425,12 @@ if test "$found_py" = "1"; then
  	if test "$found_py" = "1" -o "$found_py3" = "1"; then
  	  # Reset everything, so that we can look for another Python.
            m4_foreach([mym4pythonver],
-                     [[2.7],[3.4],[3.5],[3.6],[3.7],[3.8],[3.9],[all]],
+                     [[2.7],[3.4],[3.5],[3.6],[3.7],[3.8],[3.9],[3.10],[all]],
             [unset PYTHON
  	    unset PYTHON_VERSION
  	    unset PYTHON_CPPFLAGS
  	    unset PYTHON_LDFLAGS
+	    unset PYTHON_LIBS
  	    unset PYTHON_SITE_PKG
  	    unset PYTHON_EXTRA_LIBS
  	    unset PYTHON_EXTRA_LDFLAGS
diff --git a/m4/python.m4 b/m4/python.m4
index fd0fe771..5dfbeddb 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -36,13 +36,12 @@
  # numbers and dots only.
  AC_DEFUN([AM_PATH_PYTHON],
   [
-  dnl Find a Python interpreter.  Python versions prior to 2.0 are not
-  dnl supported. (2.0 was released on October 16, 2000).  Python 3.0
-  dnl through to Python 3.9 are also not supported.
+  dnl Find a Python interpreter.  Python versions prior to 2.1 are not
+  dnl supported. Python 3.0 through to Python 3.3 are also not supported.
    m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
  [python2 python2.7 dnl
   python dnl
- python3 python3.9 python3.8 python3.7 python3.6 python3.5 python3.4
+ python3 python3.10 python3.9 python3.8 python3.7 python3.6 python3.5 python3.4
   ])
  
    AC_ARG_VAR([PYTHON], [the Python interpreter])
@@ -89,12 +88,12 @@ AC_DEFUN([AM_PATH_PYTHON],
      m4_default([$3], [AC_MSG_ERROR([no suitable Python interpreter found])])
    else
  
-  dnl Query Python for its version number.  Getting [:3] seems to be
-  dnl the best way to do this; it's what "site.py" does in the standard
-  dnl library.
+  dnl Query Python for its version number.  Formatting sys.version_info[:2]
+  dnl seems to be the most reliable way to do this across versions 2.1
+  dnl through 3.10; it's what "site.py" does in the standard 3.10 library.
  
    AC_CACHE_CHECK([for $am_display_PYTHON version], [am_cv_python_version],
-    [am_cv_python_version=`$PYTHON -c "import sys; sys.stdout.write(sys.version[[:3]])"`])
+    [am_cv_python_version=`$PYTHON -c "import sys; sys.stdout.write('%d.%d' % sys.version_info[[:2]])"`])
    AC_SUBST([PYTHON_VERSION], [$am_cv_python_version])
  
    dnl Use the values of $prefix and $exec_prefix for the corresponding
-- 2.34.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211223/2d588087/attachment.sig>

From code at bnavigator.de  Thu Dec 23 16:56:55 2021
From: code at bnavigator.de (Ben Greiner)
Date: Thu, 23 Dec 2021 16:56:55 +0100
Subject: [PATCH gpgme 2/2] build: Find correct version string for Python
 >= 3.10
In-Reply-To: <43631bb2-5cb3-0c74-8543-96921895e819@bnavigator.de>
References: <48167e34-3b78-4d22-dc05-9e57015e5b44@bnavigator.de>
 <43631bb2-5cb3-0c74-8543-96921895e819@bnavigator.de>
Message-ID: <155f56c1-f69d-2b9b-9be1-cb67bf3d49ec@bnavigator.de>

Hi,

I am sorry, it seems that despite I sent a test e-mail to myself before 
and Thunderbird shows that correctly, that the patch format shows 
mangled line numbers in the archives.

My first submission a week ago using `git send-email` directly didn't 
make it through moderations due to not being signed up to the ML.

I additionally created "Revisions" on dev.gnupg.org now: D545 and D546.

Whatever works, please take the appropriate one, or let me know how I 
could improve the submission.

Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211223/80a72184/attachment.sig>

From me at jawa.dev  Fri Dec 24 21:06:51 2021
From: me at jawa.dev (Joshua Rubin)
Date: Fri, 24 Dec 2021 13:06:51 -0700
Subject: pinentry fails for tpm protected key
Message-ID: <a57a02c9-5d8c-480a-8e80-f5ebcb946577@beta.fastmail.com>

When I have "Save in password manager" selected, pinentry fails to work at all for my tpm protected private key. The error I get is: The value for attribute 'keygrip' was not a valid UTF-8 string.

If I do not have "Save in password manager" selected, it works fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211224/a680ba82/attachment.html>

From me at jawa.dev  Fri Dec 24 21:17:39 2021
From: me at jawa.dev (Joshua Rubin)
Date: Fri, 24 Dec 2021 13:17:39 -0700
Subject: pinentry fails for tpm protected key
Message-ID: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>

When I have "Save in password manager" selected, pinentry fails to work at all for my tpm protected private key. The error I get is: The value for attribute 'keygrip' was not a valid UTF-8 string.

If I do not have "Save in password manager" selected, it works fine.


From James.Bottomley at HansenPartnership.com  Mon Dec 27 15:17:41 2021
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Mon, 27 Dec 2021 09:17:41 -0500
Subject: pinentry fails for tpm protected key
In-Reply-To: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
Message-ID: <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>

On Fri, 2021-12-24 at 13:17 -0700, Joshua Rubin via Gnupg-devel wrote:
> When I have "Save in password manager" selected, pinentry fails to
> work at all for my tpm protected private key. The error I get is: The
> value for attribute 'keygrip' was not a valid UTF-8 string.
> 
> If I do not have "Save in password manager" selected, it works fine.

I think you're going to have to be a lot more specific.  I use gpg-
agent with pinentry and tpm keys and it works fine for me on openSUSE
and gpg-2.3.4.

James




From me at jawa.dev  Mon Dec 27 22:46:27 2021
From: me at jawa.dev (Joshua Rubin)
Date: Mon, 27 Dec 2021 14:46:27 -0700
Subject: pinentry fails for tpm protected key
In-Reply-To: <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
 <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
Message-ID: <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>

> I think you're going to have to be a lot more specific.  I use gpg-
> agent with pinentry and tpm keys and it works fine for me on openSUSE
> and gpg-2.3.4.

I'm using gpg-2.3.4 and pinentry 1.2.0. I _only_ have this issue when I select that I want to save the passphrase in the keyring, it works otherwise (which I think is what it sounds like you are doing). Happy to provide any other useful details, just not sure what you might need.


From James.Bottomley at HansenPartnership.com  Thu Dec 30 04:31:30 2021
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 29 Dec 2021 22:31:30 -0500
Subject: pinentry fails for tpm protected key
In-Reply-To: <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
 <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
 <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>
Message-ID: <058791e128b34a068514b0cdba6030414a8cffd8.camel@HansenPartnership.com>

On Mon, 2021-12-27 at 14:46 -0700, Joshua Rubin via Gnupg-devel wrote:
> > I think you're going to have to be a lot more specific.  I use gpg-
> > agent with pinentry and tpm keys and it works fine for me on
> > openSUSE
> > and gpg-2.3.4.
> 
> I'm using gpg-2.3.4 and pinentry 1.2.0. I _only_ have this issue when
> I select that I want to save the passphrase in the keyring, it works
> otherwise (which I think is what it sounds like you are doing). Happy
> to provide any other useful details, just not sure what you might
> need.

Based on this, my best guess is that whatever is on the other end of
libsecret doesn't like binary key grips.  There's no harm in converting
them all to ASCII, does this fix your problem?

James

---

>From 7af7213246a7cf085cdf42d1f79abf0d6333ed30 Mon Sep 17 00:00:00 2001
From: James Bottomley <James.Bottomley at HansenPartnership.com>
Date: Wed, 29 Dec 2021 11:58:16 -0500
Subject: [PATCH] agent: always use hexgrip when storing key password

The current code uses the binary ctrl->keygrip, but all the passphrase
storage engines expect this to be a string, so convert the binary
keygrip to a hex one before passing it in as the keyid.  This fixes a
crash seen in some libsecret implementations where a non-ascii keyid
isn't well handled.

Signed-off-by: James Bottomley <James.Bottomley at HansenPartnership.com>
---
 agent/call-tpm2d.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/agent/call-tpm2d.c b/agent/call-tpm2d.c
index 6fae5d85a..1048c7d63 100644
--- a/agent/call-tpm2d.c
+++ b/agent/call-tpm2d.c
@@ -141,14 +141,17 @@ agent_tpm2d_writekey (ctrl_t ctrl, unsigned char **shadow_info,
 static gpg_error_t
 pin_cb (ctrl_t ctrl, const char *prompt, char **passphrase)
 {
-  *passphrase = agent_get_cache (ctrl, ctrl->keygrip, CACHE_MODE_USER);
+  char hexgrip[2*KEYGRIP_LEN + 1];
+
+  bin2hex (ctrl->keygrip, KEYGRIP_LEN, hexgrip);
+  *passphrase = agent_get_cache (ctrl, hexgrip, CACHE_MODE_USER);
   if (*passphrase)
     return 0;
   return agent_get_passphrase(ctrl, passphrase,
 			      _("Please enter your passphrase, so that the "
 				"secret key can be unlocked for this session"),
 			      prompt, NULL, 0,
-			      ctrl->keygrip, CACHE_MODE_USER, NULL);
+			      hexgrip, CACHE_MODE_USER, NULL);
 }
 
 int
@@ -160,6 +163,7 @@ agent_tpm2d_pksign (ctrl_t ctrl, const unsigned char *digest,
   char line[ASSUAN_LINELENGTH];
   membuf_t data;
   struct inq_parm_s inqparm;
+  char hexgrip[2*KEYGRIP_LEN + 1];
 
   rc = start_tpm2d (ctrl);
   if (rc)
@@ -183,7 +187,10 @@ agent_tpm2d_pksign (ctrl_t ctrl, const unsigned char *digest,
 			inq_extra, &inqparm,
 			NULL, NULL);
   if (!rc)
-    agent_put_cache (ctrl, ctrl->keygrip, CACHE_MODE_USER, inqparm.pin, 0);
+    {
+      bin2hex (ctrl->keygrip, KEYGRIP_LEN, hexgrip);
+      agent_put_cache (ctrl, hexgrip, CACHE_MODE_USER, inqparm.pin, 0);
+    }
 
   xfree (inqparm.pin);
 
@@ -208,6 +215,7 @@ agent_tpm2d_pkdecrypt (ctrl_t ctrl, const unsigned char *cipher,
   char line[ASSUAN_LINELENGTH];
   membuf_t data;
   struct inq_parm_s inqparm;
+  char hexgrip[2*KEYGRIP_LEN + 1];
 
   rc = start_tpm2d (ctrl);
   if (rc)
@@ -231,7 +239,10 @@ agent_tpm2d_pkdecrypt (ctrl_t ctrl, const unsigned char *cipher,
 			inq_extra, &inqparm,
 			NULL, NULL);
   if (!rc)
-    agent_put_cache (ctrl, ctrl->keygrip, CACHE_MODE_USER, inqparm.pin, 0);
+    {
+      bin2hex (ctrl->keygrip, KEYGRIP_LEN, hexgrip);
+      agent_put_cache (ctrl, hexgrip, CACHE_MODE_USER, inqparm.pin, 0);
+    }
 
   xfree (inqparm.pin);
 
-- 
2.26.2




From me at jawa.dev  Thu Dec 30 08:03:10 2021
From: me at jawa.dev (Joshua Rubin)
Date: Thu, 30 Dec 2021 00:03:10 -0700
Subject: pinentry fails for tpm protected key
In-Reply-To: <058791e128b34a068514b0cdba6030414a8cffd8.camel@HansenPartnership.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
 <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
 <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>
 <058791e128b34a068514b0cdba6030414a8cffd8.camel@HansenPartnership.com>
Message-ID: <5361c665-b63b-4060-b5de-e89c3e5f1466@beta.fastmail.com>

> Based on this, my best guess is that whatever is on the other end of
> libsecret doesn't like binary key grips.  There's no harm in converting
> them all to ASCII, does this fix your problem?

That seems to get things set in the 3rd party password cache now. However, I'm now receiving this error:

Dec 29 22:49:53 balerion gpg-agent[3755873]: WARNING:esys:src/tss2-esys/api/Esys_Sign.c:311:Esys_Sign_Finish() Received TPM Error
Dec 29 22:49:53 balerion gpg-agent[3755873]: ERROR:esys:src/tss2-esys/api/Esys_Sign.c:105:Esys_Sign() Esys Finish ErrorCode (0x000001d5)
Dec 29 22:49:53 balerion gpg-agent[3755873]: TPM2_Sign failed with 469
Dec 29 22:49:53 balerion gpg-agent[3755873]: tpm:parameter(1):structure is the wrong size
Dec 29 22:49:53 balerion gpg-agent[3755447]: smartcard signing failed: Card error
Dec 29 22:49:53 balerion gpg-agent[3755447]: command 'PKSIGN' failed: Card error

And the gpg command itself says (for a sign only op):

gpg: signing failed: Card error
-----BEGIN PGP MESSAGE-----

gpg: signing failed: Card error

And for sign+encrypt (it does output some data on stdout):
gpg: [stdin]: sign+encrypt failed: Card error

Note that encrypt and decrypt operations work fine, it's only the signing key that has the issue (I have 3 separate subkeys, one of each type).

I was able to run `keytotpm` on newly generated keys with the same result. Reverting back to the unpatched gpg did not fix things though. Not sure if this is the same problem.

Thanks


From James.Bottomley at HansenPartnership.com  Thu Dec 30 19:09:23 2021
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 30 Dec 2021 13:09:23 -0500
Subject: pinentry fails for tpm protected key
In-Reply-To: <5361c665-b63b-4060-b5de-e89c3e5f1466@beta.fastmail.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
 <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
 <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>
 <058791e128b34a068514b0cdba6030414a8cffd8.camel@HansenPartnership.com>
 <5361c665-b63b-4060-b5de-e89c3e5f1466@beta.fastmail.com>
Message-ID: <06f0be0b592cdb72202f38d54eeae4080d7edae1.camel@HansenPartnership.com>

On Thu, 2021-12-30 at 00:03 -0700, Joshua Rubin via Gnupg-devel wrote:
> > Based on this, my best guess is that whatever is on the other end
> > of libsecret doesn't like binary key grips.  There's no harm in
> > converting them all to ASCII, does this fix your problem?
> 
> That seems to get things set in the 3rd party password cache now.
> However, I'm now receiving this error:
> 
> Dec 29 22:49:53 balerion gpg-agent[3755873]: WARNING:esys:src/tss2-
> esys/api/Esys_Sign.c:311:Esys_Sign_Finish() Received TPM Error
> Dec 29 22:49:53 balerion gpg-agent[3755873]: ERROR:esys:src/tss2-
> esys/api/Esys_Sign.c:105:Esys_Sign() Esys Finish ErrorCode
> (0x000001d5)
> Dec 29 22:49:53 balerion gpg-agent[3755873]: TPM2_Sign failed with
> 469

I'm afraid I'm not very familiar with the Intel TSS, since my gpg code
always uses the IBM TSS, which gives very verbose error messages, but
this looks like a TPM error.

> Dec 29 22:49:53 balerion gpg-agent[3755873]:
> tpm:parameter(1):structure is the wrong size

right, TPM_RC_SIZE, which means the digest is the wrong size or the TPM
doesn't understand the digest algorithm ... what digest are you using?

James




From me at jawa.dev  Thu Dec 30 19:16:55 2021
From: me at jawa.dev (Joshua Rubin)
Date: Thu, 30 Dec 2021 11:16:55 -0700
Subject: pinentry fails for tpm protected key
In-Reply-To: <06f0be0b592cdb72202f38d54eeae4080d7edae1.camel@HansenPartnership.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
 <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
 <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>
 <058791e128b34a068514b0cdba6030414a8cffd8.camel@HansenPartnership.com>
 <5361c665-b63b-4060-b5de-e89c3e5f1466@beta.fastmail.com>
 <06f0be0b592cdb72202f38d54eeae4080d7edae1.camel@HansenPartnership.com>
Message-ID: <2d926ffd-b6d0-4382-afeb-704402e8e469@beta.fastmail.com>

> right, TPM_RC_SIZE, which means the digest is the wrong size or the TPM
> doesn't understand the digest algorithm ... what digest are you using?

Oh, I was messing with that the other day... thanks for the reminder. I pretty much gave up in frustration with that effort. Is there any way I can check to see what digest is actually being used by a key?

My config has these lines, so I'm certain it's SHA512, but finding a way to actually see this info would be immensely useful.

personal-digest-preferences SHA512
digest-algo SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed

Any error that suggests that this is the issue would be much more helpful then what I found.

Also, is there any way to find out what algos the tpm supports?

Thanks again, I know this thread is now very off topic.

Joshua


From James.Bottomley at HansenPartnership.com  Thu Dec 30 19:23:20 2021
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 30 Dec 2021 13:23:20 -0500
Subject: pinentry fails for tpm protected key
In-Reply-To: <2d926ffd-b6d0-4382-afeb-704402e8e469@beta.fastmail.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
 <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
 <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>
 <058791e128b34a068514b0cdba6030414a8cffd8.camel@HansenPartnership.com>
 <5361c665-b63b-4060-b5de-e89c3e5f1466@beta.fastmail.com>
 <06f0be0b592cdb72202f38d54eeae4080d7edae1.camel@HansenPartnership.com>
 <2d926ffd-b6d0-4382-afeb-704402e8e469@beta.fastmail.com>
Message-ID: <f1314bae2f536829a02e5587fbee93d89506c47a.camel@HansenPartnership.com>

On Thu, 2021-12-30 at 11:16 -0700, Joshua Rubin via Gnupg-devel wrote:
> > right, TPM_RC_SIZE, which means the digest is the wrong size or the
> > TPM doesn't understand the digest algorithm ... what digest are you
> > using?
> 
> Oh, I was messing with that the other day... thanks for the reminder.
> I pretty much gave up in frustration with that effort. Is there any
> way I can check to see what digest is actually being used by a key?

Not short of adding a print of digestlen in the code.

> 
> My config has these lines, so I'm certain it's SHA512, but finding a
> way to actually see this info would be immensely useful.
> 
> personal-digest-preferences SHA512

Pretty much no laptop TPM will support this, so I'd cut that down to
SHA256 which is guaranteed to be supported by every TPM.

> digest-algo SHA512
> cert-digest-algo SHA512
> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
> CAST5 BZIP2 ZLIB ZIP Uncompressed
> 
> Any error that suggests that this is the issue would be much more
> helpful then what I found.
> 
> Also, is there any way to find out what algos the tpm supports?

it's listed in the algorithm capabilities.  With the IBM TSS, that's

tssgetcapability -cap 0|grep ALG_SHA

James




From me at jawa.dev  Thu Dec 30 19:36:17 2021
From: me at jawa.dev (Joshua Rubin)
Date: Thu, 30 Dec 2021 11:36:17 -0700
Subject: pinentry fails for tpm protected key
In-Reply-To: <f1314bae2f536829a02e5587fbee93d89506c47a.camel@HansenPartnership.com>
References: <25c7558a-9567-4b81-a88b-cf10b2a977ac@beta.fastmail.com>
 <24ed064116cf324bace094514ae48da3880716b5.camel@HansenPartnership.com>
 <eb970241-2f23-4c1f-9618-acd15bb633ed@beta.fastmail.com>
 <058791e128b34a068514b0cdba6030414a8cffd8.camel@HansenPartnership.com>
 <5361c665-b63b-4060-b5de-e89c3e5f1466@beta.fastmail.com>
 <06f0be0b592cdb72202f38d54eeae4080d7edae1.camel@HansenPartnership.com>
 <2d926ffd-b6d0-4382-afeb-704402e8e469@beta.fastmail.com>
 <f1314bae2f536829a02e5587fbee93d89506c47a.camel@HansenPartnership.com>
Message-ID: <6db9847a-0040-4c7d-819c-64d296ff42dd@beta.fastmail.com>

>> Also, is there any way to find out what algos the tpm supports?
>
> it's listed in the algorithm capabilities.  With the IBM TSS, that's
>
> tssgetcapability -cap 0|grep ALG_SHA

I was able to figure this out with:
tpm2_getcap algorithms
tpm2_getcap ecc-curves

Thanks for all your help!