From jb-gnumlists at wisemo.com  Sat Nov  1 08:08:27 2025
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Sat, 1 Nov 2025 08:08:27 +0100
Subject: How to setup trust?
In-Reply-To: <87pla3cca7.fsf@lispclub.com>
References: <87pla3cca7.fsf@lispclub.com>
Message-ID: <014efe78-eb8d-b653-478d-83c098a486c8@wisemo.com>

On 31/10/2025 16:37, Daniel Cerqueira wrote:
> Hi.
>
> Firstly, I am not subscribe to this list.  Please, do reply my address
> in the "To:", and the gnupg-users at gnupg.org in the "Cc:" field.  Thanks!
>
> Second, I am trying to use the trust feature of GnuPG.  My GnuPG uses
> the trust model "pgp".
>
> Now, if I do `gpg -k "<wk at gnupg.org>"` it shows this:
>
> --8<---------------cut here---------------start------------->8---
> pub   ed25519/0x63113AE866587D0A 2018-09-28 [SC] [expires: 2027-01-31]
>        Key fingerprint = AEA8 4EDC F01A D86C 4701  C85C 6311 3AE8 6658 7D0A
> uid                   [ unknown] wk at gnupg.org
> uid                   [ unknown] werner at eifzilla.de
> uid                   [ unknown] wk at g10code.com
> uid                   [ unknown] werner.koch at gnupg.com
> sub   ed25519/0x19CC1C9E085B107A 2020-08-04 [S]
>        Key fingerprint = 8777 461F 2A07 4EBC 480D  3594 19CC 1C9E 085B 107A
> sub   brainpoolP384r1/0x2B999FA9CE046B1B 2021-06-28 [E] [expires: 2027-01-10]
>        Key fingerprint = A1DB 793D C236 63E7 F914  75D8 2B99 9FA9 CE04 6B1B
> sub   ky768_bp256/0x5CF9E3DE6BC9DA95 2025-02-06 [E]
>        Key fingerprint = 5CF9E 3DE6B C9DA9 57ED2 4B39E C2D29 580F7 0B3F8 AF14B 8D7BE
> --8<---------------cut here---------------end--------------->8---
>
> The "[ unknown]" is what shows the trust?  Or it shows something else
> (like PGP's concept of validity)?
"Trust" is PGP's concept of validity.? Not sure if the --list-keys 
output prints out
the full trust result, or only the calculated result from other 
signatures.? Someone
else on the list has to answer that.
>
> Third, how can I make this 0x63113AE866587D0A key, to be marginally
> trusted?
The root of trust in the PGP model is to "ultimately trust" one of your 
own keys (not
necessarily the one you use for regular e-mail), and then count the 
trust levels of keys
that signed other keys.

For gnupg, this ultimate trust is typically granted to all the keys for 
which your copy
of gnupg stores the private key under your user account, plus any 
offline keys listed
in the "--trusted-key" option (which is usually placed in a gnupg config 
file).

On top of the default calculation of trust based on signatures tracing 
back to your
trusts, gnupg has a personal database of "ownertrusts", which can be changed
interactively with the command "gpg --edit-key" and saved with the command
"gpg --export-ownertrust".? Usually, gnupg will prompt you to set the 
trust for
any key where you have not yet set it.? Either when encountering the key 
in its
calculations or when rerunning the calculculations with the command
"gpg --update-trustdb" .?? Much more about this concept can be found in the
gnupg handbook .

> I have tried making a local signature with cert-level of 1 and also have
> edited this key's `trust` to be "marginal", then "save".  Afterwards, I
> did an `gpg --update-trustdb`, and still I get the output above :-( .
>
>
> I am not understanding how the GnuPG's trust feature works.  I want to
> learn.
>
>
> Cheers for Freedom :-) ,
>
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From dan.git at lispclub.com  Sun Nov  2 02:32:11 2025
From: dan.git at lispclub.com (Daniel Cerqueira)
Date: Sun, 02 Nov 2025 01:32:11 +0000
Subject: How to setup trust?
In-Reply-To: <014efe78-eb8d-b653-478d-83c098a486c8@wisemo.com> (Jakob Bohm's
 message of "Sat, 1 Nov 2025 08:08:27 +0100")
References: <87pla3cca7.fsf@lispclub.com>
 <014efe78-eb8d-b653-478d-83c098a486c8@wisemo.com>
Message-ID: <87ecqhcj8k.fsf@lispclub.com>

Jakob Bohm <jb-gnumlists at wisemo.com> writes:

> Much more about this concept can be found in the gnupg handbook .

Thank you, Jakob, for this info.  I haven't read all the GnuPG Handbook,
yet.

I am now reading all past mails to this list about "trust", am also
reading GnuPG Privacy Handbook; all while reading the `man 1 gpg`.  I
will also be reading the GnuPG FAQ.

So, it will take some time for me to getting back on this thread.

Hopefully, after this investment in knowledge, I will get an
understanding about the concept of Trust with GnuPG, the Web of Trust
concept; in order to write Internet Log articles (in a Web Log -- Blog
-- and in a Gopher Log -- Phlog) to clarify people about these concepts.

Unfortunately, I believe there is a big misunderstanding about what the
Web of Trust is, what is Trust to GnuPG, what is Ownertrust in GnuPG,
and what is validity in GnuPG.  I, myself, struggle with these concepts,
even after having read a book about PGP 7 and an introduction to
cryptography.

Lastly, and most important, I want to thank Werner and all the GnuPG
Hackers, for making GnuPG a reality.  I really love this project.  I
also support the LibrePGP initiative; not meaning a defensive move only,
but as a way for the future.  Finally, thank you for you that keep this
list a positive and welcoming environment for learning about GnuPG!

I will be coming to this thread, when the time has come.

Cheers for Freedom,


-- 
The pioneers of a warless world are the youth that
refuse military service. ~ Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251102/9b3b8583/attachment.sig>

From bwalzer at 59.ca  Sun Nov  2 20:46:58 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Sun, 2 Nov 2025 13:46:58 -0600
Subject: My comments on: Legacy Encryption Downgrade Attacks against GnuPG
In-Reply-To: <87ed6fb4g3.fsf@jacob.g10code.de>
References: <87ed6fb4g3.fsf@jacob.g10code.de>
Message-ID: <aQe1MgSrMXvS9qxe@watt.59.ca>

This paper has been discussed on this list before. So I will assume
possible interest and will post a link to my comments:

Legacy Encryption Downgrade Attacks against LibrePGP and CMS: Some Comments
    https://articles.59.ca/doku.php?id=pgpfan:ledowngrade

Bruce


From rjh at sixdemonbag.org  Thu Nov  6 20:53:26 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 6 Nov 2025 14:53:26 -0500
Subject: GPGMEPP and C++ antipatterns
Message-ID: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>

After using GPGMEPP for a week or so, I'm pleased with it. Somebody 
clearly put some thought into how to make it a properly C++ library, 
rather than just a thin wrapper around a C one. Whoever's responsible 
for that (Ingo?), thank you.

However, I do have a couple of minor nits. (Of course I do. It's me.)

First, a number of functions accept unsigned ints as a parameter. This 
involves a minor pain point for those of us working in environments that 
require us to follow the MISRA C++ guidelines. Admittedly, it's a 
one-letter fix:

	(*ctx).setKeyListMode(0);
		|
	     becomes
		|
		V
	(*ctx).setKeyListMode(0U);

but it would be nice if we could find some way to avoid one letter of 
syntactic sugar and let us express code in the most natural way.

Second, MISRA has ? I can only call them _opinions_, shall we say ? on 
the subject of pointers. Look at, e.g., creating a new Context:

	auto ctx = unique_ptr<Context>(OpenPGP);
	if (nullptr == ctx) {
	    // handle the error
	}

Here there are two problems. The first is that GPGMEPP is using 
old-style enums rather than modern C++ class enums, which means they're 
not typesafe and it's harder for static analysis tools to detect when 
you're feeding in garbage. The second is that per MISRA, unique_ptrs and 
shared_ptrs should be created only by calls to make_unique and/or 
make_shared, not by direct application of the constructor.

Hence, two more suggestions. First, replace all enums with C++ class 
enums, and second, make createForProtocol take a template parameter of 
the type of pointer to return, whether unique, shared, or raw.

These minor problems aren't creating any obstacles to my development, 
just requiring me to fill out a small amount of paperwork documenting 
the deviations from MISRA. All in all I quite like GPGMEPP. Thanks for 
the code, guys. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251106/6d9fae7d/attachment.sig>

From rjh at sixdemonbag.org  Thu Nov  6 22:00:52 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 6 Nov 2025 16:00:52 -0500
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
Message-ID: <9142e0ea-7a5c-4c38-bf8f-9bf8f4c6cd36@sixdemonbag.org>

>  ????auto ctx = unique_ptr<Context>(OpenPGP);

Gah! I was literally looking at my code while copying it and still 
somehow managed to goof it.

"auto ctx = unique_ptr<Context>(Context::createForProtocol(OpenPGP));"

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

From johndoe65534 at mail.com  Fri Nov  7 07:47:57 2025
From: johndoe65534 at mail.com (john doe)
Date: Fri, 7 Nov 2025 07:47:57 +0100
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
Message-ID: <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>

On 11/6/25 20:53, Robert J. Hansen via Gnupg-users wrote:
> After using GPGMEPP for a week or so, I'm pleased with it. Somebody 
> clearly put some thought into how to make it a properly C++ library, 
> rather than just a thin wrapper around a C one. Whoever's responsible 
> for that (Ingo?), thank you.
> 
> However, I do have a couple of minor nits. (Of course I do. It's me.)
> 

I'm not sure why you are posting this here instead of patching this up 
and creating a PR.

-- 
John Doe


From wk at gnupg.org  Fri Nov  7 09:53:09 2025
From: wk at gnupg.org (Werner Koch)
Date: Fri, 07 Nov 2025 09:53:09 +0100
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com> (john doe via
 Gnupg-users's message of "Fri, 7 Nov 2025 07:47:57 +0100")
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
 <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>
Message-ID: <87v7jmz0ju.fsf@jacob.g10code.de>

On Fri,  7 Nov 2025 07:47, john doe said:
> I'm not sure why you are posting this here instead of patching this up
> and creating a PR.

Because a mailing list is a better media than a bug tracker because it
reaches a muchwider audience.  The bug tracker is only monitored by a
few hackers.

gnupg-devel might have been more appropriate but gnupg-user may also
mean users of GPGME.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/8fa0374f/attachment.sig>

From jtbaldikoski at gmail.com  Fri Nov  7 01:47:22 2025
From: jtbaldikoski at gmail.com (Jack Baldikoski)
Date: Thu, 6 Nov 2025 16:47:22 -0800
Subject: Question/Bug?
Message-ID: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>

I've tried following Thunderbird's instructions here
<https://mzl.la/4bFoVkJ> to make my private key RFC 4880-compatible with
the --rfc4880 flag, but GPG does not change any of the feature flags. Am I
doing something wrong?

Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251106/7f1c3dd2/attachment.html>

From alci at mecadu.org  Fri Nov  7 11:43:58 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Fri, 7 Nov 2025 11:43:58 +0100
Subject: No PIN asked for with libpam-poldi
Message-ID: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>

Hi,

I'm trying to use my Yubikey with libpam-poldi to sudo on a Ubuntu based 
OS (Tuxedo OS).

My card is working:

$ gpg --card-status

Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00
Application ID ...: Dxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Yubico
[...]

When using pass password manager, I am asked for a PIN to unlock the 
card, touch it and I get my password unencrypted.
It also works with browserpass Firefox extension.

So far so good.

Now, I have setup libpam-poldi:
- created the /etc/poldi/localdb/users and linked my user with the 
Application ID
- created the /etc/poldi/localdb/keys/MyAppID file, with

sudo sh -c 'gpg-connect-agent "/datafile 
/etc/poldi/localdb/keys/MyAppID" "SCD READKEY --advanced OPENPGP.3" /bye'

My .gnupg/scdaemon.conf file looks like this:
disable-ccid

My /etc/pam.d/sudo and /etc/pam.d/sudo-i have auth sufficient pam_poldi.so

And finally .gnupg/gpg-agent.conf looks like:
pinentry-program /usr/bin/pinentry-qt
debug-lvel 3
enable-ssh-support
ttyname $GPG_TTY
default-cache-ttl 60
max-cache-ttl 120


Nos, when I try to sudo, I am asked to insert my card, and asked for a 
password, but never for a PIN:

$sudo su
Insert authentication card for user `franck'
Trying authentication as user `franck'...
[sudo] password for franck:

Journalctl -f shows:
gpg-agent[13666]: scdaemon[13666]: detected reader 'Yubico YubiKey 
OTP+FIDO+CCID 00 00'
gpg-agent[13666]: scdaemon[13666]: detected reader 'Yubico YubiKey 
OTP+FIDO+CCID 00 00'

But I am never given the opportunity to unlock the card...
Any idea to fix or to troubleshoot this ?

Thanks
Franck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/69d23db0/attachment.html>

From rjh at sixdemonbag.org  Fri Nov  7 14:20:25 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 7 Nov 2025 08:20:25 -0500
Subject: The community fringe (was GPGMEPP)
In-Reply-To: <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
 <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>
Message-ID: <cc4dc2ce-2f07-417b-ab75-d594ce98f493@sixdemonbag.org>

> I'm not sure why you are posting this here instead of patching this up 
> and creating a PR.

A couple of solid ones.

1. Do I understand things correctly? We're not talking about a bug fix, 
we're talking about architectural and API changes. These are not things 
to be done lightly. Discussing proposed changes before going through the 
work of implementing them is generally a better option.

2. I'm a former government-funded digital forensics researcher who has 
delivered research results at NSA. That's enough to make me permanently 
suspect in the eyes of some people in the community. For this reason I 
don't touch the code. I don't want anyone who might be thinking of using 
GnuPG decide "no, no, I can't trust it, they accept patches from people 
with NSA ties."

#2 also has a disturbing aspect of there are people in this community 
who are clinically paranoid and mentally ill. 95% of these people are 
harmless victims of a terrible mental illness who deserve our love, 
support, and understanding.

5% of these people send me unhinged emails threatening my life.

=====

If you are legitimate, wait three days for me to cool down you asshole. 
I have sat here and tolerated the pandering to Windows people the Gnu 
people have been telling Microsoft people are stupid long enough. 
Personally, these statements by you are TOTALLY out of character to 
***EVERYTHING*** I have heard from Werner Koch and others say for years. 
  I have assumed all during this time that Werner and the others are 
much more intelligent than me (true).  I have also assumed that they are 
so busy that they haven't had time to do much of anything else (that I 
don't know the truth of).  I don't give a damn how many people have 
signed your god-damn keys. THAT IS WHY I SAY, IF YOU ARE A GOD-DAMN FBI 
AGENT YOU GO TO HELL!!!  I WILL KILL YOU, YOU SON OF SATAN!!!  This 
message is signed and encrypted. Take it for what it is worth.  If the 
filthy United States would allow me to adopt my nom-de-guerre as 
legitimate legal alias I would do so and MAYBE (*JUST* *MAYBE*) the 
signing of this message would have more meaning to you.  I doubt it though.

=====

Really, folks, that's what some users send me. That's about one-sixth of 
the complete email, which is ? well, much the same as that excerpt. That 
guy also dug up my home address, my employer, and my phone number. I had 
to get the police involved and it was a bad experience for everyone.

Also remember that when the SKS keyserver network was poisoned by 
certificates sporting hundreds of thousands of spurious signatures, that 
was almost certainly done by someone who believed they needed to "save 
the GnuPG ecosystem". The fact they used the certificates of Daniel Kahn 
Gillmor and myself to wage this attack also tells you who this deranged 
person thought GnuPG needed to be saved from. The more I touch the code, 
the more the nutcases like the key-poisoner are incentivized to act.

So, yeah. As a general rule I don't touch the code unless explicitly 
invited. I don't want to cause anyone to lose faith in GnuPG, and I 
don't want to provoke the crazies into "saving GnuPG".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/41a9002a/attachment.sig>

From kloecker at kde.org  Fri Nov  7 15:56:58 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Fri, 07 Nov 2025 15:56:58 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
Message-ID: <4634150.niJfEyVGOH@daneel>

On Freitag, 7. November 2025 11:43:58 Mitteleurop?ische Normalzeit Franck 
Routier (Personnel) via Gnupg-users wrote:
> I'm trying to use my Yubikey with libpam-poldi to sudo on a Ubuntu based
> OS (Tuxedo OS).
[...]
> My .gnupg/scdaemon.conf file looks like this:
> disable-ccid
> 
> My /etc/pam.d/sudo and /etc/pam.d/sudo-i have auth sufficient pam_poldi.so
> 
> And finally .gnupg/gpg-agent.conf looks like:
> pinentry-program /usr/bin/pinentry-qt
> debug-lvel 3

Typo? In any case, avoid the weird debug-level setting. Use "debug ipc" 
instead. Also set log-file so that the logs don't end up in some random place 
(or nowhere).

> enable-ssh-support
> ttyname $GPG_TTY
> default-cache-ttl 60
> max-cache-ttl 120
> 
> 
> Nos, when I try to sudo, I am asked to insert my card, and asked for a
> password, but never for a PIN:
> 
> $sudo su
> Insert authentication card for user `franck'
> Trying authentication as user `franck'...
> [sudo] password for franck:

Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to start 
because there's no window manager running. Try using pinentry-curses or 
pinentry-tty instead of pinentry-qt if you are anyway using the terminal.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/b5b9f2c5/attachment.sig>

From alci at mecadu.org  Fri Nov  7 18:36:43 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Fri, 7 Nov 2025 18:36:43 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <4634150.niJfEyVGOH@daneel>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <4634150.niJfEyVGOH@daneel>
Message-ID: <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>

> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
> instead. Also set log-file so that the logs don't end up in some random place
> (or nowhere).
Yes typo. I removed it alltogether for now:

pinentry-program /usr/bin/pinentry-qt
enable-ssh-support
ttyname $GPG_TTY
default-cache-ttl 60
max-cache-ttl 120

> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to start
> because there's no window manager running. Try using pinentry-curses or
> pinentry-tty instead of pinentry-qt if you are anyway using the terminal.
In fact gpg-agent seems to be able to call pinentry-qt, as when I use 
pass or browserpass, it works and I get a pretty pinentry window...

That said, switching to pinentry-tty does not solve the problem with pam.
In fact I can see pinentry-tty working with pass and failing with sudo 
in the same terminal session:

$ pass perso/ameli.fr
Please unlock the card
Number: 10 955 601
Holder: Franck Routier
PIN:
*************************
$ sudo su
Insert authentication card for user `franck'
Trying authentication as user `franck'...
[sudo] password for franck:


Franck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/41bd40bb/attachment-0001.html>

From bwalzer at 59.ca  Sat Nov  8 19:16:33 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Sat, 8 Nov 2025 12:16:33 -0600
Subject: Question/Bug?
In-Reply-To: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
References: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
Message-ID: <aQ-JAXshfbPQ8S2h@ohm.59.ca>

On Thu, Nov 06, 2025 at 04:47:22PM -0800, Jack Baldikoski via Gnupg-users wrote:
> I've tried following Thunderbird's instructions here
> <https://mzl.la/4bFoVkJ> to make my private key RFC 4880-compatible with
> the --rfc4880 flag, but GPG does not change any of the feature flags. Am I
> doing something wrong?

Is this now no longer an issue for Thunderbird due to RNP support as
suggested in the comment in the bug report?

The --rfc4880 flag doesn't seem to affect the preferences. The Arch
Wiki suggests you do this:

    setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP

... with expert mode. I dunno what the expert mode does. Seems to work
without.

* https://wiki.archlinux.org/title/GnuPG#OpenPGP_compatibility

I note that the Arch page has gotten very partisan towards the RFC9580
faction at the expense of the LibrePGP faction. Sort of annoying.

Bruce


From wk at gnupg.org  Mon Nov 10 10:43:15 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 10:43:15 +0100
Subject: Question/Bug?
In-Reply-To: <aQ-JAXshfbPQ8S2h@ohm.59.ca> (Bruce Walzer via Gnupg-users's
 message of "Sat, 8 Nov 2025 12:16:33 -0600")
References: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
 <aQ-JAXshfbPQ8S2h@ohm.59.ca>
Message-ID: <87bjlaxlxo.fsf@jacob.g10code.de>

Hi!

BTW, RFC-4880 compatibily would also mean to drop support for Curve25519
(ed25519 and cv25519) because they are not covered by the ECC extension
to OpenPGP (RFC-6637).  I doubt that anyone wants that.

OCB mode is meanwhile widely used and RNP (the Thunderbird *PGP library)
also supports it (actually cross-tested with GnuPG back in 2018).  The
TB maintainer just refuses to enable this feature in RNP.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251110/c89c886c/attachment.sig>

From bernhard at intevation.de  Mon Nov 10 12:38:21 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 10 Nov 2025 12:38:21 +0100
Subject: @GnuPG@mstdn.social Mastodon account (re: gnupg.social domain)
Message-ID: <202511101238.21660.bernhard@intevation.de>

Am Donnerstag 23 Oktober 2025 22:18:08 schrieb Juergen M. BRUCKNER via 
Gnupg-users:
> Well there is a Mastodon account (@GnuPG at mstdn.social) for GnuPG. Don't
> know who runs it, but it seems to be a official account.

Currently I am the one running https://mstdn.social/@GnuPG
in behalf of the GnuPG (and Gpg4win) initiative. 

(it also says there:
  currently operated by @ber at social.tchncs.de/
and was discussed here on this list, e.g. on 2023-05-31 15:23.)

I used to run it on behalf of the GnuPG e.V (the association was 
discontinued), so now it is more or less the core devs, supporters and other 
helpers here and on gnupg-devel@ that form the core group responsible for 
GnuPG. The majority of technical work for th products is currently done by 
10code as far as I can see.

From my perspective we do not need our own Fediverse or Mastodon instance
at this point. mstdn.social and other servers are maintained well and allow
us to us microblogging in a federated way. 

Best Regards,
Bernhard

-- 
https://intevation.de/~bernhard         +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Managing Directors: 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-users/attachments/20251110/258f67b0/attachment.sig>

From hfollmann at itcfollmann.com  Mon Nov 10 14:52:25 2025
From: hfollmann at itcfollmann.com (Henning Follmann)
Date: Mon, 10 Nov 2025 08:52:25 -0500
Subject: @GnuPG@mstdn.social Mastodon account (re: gnupg.social domain)
In-Reply-To: <202511101238.21660.bernhard@intevation.de>
References: <202511101238.21660.bernhard@intevation.de>
Message-ID: <aRHuGUYJ9l-0fnun@fedora>

On Mon, Nov 10, 2025 at 12:38:21PM +0100, Bernhard Reiter via Gnupg-users wrote:
> Am Donnerstag 23 Oktober 2025 22:18:08 schrieb Juergen M. BRUCKNER via 
> Gnupg-users:
> > Well there is a Mastodon account (@GnuPG at mstdn.social) for GnuPG. Don't
> > know who runs it, but it seems to be a official account.
> 
> Currently I am the one running https://mstdn.social/@GnuPG
> in behalf of the GnuPG (and Gpg4win) initiative. 
> 
> (it also says there:
>   currently operated by @ber at social.tchncs.de/
> and was discussed here on this list, e.g. on 2023-05-31 15:23.)
> 
> I used to run it on behalf of the GnuPG e.V (the association was 
> discontinued), so now it is more or less the core devs, supporters and other 
> helpers here and on gnupg-devel@ that form the core group responsible for 
> GnuPG. The majority of technical work for th products is currently done by 
> 10code as far as I can see.
> 
> From my perspective we do not need our own Fediverse or Mastodon instance
> at this point. mstdn.social and other servers are maintained well and allow
> us to us microblogging in a federated way. 
> 

Hello,

I already dropped the domain. If you change your mind, you might be able to
register it again (if no domain hog took it).


-H







From bernhard at intevation.de  Mon Nov 10 15:19:46 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 10 Nov 2025 15:19:46 +0100
Subject: @GnuPG@mstdn.social Mastodon account (re: gnupg.social domain)
In-Reply-To: <aRHuGUYJ9l-0fnun@fedora>
References: <202511101238.21660.bernhard@intevation.de>
 <aRHuGUYJ9l-0fnun@fedora>
Message-ID: <202511101519.46618.bernhard@intevation.de>

Am Montag 10 November 2025 14:52:25 schrieb Henning Follmann:
> I already dropped the domain. If you change your mind, you might be able to
> register it again (if no domain hog took it).

Thanks for having reserved it and the principal idea!
(There are so many toplevel domains these days that someone cannot get all of 
them to prevent typo squatting or domain hogging. At least I believe that 
user just will have to pay more attention.)


-- 
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-users/attachments/20251110/71d6481a/attachment.sig>

From loup at loup-vaillant.fr  Tue Nov 11 10:44:01 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Tue, 11 Nov 2025 10:44:01 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
Message-ID: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>

Hi,

I'm currently trying to implement OpenPGP signatures to sign my code. 
RFC 9580 is fairly readable, but it?s not crystal clear how people do 
signatures in practice, so I?used GnuPG as a reference.  Version 2.4.4, 
as installed by default on my Ubuntu 24.04.

I made a signature with the following command:

     gpg --detach-sign monocypher-4.0.2.tar.gz

Here?s the hex dump of the resulting file:

     0000  88 75 04 00 16 0a 00 1d  16 21 04 bb bc 09 18 65
     0010  b9 94 0a 37 ca 9a df 86  40 f6 ba 7b ff b3 4a 05
     0020  02 69 12 0d 2c 00 0a 09  10 86 40 f6 ba 7b ff b3
     0030  4a fb 3b 00 fe 3f a0 ab  23 e1 5f df e2 21 a2 5b
     0040  2b 9b 01 5d 7c 9a 8d ec  da ac c8 85 96 24 94 bf
     0050  f9 da 57 86 a8 00 f9 01  10 75 54 63 b2 86 7d a7
     0060  7d 13 f5 5e cb 09 82 f9  c2 11 84 4d ae dc 9f fb
     0070  4a 5a e3 8d 82 76 0f
     0077

Reading the RFC, the first bytes should contain a packet header.
The first byte is the Encoded Packet Type ID.  So:

     0x88 = 0b10001000

Broken down, I get:

     10  : Legacy format
     0010: 2 (SIG)
     00  : Length is encoded in one byte

So the next byte, 0x75, should be the length of the body.  Which matches 
the length of my file (0x77 bytes total, minus the 2-byte header).  I 
have yet to decipher the rest of the packet, but that?s not my main 
concern right now. My question is, *did GnuPG really produce a legacy 
packet?*

The RFC states that is should not:

 > The Legacy packet format SHOULD NOT be used to generate new data,
 > unless the recipient is known to only support the Legacy packet
 > format. This latter case is extremely unlikely, as the Legacy packet
 > format was obsoleted by [RFC2440] in 1998.

As far as I can tell, version 2.4.4 is from last year.  And yet it 
outputs *by default* a legacy format that was obsoleted 26 years prior? 
I must be missing something.  Either I read the hex dump wrong, or 
there?s a justification behind GnuPG?s use of the legacy format.  If 
someone could explain, I?d be very grateful.

Thanks,
Loup.



From bwalzer at 59.ca  Tue Nov 11 13:11:59 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Tue, 11 Nov 2025 06:11:59 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
Message-ID: <aRMoD7nyHRNIL92A@ohm.59.ca>

On Tue, Nov 11, 2025 at 10:44:01AM +0100, Loup Vaillant wrote:
[..]
>
>     0x88 = 0b10001000
>
> Broken down, I get:
>
>     10  : Legacy format
[...]
> The RFC {9580} states that is should not:
>
> > The Legacy packet format SHOULD NOT be used to generate new data,
> > unless the recipient is known to only support the Legacy packet
> > format. This latter case is extremely unlikely, as the Legacy packet
> > format was obsoleted by [RFC2440] in 1998.

>From RFC-2440:

>PGP 2.6.x only uses old format packets. Thus, software that
>interoperates with those versions of PGP must only use old format
>packets. If interoperability is not an issue, either format may be
>used.

No preference is expressed at all in RFC-2440. So it appears that
RFC-9580 is simply incorrect.

>From RFC-4880:

>PGP 2.6.x only uses old format packets. Thus, software that
>interoperates with those versions of PGP must only use old format
>packets.  If interoperability is not an issue, the new packet format
>is RECOMMENDED.

So RFC-9580 is also incorrect for RFC-4880 as well. I don't know the
reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
incorrect language was used. You would probably have to ask on the
appropriate mailing list to find out if anyone from that faction still
knows, is still around, and is interested enough to answer your
question.

There doesn't seem to be any practical reason to use a new packet
header if the packet tag is less than 16. Otherwise you *have* to use
a new packet header.

LibrePGP introduces no changes from RFC-4880 with respect to this. So
in the world of GnuPG the new packet format is only "RECOMMENDED" for
cases where interoperability is not an issue.

Bruce


From andrewg at andrewg.com  Tue Nov 11 15:59:30 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 11 Nov 2025 14:59:30 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRMoD7nyHRNIL92A@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
Message-ID: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>

Hi, Bruce.

On 11/11/2025 12:11, Bruce Walzer via Gnupg-users wrote:
>
> No preference is expressed at all in RFC-2440. So it appears that
> RFC-9580 is simply incorrect.
...
> So RFC-9580 is also incorrect for RFC-4880 as well.

It is neither accurate nor helpful to use the term "incorrect". None of 
these documents claim correctness, they are merely specifications. That 
means that they can and will differ; it does not mean that any of them 
are more "correct" than any other. All that you can say is that some of 
them are more recent than others.

> I don't know the
> reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> incorrect language was used.

Surely the reason is obvious? It is desirable in general to gracefully 
sunset legacy formats. As you have pointed out already, the 
specification changed between RFC2440 and RFC4880, to explicitly prefer 
the newer format (with caveats). RFC9580 merely strengthens the language 
again to more strongly prefer the newer format. This seems to me to be a 
natural evolution of the spec.

> You would probably have to ask on the
> appropriate mailing list to find out if anyone from that faction still
> knows, is still around, and is interested enough to answer your
> question.

This backhanded snark is unbecoming of you, Bruce. The authors of 
RFC9580 are named individuals - three of whom currently work on PGP 
software, and one of those (Niibe) works on GnuPG. Your insinuation that 
RFC9580 was written by shadowy, disinterested figures is an insult to 
its authors, and you should consider issuing an apology.

For reference, the relevant mailing list is openpgp at lists.ietf.org 
(https://mailarchive.ietf.org/arch/browse/openpgp/)
> There doesn't seem to be any practical reason to use a new packet
> header if the packet tag is less than 16. Otherwise you *have* to use
> a new packet header.

The practical reason is that the implementers want the ability 
(eventually) to drop support for the legacy format. This can't be done 
if today's software is still generating it. Considering that all 
RFC2440-compatible software (i.e. anything written in the last 25 years) 
MUST implement the modern format, any software that cannot read it is so 
far out of date that it doesn't support any modern cryptography either 
(for example, it won't support MDC) so is not safe for use anyway, other 
than to read prehistoric archives.

A



From andrewg at andrewg.com  Tue Nov 11 15:59:30 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 11 Nov 2025 14:59:30 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRMoD7nyHRNIL92A@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
Message-ID: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>

Hi, Bruce.

On 11/11/2025 12:11, Bruce Walzer via Gnupg-users wrote:
>
> No preference is expressed at all in RFC-2440. So it appears that
> RFC-9580 is simply incorrect.
...
> So RFC-9580 is also incorrect for RFC-4880 as well.

It is neither accurate nor helpful to use the term "incorrect". None of 
these documents claim correctness, they are merely specifications. That 
means that they can and will differ; it does not mean that any of them 
are more "correct" than any other. All that you can say is that some of 
them are more recent than others.

> I don't know the
> reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> incorrect language was used.

Surely the reason is obvious? It is desirable in general to gracefully 
sunset legacy formats. As you have pointed out already, the 
specification changed between RFC2440 and RFC4880, to explicitly prefer 
the newer format (with caveats). RFC9580 merely strengthens the language 
again to more strongly prefer the newer format. This seems to me to be a 
natural evolution of the spec.

> You would probably have to ask on the
> appropriate mailing list to find out if anyone from that faction still
> knows, is still around, and is interested enough to answer your
> question.

This backhanded snark is unbecoming of you, Bruce. The authors of 
RFC9580 are named individuals - three of whom currently work on PGP 
software, and one of those (Niibe) works on GnuPG. Your insinuation that 
RFC9580 was written by shadowy, disinterested figures is an insult to 
its authors, and you should consider issuing an apology.

For reference, the relevant mailing list is openpgp at lists.ietf.org 
(https://mailarchive.ietf.org/arch/browse/openpgp/)
> There doesn't seem to be any practical reason to use a new packet
> header if the packet tag is less than 16. Otherwise you *have* to use
> a new packet header.

The practical reason is that the implementers want the ability 
(eventually) to drop support for the legacy format. This can't be done 
if today's software is still generating it. Considering that all 
RFC2440-compatible software (i.e. anything written in the last 25 years) 
MUST implement the modern format, any software that cannot read it is so 
far out of date that it doesn't support any modern cryptography either 
(for example, it won't support MDC) so is not safe for use anyway, other 
than to read prehistoric archives.

A



From wk at gnupg.org  Tue Nov 11 16:36:34 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Nov 2025 16:36:34 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr> (Loup
 Vaillant's message of "Tue, 11 Nov 2025 10:44:01 +0100")
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
Message-ID: <87ldkcvawt.fsf@jacob.g10code.de>

On Tue, 11 Nov 2025 10:44, Loup Vaillant said:

> code. RFC 9580 is fairly readable, but it?s not crystal clear how
> people do signatures in practice, so I?used GnuPG as a reference.

Oh and I thought one of the goals was to make it better readable ;-).
Yet another goal not achieved - which is also not a surprise given the
heavily increased size of the the specification.

>     10  : Legacy format

I don't know what you mean by Legacy Format.  It might be that RFC9580
defines that as legacy but there is no reason for this.  The old CTB
works just fine and can't be dropped for backward compatibility reasons.

> As far as I can tell, version 2.4.4 is from last year.  And yet it
> outputs *by default* a legacy format that was obsoleted 26 years

It has never been obsoleted.  BTW, GnuPG does not implement the new
RFC9580 specification but LibrePGP which is just a minor update to the
well matured RFC4880 specification.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251111/dfe7f773/attachment.sig>

From rjh at sixdemonbag.org  Tue Nov 11 16:46:46 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 11 Nov 2025 10:46:46 -0500
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
Message-ID: <42c96fd8-d275-4654-86d1-4458cf3f8fb0@sixdemonbag.org>

> This backhanded snark is unbecoming of you, Bruce. The authors of 
> RFC9580 are named individuals - three of whom currently work on PGP 
> software, and one of those (Niibe) works on GnuPG. Your insinuation that 
> RFC9580 was written by shadowy, disinterested figures is an insult to 
> its authors, and you should consider issuing an apology.

Thank you, Andrew, for being the first to say this, and to do it in a 
gentlemanly way.

I completely agree with Andrew.

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

From bwalzer at 59.ca  Tue Nov 11 21:57:16 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Tue, 11 Nov 2025 14:57:16 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
Message-ID: <aROjLAmLnFJU_2kL@ohm.59.ca>

On Tue, Nov 11, 2025 at 02:59:30PM +0000, Andrew Gallagher via Gnupg-users wrote:
> Hi, Bruce.
> 
> On 11/11/2025 12:11, Bruce Walzer via Gnupg-users wrote:
> > 
> > No preference is expressed at all in RFC-2440. So it appears that
> > RFC-9580 is simply incorrect.
> ...
> > So RFC-9580 is also incorrect for RFC-4880 as well.
> 
> It is neither accurate nor helpful to use the term "incorrect". None of
> these documents claim correctness, they are merely specifications. That
> means that they can and will differ; it does not mean that any of them are
> more "correct" than any other. All that you can say is that some of them are
> more recent than others.

RFC-9580 states:

>...as the Legacy packet format was obsoleted by [RFC2440] in 1998.

That statement is literally incorrect for RFC2440. So I don't really
know what you mean here. It is simply wrong and I don't see how any
further discussion is possible.

> 
> > I don't know the
> > reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> > incorrect language was used.
> 
> Surely the reason is obvious? It is desirable in general to gracefully
> sunset legacy formats. As you have pointed out already, the specification
> changed between RFC2440 and RFC4880, to explicitly prefer the newer format
> (with caveats). RFC9580 merely strengthens the language again to more
> strongly prefer the newer format. This seems to me to be a natural evolution
> of the spec.

Yes, but *why* was the language strngthened from RFC-4880 to more
strongly prefer the newer format? That is the question at hand. You
can't just claim some inevitable trend in the pursuit of that
question, particularly in this case where it seems that whoever
modified this section incorrectly thought that the old packet format
had been obsoleted in RFC2440. Perhaps that person might feel
differently in light of the corrected information.

> 
> > You would probably have to ask on the
> > appropriate mailing list to find out if anyone from that faction still
> > knows, is still around, and is interested enough to answer your
> > question.
> 
> This backhanded snark is unbecoming of you, Bruce. The authors of RFC9580
> are named individuals - three of whom currently work on PGP software, and
> one of those (Niibe) works on GnuPG. Your insinuation that RFC9580 was
> written by shadowy, disinterested figures is an insult to its authors, and
> you should consider issuing an apology.

If I am insulting someone here, then those someones don't really
exist. This is based on more than one experience. I would go to ITEF
openpgp mailing list and ask why something was the way it was in the
draft that eventually became RFC-9580. In each case I came bath with
the impression that the original proponent was no longer around or was
no longer responding. That's understandable for a process that spanned
so many years, but it is still a thing.

> 
> For reference, the relevant mailing list is openpgp at lists.ietf.org
> (https://mailarchive.ietf.org/arch/browse/openpgp/)
> > There doesn't seem to be any practical reason to use a new packet
> > header if the packet tag is less than 16. Otherwise you *have* to use
> > a new packet header.
> 
> The practical reason is that the implementers want the ability (eventually)
> to drop support for the legacy format. This can't be done if today's
> software is still generating it. Considering that all RFC2440-compatible
> software (i.e. anything written in the last 25 years) MUST implement the
> modern format, any software that cannot read it is so far out of date that
> it doesn't support any modern cryptography either (for example, it won't
> support MDC) so is not safe for use anyway, other than to read prehistoric
> archives.

*Why* drop it? I happen to know that a popular implementation (GnuPG)
generates old packet headers as a matter of course and has been doing
that since forever. So the usage is completely standard in
practice. If you want to change the RFC-4880 wording then you have an
obligation to first convince the implementations to discontinue
use. Standaards should follow practice, not the other way around.

Bruce


From jtbaldikoski at gmail.com  Tue Nov 11 07:52:40 2025
From: jtbaldikoski at gmail.com (Jack Baldikoski)
Date: Mon, 10 Nov 2025 22:52:40 -0800
Subject: Question/Bug?
In-Reply-To: <87bjlaxlxo.fsf@jacob.g10code.de>
References: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
 <aQ-JAXshfbPQ8S2h@ohm.59.ca> <87bjlaxlxo.fsf@jacob.g10code.de>
Message-ID: <d6f13431-267a-4a6e-8e69-9c72342431b7@gmail.com>

On 11/10/25 1:43 AM, Werner Koch wrote:
 > Hi!

Hi Werner, and nice to meet you! I really appreciate all the work you?ve 
done for PGP.

 > BTW, RFC-4880 compatibily would also mean to drop support for Curve25519
 > (ed25519 and cv25519) because they are not covered by the ECC extension
 > to OpenPGP (RFC-6637).  I doubt that anyone wants that.
 >
 > OCB mode is meanwhile widely used and RNP (the Thunderbird *PGP library)
 > also supports it (actually cross-tested with GnuPG back in 2018).  The
 > TB maintainer just refuses to enable this feature in RNP.

True, and perhaps I didn?t say what I meant.

At least on macOS, using any flags, such as --rfc4880, --openpgp, and 
--rfc4880bis, when editing the key and setting prefs do not change the 
key feature flags whatsoever. They only change when set manually. I 
don?t mean to change the algorithm of the key, of course.

And I understand what?s *possible* in RNP/TB, but I?d hope to be able to 
set the feature flags of my key to be TB-compatible.

Best,
Jack


From loup at loup-vaillant.fr  Wed Nov 12 02:31:49 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Wed, 12 Nov 2025 02:31:49 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aROjLAmLnFJU_2kL@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
Message-ID: <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>

I have to say, what I'm seing for my first interaction with this mailing 
list doesn't encourage me to stick around.  I'll try not to waste too 
much of your time.  Still, I feel compelled to correct a couple 
reasoning flaws.

---

First, a note on the meaning of the word "obsolete".
Just so we understand each other.

To me, and I believe most people, "obsolete" does *not* mean "we can 
drop support right now".  It just means it is time to deprecate it.  The 
way that happens for wire formats (at least those who have a version 
marker) is always the same:

1. Have all readers support both formats.
2. Have all writers output the new format.
3. Let readers drop support for the old format.

When there are very few implementations, the process can be very quick. 
Or it can take forever, if some popular implementation keeps outputting 
the old format decades after the new is supported by all readers.

---

> RFC-9580 states:
> 
>> ...as the Legacy packet format was obsoleted by [RFC2440] in 1998.
> 
> That statement is literally incorrect for RFC2440. So I don't really
> know what you mean here. It is simply wrong and I don't see how any
> further discussion is possible.

In 1998, RFC 2440 introduced a new packet header format.
That new format subsumes the old format.
The new format is required for packets types 16 and higher.
In 2007, RFC 4880 introduced packets 17, 18, and 19.

It would be hard, given the above, to argue that the old format wasn't 
obsolete in 2007.  They didn't say "obsolete" or "deprecated", but still:

- Any fully compliant RFC 2440 reader has to understand the new format.
- Any fully compliant RFC 4880 writer has to sometimes write in the new
   format.

There's also a reasonable argument to be made that deprecation should 
have started as soon as 1998.  I'm personally in that camp, though I 
understand reluctance to do so before 2007, since there was no 
substantial official functionality behind it yet.


> Yes, but *why* was the language strngthened from RFC-4880 to more
> strongly prefer the newer format?

I can make an educated guess: despite the lenient wording of RFC 2440 
and RFC 2880, it is pretty obvious to me that the old format should have 
been deprecated since at least 2007.  The stronger wording is a signal 
to implementers who haven't gotten the memo, so hopefully phase (2) of 
the deprecation process can finally complete.  It is simply the right 
thing to do.

Now of course, I base my guess on two important premises:

- The new format is needed to support functionality from RFC 4880.
- The new format subsumes the old format.

Or in simpler terms, the new format is simply better.  Of course we 
should support only that one, instead of both formats.


> *Why* drop it? I happen to know that a popular implementation (GnuPG)
> generates old packet headers as a matter of course and has been doing
> that since forever. So the usage is completely standard in
> practice.

That, my friend, is circular reasoning.  A form of "Might Makes Right".

It should be obvious by now why we should drop it.  Again:
- It is subsumed by the new format.
- The new format is needed to support RFC 4880.

Once that's established, the onus is on you to show why we should 
support both formats, instead of just one.

Unless GnuPG doesn't read nor write packets of type 17, 18, or 19?  I 
would be genuinely surprised.  Or maybe the header writing logic has 
been duplicated, and the necessary refactoring is difficult?


> If you want to change the RFC-4880 wording then you have an
> obligation to first convince the implementations to discontinue
> use. Standaards should follow practice, not the other way around.

Unless of course practice is bad.  Which it is.  It only takes one 
popular implementation to keep outputting the old format to force 
everyone else to support reading both formats.  Which is more complex 
and more bug prone.  _At scale._

And I am beginning to suspect GnuPG is the only popular application that 
still outputs the old format by default.  I know it's a fairly minor 
detail: the additional format represents less than 30 lines of code in a 
properly written code base.  Still, for an application that is supposed 
to promote security that is quite the bad look.  Please don't do that.

Loup.



From rjh at sixdemonbag.org  Wed Nov 12 03:48:54 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 11 Nov 2025 21:48:54 -0500
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
 <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
Message-ID: <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>

> To me, and I believe most people, "obsolete" does *not* mean "we can 
> drop support right now".? It just means it is time to deprecate it.? The 
> way that happens for wire formats (at least those who have a version 
> marker) is always the same:

 From Merriam-Webster's online dictionary:

"obsolete: no longer in use or no longer useful."

Yes, if something is obsolete it is to be dropped. You are confusing 
obsolete with obsolescent:

"obsolescent: going out of use : becoming obsolete"

If it's obsolescent, deprecate it. If it's obsolete, get rid of it.

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

From wk at gnupg.org  Wed Nov 12 13:52:46 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Nov 2025 13:52:46 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Tue, 11 Nov 2025 14:59:30
 +0000")
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
Message-ID: <877bvvv2e9.fsf@jacob.g10code.de>

On Tue, 11 Nov 2025 14:59, Andrew Gallagher said:
> RFC9580 are named individuals - three of whom currently work on PGP
> software, and one of those (Niibe) works on GnuPG. Your insinuation

Just for the recods: After we finished the core of rfc4880bis and solved
the litigous things in Summer 2021, I stepped out due to my time
constraints.  Only editorial changes were planned ay the point and thus
I asked the design team to have my colleague Niibe-san to replace me.
Actually he planned to bring his Simple Octet String proposal forward
which makes the encoding of certain objects easier to describe.

That is the background why he is given as author.  I explictly asked the
new editor to drop me from the list of authors, when I realized that
they did substantial changes instead of just editorial changes.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251112/cfb515a9/attachment.sig>

From loup at loup-vaillant.fr  Wed Nov 12 18:47:47 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Wed, 12 Nov 2025 18:47:47 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
 <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
 <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>
Message-ID: <321808bf-6867-4c23-8598-055e06723c57@loup-vaillant.fr>

>> To me, and I believe most people, "obsolete" does *not* mean "we can 
>> drop support right now".? It just means it is time to deprecate it.  
>> The way that happens for wire formats (at least those who have a 
>> version marker) is always the same:
> 
>  From Merriam-Webster's online dictionary:
> 
> "obsolete: no longer in use or no longer useful."

The second part, "or no longer useful", is what I had in mind.
Applied to a wire format, the obvious consequence is "it is time to 
deprecate it".  Because of course we're not gonna break compatibility 
overnight.

---

While we're listing dictionary definitions, "obsolete" can also be a 
transitive verb.  Word reference says:

""" to make obsolete by replacing with something newer or better;
""" antiquate:
""" > Automation has obsoleted many factory workers.

That's how RFC 9580 used the word:

""" [...] the Legacy packet format was obsoleted by [RFC2440] in 1998.

- Considering the definition of "obsolete" as a transitive verb,
- considering RFC 2440 introduced the new packet format 27 years ago,
- considering that the new packet format dominates the old,

RFC 9580 is correct: RFC 2440 made the old format antique, and enabled 
other implementations to support the new, which is the first step for 
deprecation.

---

> Yes, if something is obsolete it is to be dropped. You are confusing 
> obsolete with obsolescent:
> 
> "obsolescent: going out of use : becoming obsolete"
> 
> If it's obsolescent, deprecate it. If it's obsolete, get rid of it.

That interpretation of "obsolete" is too strict in my opinion.  It would 
mean that if I cannot reasonably get rid of the old format, then it is 
not obsolete.

And as a matter of fact, readers can't get rid of it, because GnuPG 
still outputs it.  So under that interpretation, Werner just has to say 
"nope, not gonna change", and just like that the redundant, discouraged, 
old format is declared "not obsolete".

That would be a weird power to have.

Loup.



From loup at loup-vaillant.fr  Wed Nov 12 19:17:14 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Wed, 12 Nov 2025 19:17:14 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRMoD7nyHRNIL92A@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
Message-ID: <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>

> No preference is expressed at all in RFC-2440. So it appears that
> RFC-9580 is simply incorrect.

See my response about the various dictionary meanings of "obsolete" 
(here as a transitive verb), as to why it actually might be correct, 
even if RFC 2440 did not explicitly express a preference.

I won't die on that hill though, I know there's wiggle room.


>  From RFC-4880:
> 
>> PGP 2.6.x only uses old format packets. Thus, software that
>> interoperates with those versions of PGP must only use old format
>> packets.  If interoperability is not an issue, the new packet format
>> is RECOMMENDED.
> 
> So RFC-9580 is also incorrect for RFC-4880 as well. I don't know the
> reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> incorrect language was used.

That's where it is so useful to look up the official definition of the 
capital words from the RFCs.  You would have known that in this 
particular instance, RFC 9580 means the exact same thing as RFC 4880.

 From RFC 2119:

"" *SHOULD*  This word, or the adjective "RECOMMENDED", mean that there
"" may exist valid reasons in particular circumstances to ignore a
"" particular item, but the full implications must be understood and
"" carefully weighed before choosing a different course.
""
"" *SHOULD NOT*  This phrase, or the phrase "NOT RECOMMENDED" mean that
"" there may exist valid reasons in particular circumstances when the
"" particular behavior is acceptable or even useful, but the full
"" implications should be understood and the case carefully weighed
"" before implementing any behavior described with this label.

So when RFC 4880 says:

"" If interoperability is not an issue, the new packet format
"" is RECOMMENDED.

It means the exact same thing as:

"" If interoperability is not an issue, the old packet format
"" is NOT RECOMMENDED.

Which means the exact same thing as:

"" If interoperability is not an issue, the old packet format
"" SHOULD NOT be used.

Which (from those who output data) means the exact same thing as:

"" The Legacy packet format SHOULD NOT be used to generate new data,
"" unless the recipient is known to only support the Legacy packet
"" format.

So as you can see, the legal meaning of RFC 9580 here is exactly the 
same as that of RFC 4880.


> LibrePGP introduces no changes from RFC-4880 with respect to this. So
> in the world of GnuPG the new packet format is only "RECOMMENDED" for
> cases where interoperability is not an issue.

Let's be honest, interoperability has not ben an issues for likely more 
than a decade.  Given that, and the legal argument above, in GnuPG word 
you SHOULD output the new format, and you SHOULD NOT output the old format.

And now the real funny part.  The latest version of LibrePGP states:

"" If interoperability is not an issue, the new packet format
"" is RECOMMENDED

Same as RFC 4880.  So not only GnuPG is in clear violation of the legal 
equivalent of a "SHOULD NOT" from a 18 year old RFC, the recommendation 
(and associated violation) persists even through the very draft it 
promotes.

Loup.



From rjh at sixdemonbag.org  Wed Nov 12 20:08:41 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 12 Nov 2025 14:08:41 -0500
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <321808bf-6867-4c23-8598-055e06723c57@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
 <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
 <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>
 <321808bf-6867-4c23-8598-055e06723c57@loup-vaillant.fr>
Message-ID: <527f0f1e-e4e6-496b-8a73-714046becb53@sixdemonbag.org>

> And as a matter of fact, readers can't get rid of it, because GnuPG 
> still outputs it.? So under that interpretation, Werner just has to say 
> "nope, not gonna change", and just like that the redundant, discouraged, 
> old format is declared "not obsolete".

This exact thing is happening with the obsolescent IPv4 format.

IPv6 is out there, has been stable for 20+ years, but major companies 
are still being slow to adopt it for cost reasons: and because they 
refuse to modernize, IPv4 remains obsolescent and not obsolete.

This thing you think would be silly to happen is, in fact, happening 
constantly in the tech space. Right now, at this very moment.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251112/2662e9cc/attachment.sig>

From andrewg at andrewg.com  Wed Nov 12 20:41:01 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 12 Nov 2025 19:41:01 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <527f0f1e-e4e6-496b-8a73-714046becb53@sixdemonbag.org>
References: <527f0f1e-e4e6-496b-8a73-714046becb53@sixdemonbag.org>
Message-ID: <066D98E8-4E5B-497E-B10D-E8E8898351A5@andrewg.com>

On 12 Nov 2025, at 19:10, Robert J. Hansen via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> This exact thing is happening with the obsolescent IPv4 format.

I don?t think this is a useful comparison - ipv4 and ipv6 are separate stacks that have to operate in parallel for a long period of time, and we?re not yet at the stage where every single device and network on the internet is ipv6-capable. OpenPGP passed the equivalent stage on the tech adoption timeline somewhere around 2005 or 2006, before RFC4880 introduced packet types that were incompatible with the old framing (e.g. MDC). Aside from network management tools, there are no broadly-supported protocols that have a hard requirement for ipv6 - because entire networks and countless devices still have to be upgraded (at great expense). Whereas we could stop emitting the legacy framing at any time and few people outside this list would even notice? ;-)

A

From alci at mecadu.org  Wed Nov 12 22:07:15 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Wed, 12 Nov 2025 22:07:15 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <4634150.niJfEyVGOH@daneel> <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
Message-ID: <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org>

I managed to get some logs from gpg-agent. No sure how to interpret this 
however. No obvious error I can spot (but I don't know what to look for):

2025-11-12 21:59:02 gpg-agent[15833] gpg-agent (GnuPG) 2.4.4 starting in 
supervised mode.
2025-11-12 21:59:02 gpg-agent[15833] using fd 3 for std socket 
(/run/user/1000/gnupg/S.gpg-agent)
2025-11-12 21:59:02 gpg-agent[15833] using fd 4 for extra socket 
(/run/user/1000/gnupg/S.gpg-agent.extra)
2025-11-12 21:59:02 gpg-agent[15833] using fd 5 for ssh socket 
(/run/user/1000/gnupg/S.gpg-agent.ssh)
2025-11-12 21:59:02 gpg-agent[15833] using fd 6 for browser socket 
(/run/user/1000/gnupg/S.gpg-agent.browser)
2025-11-12 21:59:02 gpg-agent[15833] listening on: std=3 extra=4 
browser=6 ssh=5
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK Pleased to meet 
you, process 15832
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- RESET
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
ttyname=/dev/pts/4
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
ttytype=xterm-256color
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION display=:0
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
xauthority=/run/user/1000/xauth_uyqgiW
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=WAYLAND_DISPLAY=wayland-0
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=XDG_SESSION_TYPE=wayland
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
lc-ctype=fr_FR.UTF-8
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
lc-messages=fr_FR.UTF-8
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- [eof]
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> OK Pleased to meet 
you, process 15998
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 <- SCD GETINFO socket_name
2025-11-12 21:59:54 gpg-agent[15833] no running /usr/lib/gnupg/scdaemon 
daemon - starting it
2025-11-12 21:59:54 gpg-agent[15833] DBG: agent_flush_cache (pincache only)
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK GNU Privacy 
Guard's Smartcard server ready
2025-11-12 21:59:54 gpg-agent[15833] first connection to daemon 
/usr/lib/gnupg/scdaemon established
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> GETINFO socket_name
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: additional connections at 
'/run/user/1000/gnupg/S.scdaemon'
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> OPTION event-signal=12
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> GETINFO socket_name
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 <- BYE
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> OK closing connection
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> RESTART
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK Pleased to meet 
you, process 16050
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- RESET
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
ttytype=xterm-256color
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION display=:0
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
xauthority=/run/user/1000/xauth_uyqgiW
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=WAYLAND_DISPLAY=wayland-0
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=XDG_SESSION_TYPE=wayland
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- KILLAGENT
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK closing connection
2025-11-12 22:00:18 gpg-agent[15833] random usage: poolsize=600 mixed=0 
polls=0/0 added=0/0
 ? ? ? ? ? ? ? outmix=0 getlvl1=0/0 getlvl2=0/0
2025-11-12 22:00:18 gpg-agent[15833] rndjent stat: 
collector=0x0000000000000000 calls=0 bytes=0
2025-11-12 22:00:18 gpg-agent[15833] secmem usage: 0/65536 bytes in 0 blocks
2025-11-12 22:00:22 gpg-agent[16056] gpg-agent (GnuPG) 2.4.4 starting in 
supervised mode.
2025-11-12 22:00:22 gpg-agent[16056] using fd 3 for std socket 
(/run/user/1000/gnupg/S.gpg-agent)
2025-11-12 22:00:22 gpg-agent[16056] using fd 4 for extra socket 
(/run/user/1000/gnupg/S.gpg-agent.extra)
2025-11-12 22:00:22 gpg-agent[16056] using fd 5 for ssh socket 
(/run/user/1000/gnupg/S.gpg-agent.ssh)
2025-11-12 22:00:22 gpg-agent[16056] using fd 6 for browser socket 
(/run/user/1000/gnupg/S.gpg-agent.browser)
2025-11-12 22:00:22 gpg-agent[16056] listening on: std=3 extra=4 
browser=6 ssh=5
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet 
you, process 16055
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- RESET
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
ttyname=/dev/pts/4
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
ttytype=xterm-256color
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION display=:0
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
xauthority=/run/user/1000/xauth_uyqgiW
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
putenv=WAYLAND_DISPLAY=wayland-0
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
putenv=XDG_SESSION_TYPE=wayland
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
lc-ctype=fr_FR.UTF-8
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
lc-messages=fr_FR.UTF-8
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- [eof]
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet 
you, process 16072
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- SCD GETINFO socket_name
2025-11-12 22:00:31 gpg-agent[16056] no running /usr/lib/gnupg/scdaemon 
daemon - starting it
2025-11-12 22:00:31 gpg-agent[16056] DBG: agent_flush_cache (pincache only)
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK GNU Privacy 
Guard's Smartcard server ready
2025-11-12 22:00:31 gpg-agent[16056] first connection to daemon 
/usr/lib/gnupg/scdaemon established
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: additional connections at 
'/run/user/1000/gnupg/S.scdaemon'
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> OPTION event-signal=12
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- BYE
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK closing connection
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> RESTART
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK

Trying to sudo at 22:00:31
Before is just normal gpg-agent start (?).

Any idea ?

Regards,
Franck

Le 07/11/2025 ? 18:36, Franck Routier (Personnel) via Gnupg-users a ?crit?:
>> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
>> instead. Also set log-file so that the logs don't end up in some random place
>> (or nowhere).
> Yes typo. I removed it alltogether for now:
>
> pinentry-program /usr/bin/pinentry-qt
> enable-ssh-support
> ttyname $GPG_TTY
> default-cache-ttl 60
> max-cache-ttl 120
>
>> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to start
>> because there's no window manager running. Try using pinentry-curses or
>> pinentry-tty instead of pinentry-qt if you are anyway using the terminal.
> In fact gpg-agent seems to be able to call pinentry-qt, as when I use 
> pass or browserpass, it works and I get a pretty pinentry window...
>
> That said, switching to pinentry-tty does not solve the problem with pam.
> In fact I can see pinentry-tty working with pass and failing with sudo 
> in the same terminal session:
>
> $ pass perso/ameli.fr
> Please unlock the card
> Number: 10 955 601
> Holder: Franck Routier
> PIN:
> *************************
> $ sudo su
> Insert authentication card for user `franck'
> Trying authentication as user `franck'...
> [sudo] password for franck:
>
> Franck
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251112/3beb73eb/attachment-0001.html>

From kloecker at kde.org  Wed Nov 12 22:32:27 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Wed, 12 Nov 2025 22:32:27 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
 <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org>
Message-ID: <2762673.lGaqSPkdTl@daneel>

On Mittwoch, 12. November 2025 22:07:15 Mitteleurop?ische Normalzeit Franck 
Routier (Personnel) via Gnupg-users wrote:
> I managed to get some logs from gpg-agent. No sure how to interpret this
> however. No obvious error I can spot (but I don't know what to look for):
> 
[...]
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet
> you, process 16072
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- SCD GETINFO socket_name
> 2025-11-12 22:00:31 gpg-agent[16056] no running /usr/lib/gnupg/scdaemon
> daemon - starting it
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: agent_flush_cache (pincache only)
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK GNU Privacy
> Guard's Smartcard server ready
> 2025-11-12 22:00:31 gpg-agent[16056] first connection to daemon
> /usr/lib/gnupg/scdaemon established
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
> /run/user/1000/gnupg/S.scdaemon
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: additional connections at
> '/run/user/1000/gnupg/S.scdaemon'
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> OPTION event-signal=12
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
> /run/user/1000/gnupg/S.scdaemon
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> D
> /run/user/1000/gnupg/S.scdaemon
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- BYE
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK closing connection
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> RESTART
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 
> Trying to sudo at 22:00:31
> Before is just normal gpg-agent start (?).
> 
> Any idea ?

What we see above for chan_12 looks like the communication between libpam-
poldi (?) and gpg-agent. libpam-poldi asks scdaemon via gpg-agent for its 
socket (SCD GETINFO socket_name). Then for chan_13 we see how gpg-agent talks 
to scdaemon (that it first started) to ask scdaemon for its socket (GETINFO 
socket_name) which replies with /run/user/1000/gnupg/S.scdaemon and OK. I 
don't understand the "additional connections ..." message and the other chat 
on chan_13. In any case, on chan_12 gpg-agent sends the socket back to libpam-
poldi which then ends the connection with BYE.

My guess is that libpam-poldi asked gpg-agent for the socket of scdaemon so 
that it can subsequently talk to scdaemon directly. You might want to add 
'debug ipc' to scdaemon.conf to capture the communication of scdaemon with 
other processes.

Regards,
Ingo

> Le 07/11/2025 ? 18:36, Franck Routier (Personnel) via Gnupg-users a ?crit :
> >> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
> >> instead. Also set log-file so that the logs don't end up in some random
> >> place (or nowhere).
> > 
> > Yes typo. I removed it alltogether for now:
> > 
> > pinentry-program /usr/bin/pinentry-qt
> > enable-ssh-support
> > ttyname $GPG_TTY
> > default-cache-ttl 60
> > max-cache-ttl 120
> > 
> >> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to
> >> start because there's no window manager running. Try using
> >> pinentry-curses or pinentry-tty instead of pinentry-qt if you are anyway
> >> using the terminal.> 
> > In fact gpg-agent seems to be able to call pinentry-qt, as when I use
> > pass or browserpass, it works and I get a pretty pinentry window...
> > 
> > That said, switching to pinentry-tty does not solve the problem with pam.
> > In fact I can see pinentry-tty working with pass and failing with sudo
> > in the same terminal session:
> > 
> > $ pass perso/ameli.fr
> > Please unlock the card
> > Number: 10 955 601
> > Holder: Franck Routier
> > PIN:
> > *************************
> > $ sudo su
> > Insert authentication card for user `franck'
> > Trying authentication as user `franck'...
> > [sudo] password for franck:
> > 
> > Franck
> > 
> > _______________________________________________
> > Gnupg-users mailing list
> > Gnupg-users at gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gnupg-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251112/0c789265/attachment.sig>

From me at chandlerdavis.cc  Thu Nov 13 01:32:33 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Thu, 13 Nov 2025 00:32:33 +0000
Subject: Bug Tracker Account Request
Message-ID: <pn8rz8Nvci4F1sakCcy7p-6CQYCtBO0TEMCj2xoUC3fgicc-g4XavEJ0d_2g5UvIA2EE8KtpUFVrBKL24ncMfPmisRWPTvniBD-Djh6JDoc=@chandlerdavis.cc>

Hey folks,

I believe I've found a minor issue in the gpgme documentation, and wanted to open an issue on the bug tracker and submit a patch. I believe that's the correct place for it, but let me know if I should discuss here / in the development list / elsewhere.

If I were to be blessed with an account for the bug tracker, my handle is "bitcrshr", name is "Chandler Davis", and email is "me at chandlerdavis.cc".

Thanks, and have a good one!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/53b92b5e/attachment.sig>

From jcb62281 at gmail.com  Thu Nov 13 05:27:56 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 12 Nov 2025 22:27:56 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
Message-ID: <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>

On 11/12/25 12:17, Loup Vaillant wrote:
> [...]
>
>> LibrePGP introduces no changes from RFC-4880 with respect to this. So
>> in the world of GnuPG the new packet format is only "RECOMMENDED" for
>> cases where interoperability is not an issue.
>
> Let's be honest, interoperability has not ben an issues for likely 
> more than a decade.? Given that, and the legal argument above, in 
> GnuPG word you SHOULD output the new format, and you SHOULD NOT output 
> the old format.
>
> And now the real funny part.? The latest version of LibrePGP states:
>
> "" If interoperability is not an issue, the new packet format
> "" is RECOMMENDED
>
> Same as RFC 4880.? So not only GnuPG is in clear violation of the 
> legal equivalent of a "SHOULD NOT" from a 18 year old RFC, the 
> recommendation (and associated violation) persists even through the 
> very draft it promotes.

Ah, but that is conditional on interoperability not being an issue.

I propose a more nuanced solution:? output the legacy format iff the 
cryptographic primitives used are compatible with the ancient PGP 
implementations that only understand the legacy format, otherwise output 
the new format since receivers that lack support for the new format 
would not be able to use the message anyway because they also lack the 
required algorithm support.

Note that this could potentially mean supporting the legacy format 
indefinitely for RSA signatures, at least with whatever digests the 
ancient implementations supported.


-- Jacob



From loup at loup-vaillant.fr  Thu Nov 13 08:22:39 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Thu, 13 Nov 2025 08:22:39 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
Message-ID: <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>

>> Let's be honest, interoperability has not ben an issues for likely 
>> more than a decade.?[...]
> 
> Ah, but that is conditional on interoperability not being an issue.

As I?said, it's not.  Hasn't been for many years.

Remember, the ability to read the new framing became at least a SHOULD 
27 years ago.  18 years ago, the new packet types made it a MUST.

Can anyone name *one* OpenPGP implementation in notable use today that 
still cannot understand the new framing?  There isn't, right?


> [...] the ancient PGP 
> implementations that only understand the legacy format,

But are these ancient implementations still being used today?
Where?  By who?

Seriously, at this point it's not on me to prove no one such 
implementation still exist.  It's on you to show that it's still being 
used.  So far no one did.  Not a single example.  If there was one, then 
one of you would have answered my first query with "this reader still 
doesn't understand the new framing, we have to still use the old to be 
compatible with it".

Loup



From kloecker at kde.org  Thu Nov 13 08:32:01 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 13 Nov 2025 08:32:01 +0100
Subject: Bug Tracker Account Request
In-Reply-To: <pn8rz8Nvci4F1sakCcy7p-6CQYCtBO0TEMCj2xoUC3fgicc-g4XavEJ0d_2g5UvIA2EE8KtpUFVrBKL24ncMfPmisRWPTvniBD-Djh6JDoc=@chandlerdavis.cc>
References: <pn8rz8Nvci4F1sakCcy7p-6CQYCtBO0TEMCj2xoUC3fgicc-g4XavEJ0d_2g5UvIA2EE8KtpUFVrBKL24ncMfPmisRWPTvniBD-Djh6JDoc=@chandlerdavis.cc>
Message-ID: <5002581.OV4Wx5bFTl@daneel>

Hi,

On Donnerstag, 13. November 2025 01:32:33 Mitteleurop?ische Normalzeit 
Chandler Davis via Gnupg-users wrote:
> I believe I've found a minor issue in the gpgme documentation, and wanted to
> open an issue on the bug tracker and submit a patch. I believe that's the
> correct place for it, but let me know if I should discuss here / in the
> development list / elsewhere.

We prefer patches to be sent to the gnupg-devel mailing list. See the file 
doc/HACKING in gpgme for details.

> If I were to be blessed with an account for the bug tracker, my handle is
> "bitcrshr", name is "Chandler Davis", and email is "me at chandlerdavis.cc".

Werner will take care of this.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/15a62347/attachment.sig>

From alci at mecadu.org  Thu Nov 13 11:03:34 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Thu, 13 Nov 2025 11:03:34 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <2762673.lGaqSPkdTl@daneel>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
 <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org> <2762673.lGaqSPkdTl@daneel>
Message-ID: <ccf2e162-2b33-4bd0-8be8-9a87df98e33a@mecadu.org>

Thanks for helping me interpret this logs !
So I activited logs one component after the other, and finally the 
problem was simply in libpam-poldi configuration...
The opening parenthesis (before "public-key" keyword) was missing in the 
key file :

public-key
(rsa etc...

Well... embarrassing :-)
But it least I progressed in the understanding of this stack !

Thanks again,
Franck

Le 12/11/2025 ? 22:32, Ingo Kl?cker a ?crit?:
> On Mittwoch, 12. November 2025 22:07:15 Mitteleurop?ische Normalzeit Franck
> Routier (Personnel) via Gnupg-users wrote:
>> I managed to get some logs from gpg-agent. No sure how to interpret this
>> however. No obvious error I can spot (but I don't know what to look for):
>>
> [...]
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet
>> you, process 16072
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- SCD GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] no running /usr/lib/gnupg/scdaemon
>> daemon - starting it
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: agent_flush_cache (pincache only)
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK GNU Privacy
>> Guard's Smartcard server ready
>> 2025-11-12 22:00:31 gpg-agent[16056] first connection to daemon
>> /usr/lib/gnupg/scdaemon established
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: additional connections at
>> '/run/user/1000/gnupg/S.scdaemon'
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> OPTION event-signal=12
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- BYE
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK closing connection
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> RESTART
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>>
>> Trying to sudo at 22:00:31
>> Before is just normal gpg-agent start (?).
>>
>> Any idea ?
> What we see above for chan_12 looks like the communication between libpam-
> poldi (?) and gpg-agent. libpam-poldi asks scdaemon via gpg-agent for its
> socket (SCD GETINFO socket_name). Then for chan_13 we see how gpg-agent talks
> to scdaemon (that it first started) to ask scdaemon for its socket (GETINFO
> socket_name) which replies with /run/user/1000/gnupg/S.scdaemon and OK. I
> don't understand the "additional connections ..." message and the other chat
> on chan_13. In any case, on chan_12 gpg-agent sends the socket back to libpam-
> poldi which then ends the connection with BYE.
>
> My guess is that libpam-poldi asked gpg-agent for the socket of scdaemon so
> that it can subsequently talk to scdaemon directly. You might want to add
> 'debug ipc' to scdaemon.conf to capture the communication of scdaemon with
> other processes.
>
> Regards,
> Ingo
>
>> Le 07/11/2025 ? 18:36, Franck Routier (Personnel) via Gnupg-users a ?crit :
>>>> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
>>>> instead. Also set log-file so that the logs don't end up in some random
>>>> place (or nowhere).
>>> Yes typo. I removed it alltogether for now:
>>>
>>> pinentry-program /usr/bin/pinentry-qt
>>> enable-ssh-support
>>> ttyname $GPG_TTY
>>> default-cache-ttl 60
>>> max-cache-ttl 120
>>>
>>>> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to
>>>> start because there's no window manager running. Try using
>>>> pinentry-curses or pinentry-tty instead of pinentry-qt if you are anyway
>>>> using the terminal.>
>>> In fact gpg-agent seems to be able to call pinentry-qt, as when I use
>>> pass or browserpass, it works and I get a pretty pinentry window...
>>>
>>> That said, switching to pinentry-tty does not solve the problem with pam.
>>> In fact I can see pinentry-tty working with pass and failing with sudo
>>> in the same terminal session:
>>>
>>> $ pass perso/ameli.fr
>>> Please unlock the card
>>> Number: 10 955 601
>>> Holder: Franck Routier
>>> PIN:
>>> *************************
>>> $ sudo su
>>> Insert authentication card for user `franck'
>>> Trying authentication as user `franck'...
>>> [sudo] password for franck:
>>>
>>> Franck
>>>
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/ca0f6712/attachment-0001.html>

From roam at ringlet.net  Thu Nov 13 10:23:54 2025
From: roam at ringlet.net (Peter Pentchev)
Date: Thu, 13 Nov 2025 11:23:54 +0200
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
Message-ID: <aRWjqr130IkWhbvx@straylight.m.ringlet.net>

On Thu, Nov 13, 2025 at 08:22:39AM +0100, Loup Vaillant wrote:
> > > Let's be honest, interoperability has not ben an issues for likely
> > > more than a decade.?[...]
> > 
> > Ah, but that is conditional on interoperability not being an issue.
> 
> As I?said, it's not.  Hasn't been for many years.
> 
> Remember, the ability to read the new framing became at least a SHOULD 27
> years ago.  18 years ago, the new packet types made it a MUST.
> 
> Can anyone name *one* OpenPGP implementation in notable use today that still
> cannot understand the new framing?  There isn't, right?

You'd be surprised what software runs on internal corporate systems that
were set up literally thirty years ago and that were maybe, *maybe*,
upgraded twice since then, with extremely careful testing and
extremely conservative upgrade paths. You may be surprised at what some
tools written last year may need to produce so that some of those
installations can consume it.

So here we come to what I think is the most important point missed by
some of the people in this thread: TL;DR: gnupg has the `--rfc2440`,
`--rfc4880`, and `--rfc4880bis` options; use them as appropriate.

Somewhat more verbose TL;DR: for various tools that support several
output formats, it is actually good practice to specify the exact format
that you want, even if you think it really should be the default or
if it is the current default.

The longer version:
- standards change with time
- implementations change their defaults with time
- these changed defaults may cause problems down the road; see e.g. how
  various Linux distributions (I know for certain about Fedora and Debian,
  there may be others) had a bit of work to do recently when GCC 15
  switched to a new C language standard by default (if the -std option
  was not specified!), and it started failing to compile programs that
  used something that, in my personal opinion, was obsolete twenty years
  ago, but there was still source code like that out there
- yes, it would be nice if stuff could "just work" without additional
  options
- no, it is not possible in the real world
- so, always specify as many standards-compliance and output-format
  options as you can think of; yes, this makes some command-lines
  longer that they might possibly need to be to work today, you will
  be glad you did in three years (or fifteen years) time

And the longer version, *specifically* pertaining to GnuPG:
- AFAIK, GnuPG has always had interoperability in mind (my personal
  opinion about the recent, um, differences in opinion within
  the OpenPGP working group is irrelevant here)
- interoperability includes "this version of GnuPG should not change
  its behavior when invoked by ancient tooling that aims to produce
  output to be consumed by even more ancient tooling"
- so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
  the least common denominator

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at debian.org peter at morpheusly.com
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/62f61172/attachment.sig>

From andrewg at andrewg.com  Thu Nov 13 12:56:32 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 13 Nov 2025 11:56:32 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
Message-ID: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>

Hi, Peter.

On 13/11/2025 09:23, Peter Pentchev wrote:
> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>    the least common denominator

This is not how GnuPG's compliance options currently work though; 
non-default compliance options cause GnuPG to comply with *earlier* 
specs, to improve backwards compatibility at the expense of 
cryptographic strength.

It would be reasonable, and still solidly defensive, for GnuPG to emit 
the old packet framing iff a compliance option such as --rfc2440 was 
supplied, or if the key being encrypted to advertised old defaults, or 
if the key material uses an algorithm or packet version that pre-dates 
rfc4880. But it serves no purpose to continue to use the old format with 
modern cryptography that legacy code can't understand anyway.

A



From jb-gnumlists at wisemo.com  Thu Nov 13 13:35:02 2025
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Thu, 13 Nov 2025 13:35:02 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
Message-ID: <2e00cf99-ee48-1934-1437-7d1bb02cb94f@wisemo.com>

On 13/11/2025 12:56, Andrew Gallagher via Gnupg-users wrote:
> Hi, Peter.
>
> On 13/11/2025 09:23, Peter Pentchev wrote:
>> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>> ?? the least common denominator
>
> This is not how GnuPG's compliance options currently work though; 
> non-default compliance options cause GnuPG to comply with *earlier* 
> specs, to improve backwards compatibility at the expense of 
> cryptographic strength.
>
> It would be reasonable, and still solidly defensive, for GnuPG to emit 
> the old packet framing iff a compliance option such as --rfc2440 was 
> supplied, or if the key being encrypted to advertised old defaults, or 
> if the key material uses an algorithm or packet version that pre-dates 
> rfc4880. But it serves no purpose to continue to use the old format 
> with modern cryptography that legacy code can't understand anyway.
>
The important open questions are:

1. Since what version and year does gnupg accept the new framing of 
packets that it can also accept with old framing?? This controls when 
senders will be able to use the new framing by default.

2. Since what year do all then-and-later commonly distributed OpenPGP 
implementations accept the new framing of packets that gnupg can send 
with old framing? This controls when gnupg will be able to send the new 
framing by default.

3. If either of the above questions are answered by "recent" (for 
enterprise-frozen values of "recent"), should gnupg add options to 
specify that the recipient follows a newer spec, such as rfc-4880, and 
can thus decode the new framing of old packet types and can also handle 
the new packet types introduced by that "newer spec"?? Such an option 
might be named --rfc4880plus or --no-rfc2440 (meaning don't implicitly 
trigger option --rfc2440, but be careful not to create a contradictory 
corner case where --rfc2440 is not the exact negative of --no-rfc2440).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From ametzler at bebt.de  Thu Nov 13 12:50:11 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 13 Nov 2025 12:50:11 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
Message-ID: <aRXF89gJIBuY-Wtq@argenau.bebt.de>

On 2025-11-13 Peter Pentchev <roam at ringlet.net> wrote:
[...]
> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>   the least common denominator

Hello,
Is this really true in this strict sense? Afaik GnuPG has not been
emitting rfc-2440 (or even rfc-4880) compliant packets *by* *default*
for ages.

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 andrewg at andrewg.com  Thu Nov 13 15:42:37 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 13 Nov 2025 14:42:37 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <2e00cf99-ee48-1934-1437-7d1bb02cb94f@wisemo.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
 <2e00cf99-ee48-1934-1437-7d1bb02cb94f@wisemo.com>
Message-ID: <f9d672a5-ca3b-4db6-b476-cf19820e905d@andrewg.com>

On 13/11/2025 12:35, Jakob Bohm via Gnupg-users wrote:
> 
> 1. Since what version and year does gnupg accept the new framing of 
> packets that it can also accept with old framing?? This controls when 
> senders will be able to use the new framing by default.

I believe gnupg has always supported the new framing - it was defined in 
the first OpenPGP spec (RFC2440) in 1998, and gnupg 1.0 was released in 
September 1999.

> 2. Since what year do all then-and-later commonly distributed OpenPGP 
> implementations accept the new framing of packets that gnupg can send 
> with old framing? This controls when gnupg will be able to send the new 
> framing by default.

AIUI the only code that cannot understand the new framing is in 
pre-OpenPGP versions of commercial PGP. PGP5 had partial support for the 
new framing, but note that PGP5 was incomplete in many other areas; for 
example it only had partial support for V4 signatures and its OPS 
handling was buggy. See Section 14 of RFC2440 for a list of caveats:

https://datatracker.ietf.org/doc/html/rfc2440#section-14

Basically, if you are still using a version of commercial PGP that can't 
handle modern packet framing, that's the *least* of your problems.

> 3. If either of the above questions are answered by "recent" (for 
> enterprise-frozen values of "recent"), should gnupg add options to 
> specify that the recipient follows a newer spec, such as rfc-4880, and 
> can thus decode the new framing of old packet types and can also handle 
> the new packet types introduced by that "newer spec"?? Such an option 
> might be named --rfc4880plus or --no-rfc2440 (meaning don't implicitly 
> trigger option --rfc2440, but be careful not to create a contradictory 
> corner case where --rfc2440 is not the exact negative of --no-rfc2440).

Note that it was RFC2440 (1998) that specified modern packet framing 
even for existing features; RFC4880 was the first spec that introduced 
new features with a *requirement* for the modern framing. All 
OpenPGP-compatible software SHOULD therefore accept the modern framing.

A



From wk at gnupg.org  Thu Nov 13 21:17:20 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Nov 2025 21:17:20 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Thu, 13 Nov 2025 11:56:32
 +0000")
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
Message-ID: <875xbdsn5b.fsf@jacob.g10code.de>

Hi!

Some background on why we have these compliance options: Back then when
we developed rfc2440, and later rfc4880, it was useful to have them to
test the changes we implemented in PGP and GnuPG.  The --pgp options
were also useful in the early days for an easy migration path from pgp2
to gpg; in particular in MUAs like Pine and such.

These days they are mostly useless because everyone demands MDC and it
is virtually impossible to keep the compliance options exactly up to the
respective specification.  But people are using them and thus it is hard
to remove the option.

The new generalized option --compliance is now used to restrict he GnuPG
behaviour to certain compliance requirements.  Currently only for the
German/EU/NATO compliance but maybe later also for FIPS.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/988f5fe9/attachment-0001.sig>

From jcb62281 at gmail.com  Fri Nov 14 02:29:52 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 13 Nov 2025 19:29:52 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
Message-ID: <43a61e1c-7564-4ee9-8b1e-8dba8f65c5bc@gmail.com>

On 11/13/25 05:56, Andrew Gallagher via Gnupg-users wrote:
> Hi, Peter.
>
> On 13/11/2025 09:23, Peter Pentchev wrote:
>> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>> ?? the least common denominator
>
> This is not how GnuPG's compliance options currently work though; 
> non-default compliance options cause GnuPG to comply with *earlier* 
> specs, to improve backwards compatibility at the expense of 
> cryptographic strength.
>
> It would be reasonable, and still solidly defensive, for GnuPG to emit 
> the old packet framing iff a compliance option such as --rfc2440 was 
> supplied, or if the key being encrypted to advertised old defaults, or 
> if the key material uses an algorithm or packet version that pre-dates 
> rfc4880. But it serves no purpose to continue to use the old format 
> with modern cryptography that legacy code can't understand anyway.

This is what I am suggesting:? when using ciphers that were not 
available in the ancient implementations that do not understand the new 
format, use the new format because interoperability is broken (at the 
user's command) anyway.

I also noted that it may be possible for some modern signatures to be 
usable in those ancient implementations.? If that is so, this should 
*not* be gratuitously broken unless we find some serious cryptographic 
flaw in that format.

If there *is* such a flaw, GnuPG could still have an option to generate 
the old form, in case someone out there actually has a workflow that 
depends on it, but should emit a BIG SCARY WARNING explaining the 
problem, both when generating a weak signature and especially upon 
verifying one!


-- Jacob