From damien at cassou.me  Mon Apr  1 16:36:58 2024
From: damien at cassou.me (Damien Cassou)
Date: Mon, 01 Apr 2024 16:36:58 +0200
Subject: Get the private portion of subkeys
In-Reply-To: <c6069e4d-ff06-49f0-bf5c-f09a6604f0a6@kulbartsch.de>
References: <87y1a2stow.fsf@cassou.me> <87sf07wv11.fsf@cassou.me>
 <c6069e4d-ff06-49f0-bf5c-f09a6604f0a6@kulbartsch.de>
Message-ID: <87msqdw3n9.fsf@cassou.me>

Hi Alexander,

thank you for giving me background information. It really helped, this
sentenc was particularly helpful:

Alexander Kulbartsch <alexander at kulbartsch.de> writes:
> When you call "gpg --list-packets sec.asc"
> I assume you see something like "gnu-divert-to-card, ..." under your 
> subkeys

When I export today, I see "gnu-divert-to-card" on my subkeys. But if I
check on an old backup, I don't see this. So I conclude that my backup
contains the private subkeys (good news!).

I just found out that if I don't see the subkeys after importing the
backup it's just because they are expired: "show-unusable-subkeys"
reveal them and everything is good.

Thank you so much.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill


From wk at gnupg.org  Tue Apr  2 12:58:29 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 02 Apr 2024 12:58:29 +0200
Subject: x488 vs all other : keyid flip
In-Reply-To: <CEDB4B98-F6F7-4B1C-9FC2-26E5C317150F@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Fri, 29 Mar 2024 13:00:38
 +0000")
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CEDB4B98-F6F7-4B1C-9FC2-26E5C317150F@andrewg.com>
Message-ID: <87sf04c9pm.fsf@jacob.g10code.de>

On Fri, 29 Mar 2024 13:00, Andrew Gallagher said:

> V5 subkeys of v4 primary keys would appear to introduce a novel
> failure mode. It should be noted that in crypto-refresh, adding a

Nope.  A v5 key has nothing to do a v4 signature and having different
algorithm on the primary key and the subkeys is really common and
allowed us once to slowly introduce RSA and ECC without any major
problems.  This is why we will do the same for PQC encryption.

To repeat: The *v5 key format* merely adds a four-octet count of the
public key material to the v4 format.  There are also minor chnages for
the (not so import) secret key exchange format.  And - more important -
it defines that the fingerprint is now done using SHA-256.

The latter is the whole point why we once decided to use add a v5 format
- to make it clear tha a SHA-256 fingerprint is used.  All in all a
really minor changes and not worth a long debate.

The crypto-refresh has a lot of things which breaks OpenPGP and that
draft, or soon to be RFC, does not care about backward compatibility.
They should not have used the term OpenPGP for this.


Salam-Shalom,

   Werner

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

From andrewg at andrewg.com  Tue Apr  2 13:39:59 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 2 Apr 2024 12:39:59 +0100
Subject: x488 vs all other : keyid flip
In-Reply-To: <87sf04c9pm.fsf@jacob.g10code.de>
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CEDB4B98-F6F7-4B1C-9FC2-26E5C317150F@andrewg.com>
 <87sf04c9pm.fsf@jacob.g10code.de>
Message-ID: <99950276-1E2F-4538-B192-FE0D0A7ABA4C@andrewg.com>

On 2 Apr 2024, at 11:58, Werner Koch <wk at gnupg.org> wrote:
> 
> On Fri, 29 Mar 2024 13:00, Andrew Gallagher said:
> 
>> V5 subkeys of v4 primary keys would appear to introduce a novel
>> failure mode. It should be noted that in crypto-refresh, adding a
> 
> Nope.

Are you saying that this is *not* a novel failure mode? Because we?ve never before had a key of one version number with a subkey of a different version number (since v3 did not support subkeys). Have you interop-tested this with other implementations? Besides RNP? What were the results?

> A v5 key has nothing to do a v4 signature and having different
> algorithm on the primary key and the subkeys is really common and
> allowed us once to slowly introduce RSA and ECC without any major
> problems.  This is why we will do the same for PQC encryption.

Yes, but a subkey of a different *algorithm* is anticipated by the spec and should work (in principle). A subkey of a different *version* is a different matter. Or is it specified somewhere that I have overlooked?

> All in all a really minor changes and not worth a long debate.

It may be a minor change, but if it breaks interop it is still worth debating the consequences.

> The crypto-refresh has a lot of things which breaks OpenPGP and that
> draft, or soon to be RFC, does not care about backward compatibility.
> They should not have used the term OpenPGP for this.

You keep repeating these talking points, but they are simply not true.

1. crypto-refresh defines a *different* set of extensions to OpenPGP than GnuPG supports, but these do not ?break? OpenPGP.
2. crypto-refresh has bumped all of its packet version numbers specifically to avoid compatibility issues. Just because the WG have a different opinion does not mean that they don?t care.
3. The term ?OpenPGP? does not belong to GnuPG.

And I notice that you have not addressed the most important point in my last email:

> how should an implementation behave if it wants to support both the librepgp and crypto-refresh specs?

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240402/8fd5683c/attachment.sig>

From marcio.barbado at gmail.com  Tue Apr  2 12:46:48 2024
From: marcio.barbado at gmail.com (Marcio Barbado, Jr.)
Date: Tue, 2 Apr 2024 07:46:48 -0300
Subject: [OFF-TOPIC] gpg-agent, sshd and/or SELinux (was Re: Get the private
 portion of subkeys)
Message-ID: <CA+0jWE2ZQovXmdKo-7=8sBjJoa1co0xraLMgQa__ZnUN9w8YDg@mail.gmail.com>

Hi, Werner, all.

Please let me take this opportunity to ask you for trustable documentation,
or any other resource, which could help interested users like myself in
providing the gpg-agent with ssh client and daemon errands, on both fresh
and not-so-fresh OS installs. Please consider SELinux contexts if possible.

Regards,

Marcio Barbado, Jr.


On Thu, 28 Mar 2024 at 07:01 Werner Koch via Gnupg-users <
gnupg-users at gnupg.org> wrote:

> On Thu, 28 Mar 2024 08:26, Damien Cassou said:
>
> > Is that a problem? Am I missing something important? It seems this
> > causes me the troubles mentioned at [1].
>
> Your subkeys are all stored on a smartcard.  The primary key is online.
> This is as intended.  If you remove the the primary private key
> (<keygrip>.key)  You should see a '#' mark for the primary key.
>
> > My private master key is symlinked in ~/.gnupg/private-keys-v1.d:
>
> That is intended to work but has not been thoroughly tested.
>
> > [1] https://github.com/pinpox/pgp2ssh/issues/6
>
> That reminds me that we have a function export_secret_ssh_key but it
> will always fail with a not-implemented error ;-).  Noone of the core
> hackers felt a need for it.  For example I have not used anything else
> than gpg-agent based ssh access since 2005.
>
>
> Shalom-Salam,
>
>    Werner
>
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
> _______________________________________________
> 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/20240402/163d5870/attachment.html>

From wk at gnupg.org  Tue Apr  2 16:24:06 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 02 Apr 2024 16:24:06 +0200
Subject: x488 vs all other : keyid flip
In-Reply-To: <99950276-1E2F-4538-B192-FE0D0A7ABA4C@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Tue, 2 Apr 2024 12:39:59
 +0100")
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CEDB4B98-F6F7-4B1C-9FC2-26E5C317150F@andrewg.com>
 <87sf04c9pm.fsf@jacob.g10code.de>
 <99950276-1E2F-4538-B192-FE0D0A7ABA4C@andrewg.com>
Message-ID: <87le5vderd.fsf@jacob.g10code.de>

On Tue,  2 Apr 2024 12:39, Andrew Gallagher said:

> Are you saying that this is *not* a novel failure mode? Because we?ve

No.  We had v2, v3 and v4 keyes in all kind of combinations in the past
(even as part of subkeys) and back then the two OpenPGP implementations
had no problems with that.  The whole point of packet version numbers is
to be able to ignore such packets.

> different version number (since v3 did not support subkeys). Have you
> interop-tested this with other implementations? Besides RNP? What were

If there are new implementaions they should check interop with the
de-facto standards which are PGP, GnuPG and later RNP.  There is also
the widely used BouncyCastle library and we have not seen problems with
it except when ppl ignore features of these library.

> 3. The term ?OpenPGP? does not belong to GnuPG.

But let me remark for the records that GnuPG has been the entity which
always used the term /OpenPGP/ instead of /PGP/ or - as many Linux
people did - the term /GPG/ keys.  Thus we, and in particular me,
stressed that this is the OpenPGP standard which GnuPG implements,
popularized, took care, and pride of.  Sure it does no "belong" to us or
anyone - it is term without having a trademark.  OTOH, tehre is a
respoisbility here to keep the repudiation of that standard high - this
is what the /current OpenPGP WG participants/ don't a do anymore since
fall 2021.

> And I notice that you have not addressed the most important point in
> my last email:
>
>> how should an implementation behave if it wants to support both the
>> librepgp and crypto-refresh specs?

That is up to those implementaions who want to destroy a solid standard.
Why should I help them?  This is a GnuPG mailing list and you are
welcome to discuss technical details of stuff relevant to GnuPG and
OpenPGP (up to fall 2021).  Everything else is better addressed to the
crypto-refresh commitee.


Shalom-Salam,

   Werner

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

From andrewg at andrewg.com  Tue Apr  2 19:53:43 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 2 Apr 2024 18:53:43 +0100
Subject: x488 vs all other : keyid flip
In-Reply-To: <87le5vderd.fsf@jacob.g10code.de>
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CEDB4B98-F6F7-4B1C-9FC2-26E5C317150F@andrewg.com>
 <87sf04c9pm.fsf@jacob.g10code.de>
 <99950276-1E2F-4538-B192-FE0D0A7ABA4C@andrewg.com>
 <87le5vderd.fsf@jacob.g10code.de>
Message-ID: <6CDA1432-89BA-4F59-8E24-BE44309703DA@andrewg.com>

On 2 Apr 2024, at 15:24, Werner Koch <wk at gnupg.org> wrote:
> 
> On Tue,  2 Apr 2024 12:39, Andrew Gallagher said:
> 
>> Are you saying that this is *not* a novel failure mode? Because we?ve
> 
> No.  We had v2, v3 and v4 keyes in all kind of combinations in the past
> (even as part of subkeys) and back then the two OpenPGP implementations
> had no problems with that.  The whole point of packet version numbers is
> to be able to ignore such packets.

This intrigued me, so I went back through the SKS dataset and found exactly four (4) v4 primary keys with v3 subkeys. This was quite a technical challenge since no modern software supports them, and gnupg1 doesn?t implement --list-packets :-) But I have to admit they do exist? and rfc4880 technically doesn?t forbid them. Still, I?m sure most people would find their existence as surprising as that of v3 sbinds over v4 subkeys (which are several orders of magnitude more common).

>> different version number (since v3 did not support subkeys). Have you
>> interop-tested this with other implementations? Besides RNP? What were
> 
> If there are new implementaions they should check interop with the
> de-facto standards which are PGP, GnuPG and later RNP.  There is also
> the widely used BouncyCastle library and we have not seen problems with
> it except when ppl ignore features of these library.

BouncyCastle is quite low level, and AFAICT does not enforce much in the way of packet grammar etc., so may not be the best comparison. And surely the entire point of a written specification is to avoid "de-facto standard? reference implementations?

> But let me remark for the records that GnuPG has been the entity which
> always used the term /OpenPGP/ instead of /PGP/ or - as many Linux
> people did - the term /GPG/ keys.  Thus we, and in particular me,
> stressed that this is the OpenPGP standard which GnuPG implements,
> popularized, took care, and pride of.  Sure it does no "belong" to us or
> anyone - it is term without having a trademark.

This is fair, and thank you. Not everyone is so careful.

> OTOH, tehre is a
> respoisbility here to keep the repudiation of that standard high - this
> is what the /current OpenPGP WG participants/ don't a do anymore since
> fall 2021.

Reputation is a matter of publicly expressed opinion, and by far the greatest amount of text declaring that OpenPGP no longer has a good reputation has been written by you. So this is a circular argument.

>>> how should an implementation behave if it wants to support both the
>>> librepgp and crypto-refresh specs?
> 
> That is up to those implementaions who want to destroy a solid standard.
> Why should I help them?

Let us be clear here: you appear to be saying that if I want to update hockeypuck to support both librepgp and crypto-refresh artifacts, I am helping to destroy a solid standard? Or have I misunderstood your position?

> This is a GnuPG mailing list and you are
> welcome to discuss technical details of stuff relevant to GnuPG and
> OpenPGP (up to fall 2021).  Everything else is better addressed to the
> crypto-refresh commitee.

I will bring this to the WG, with your comments.

Thanks,
A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240402/8e1ce667/attachment-0001.sig>

From wk at gnupg.org  Wed Apr  3 11:32:06 2024
From: wk at gnupg.org (Werner Koch)
Date: Wed, 03 Apr 2024 11:32:06 +0200
Subject: x488 vs all other : keyid flip
In-Reply-To: <6CDA1432-89BA-4F59-8E24-BE44309703DA@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Tue, 2 Apr 2024 18:53:43
 +0100")
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CEDB4B98-F6F7-4B1C-9FC2-26E5C317150F@andrewg.com>
 <87sf04c9pm.fsf@jacob.g10code.de>
 <99950276-1E2F-4538-B192-FE0D0A7ABA4C@andrewg.com>
 <87le5vderd.fsf@jacob.g10code.de>
 <6CDA1432-89BA-4F59-8E24-BE44309703DA@andrewg.com>
Message-ID: <8734s2dc6h.fsf@jacob.g10code.de>

On Tue,  2 Apr 2024 18:53, Andrew Gallagher said:

> technical challenge since no modern software supports them, and gnupg1
> doesn?t implement --list-packets :-) But I have to admit they do

Sure it has the --list-packets command.  This command dates back to the
very first release.

>> But let me remark for the records that GnuPG has been the entity which
>> always used the term /OpenPGP/ instead of /PGP/ or - as many Linux
>> people did - the term /GPG/ keys.  Thus we, and in particular me,
>> stressed that this is the OpenPGP standard which GnuPG implements,
>> popularized, took care, and pride of.  Sure it does no "belong" to us or
>> anyone - it is term without having a trademark.
>
> This is fair, and thank you. Not everyone is so careful.

Thanks.

> greatest amount of text declaring that OpenPGP no longer has a good
> reputation has been written by you. So this is a circular argument.

Well, I was obviously not caution enough with my statement.  What I mean
is that the current way the IETF WG works has a high potential to just
this.  At least an article in the very popular c't magazin might have
such an effect.  Maybe I should not overvalue such articles and postings
on mailing lists.


> Let us be clear here: you appear to be saying that if I want to update
> hockeypuck to support both librepgp and crypto-refresh artifacts, I am
> helping to destroy a solid standard? Or have I misunderstood your

Given that Ubuntu's Hockeypuck is the default keyserver for GnuPG for
most people (i.e. on Windows) it would be good if it continues to
support at least the default keys.  Whether X448 or the forthcominng
Kyber subkeys are relevant for keyservers is a different questions.


FWIW, I have severe doubts on the usefulness of public keyservers given
the DoS problems for users and the wrong - but real - assumption of
users that keys from a keyserver are trustworthy.  Sending keys with an
initial mail is a better way; keyserver should be used only to provide
subkey updates and revocations - no search by user id.

> I will bring this to the WG, with your comments.

I don't care about the IETF OpenPGP WG^Committee anymore.


Shalom-Salam,

   Werner

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

From andrewg at andrewg.com  Wed Apr  3 12:51:11 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 3 Apr 2024 11:51:11 +0100
Subject: x488 vs all other : keyid flip
In-Reply-To: <8734s2dc6h.fsf@jacob.g10code.de>
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CEDB4B98-F6F7-4B1C-9FC2-26E5C317150F@andrewg.com>
 <87sf04c9pm.fsf@jacob.g10code.de>
 <99950276-1E2F-4538-B192-FE0D0A7ABA4C@andrewg.com>
 <87le5vderd.fsf@jacob.g10code.de>
 <6CDA1432-89BA-4F59-8E24-BE44309703DA@andrewg.com>
 <8734s2dc6h.fsf@jacob.g10code.de>
Message-ID: <2AC9B51B-9B0C-475F-8949-3C6F31279479@andrewg.com>

On 3 Apr 2024, at 10:32, Werner Koch <wk at gnupg.org> wrote:
> 
> On Tue,  2 Apr 2024 18:53, Andrew Gallagher said:
> 
>> technical challenge since no modern software supports them, and gnupg1
>> doesn?t implement --list-packets :-) But I have to admit they do
> 
> Sure it has the --list-packets command.  This command dates back to the
> very first release.

Please ignore my above remark; PEBKAC :facepalm:

> Given that Ubuntu's Hockeypuck is the default keyserver for GnuPG for
> most people (i.e. on Windows) it would be good if it continues to
> support at least the default keys.  Whether X448 or the forthcominng
> Kyber subkeys are relevant for keyservers is a different questions.

I don?t see why a new algorithm would be fundamentally different from existing ones from a keyserver point of view. I would hope that they could be supported seamlessly.

> FWIW, I have severe doubts on the usefulness of public keyservers given
> the DoS problems for users and the wrong - but real - assumption of
> users that keys from a keyserver are trustworthy.  Sending keys with an
> initial mail is a better way; keyserver should be used only to provide
> subkey updates and revocations - no search by user id.

I agree that keyservers are not ideal for userid search - unfortunately we haven?t collectively settled on an alternative yet. Sending initial keys with every email may not be the best solution for large key material such as Kyber, although one could imagine a two-step process such as looking up the signing key of a signed mail via a keyserver. And trust calculations would still be an issue of course; TOFU protects against a passive eavesdropper but doesn?t do much against an active MITM? there?s a lot of work still to be done to improve the UX of mutual verification.

> I don't care about the IETF OpenPGP WG^Committee anymore.

Like it or not, we have to find some way to tolerate each other?s existence. And petty name-calling doesn?t help.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240403/f7be2a0b/attachment.sig>

From tmz at pobox.com  Fri Apr  5 06:04:25 2024
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 5 Apr 2024 00:04:25 -0400
Subject: Agent forwarding issue
Message-ID: <Zg94SYOkSEWPx1Jk@pobox.com>

Hi,

I have been working on setting up agent forwarding?.

One issue which I have not yet found a solution for is that
gpg prints the following to stderr when performing actions
involving the agent:

    gpg: problem with fast path key listing: Forbidden - ignored

Both hosts are running gnupg-2.4.5, based on the Fedora
packages.

With mutt, this causes the signing to pause after entering
the password, as stderr is not empty (I think this is the
reason, anyway).  Can this warning be avoided or silenced
(without directing stderr to /dev/null)?

I can't find much information about it, but it seems like
while this is something useful to note, after seeing it once
it is simply needless.

I believe this is because I've used the extra socket, which
seems like the proper thing to do with agent forwarding, but
perhaps isn't worth the hassle?  I'm not too eager to
forward the regular agent when I can use a more restricted
socket.

? https://wiki.gnupg.org/AgentForwarding

Thanks,

-- 
Todd


From wk at gnupg.org  Fri Apr  5 10:59:51 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 05 Apr 2024 10:59:51 +0200
Subject: Agent forwarding issue
In-Reply-To: <Zg94SYOkSEWPx1Jk@pobox.com> (Todd Zullinger via Gnupg-users's
 message of "Fri, 5 Apr 2024 00:04:25 -0400")
References: <Zg94SYOkSEWPx1Jk@pobox.com>
Message-ID: <87frw0b2wo.fsf@jacob.g10code.de>

Hi!

>     gpg: problem with fast path key listing: Forbidden - ignored

I'll suppress that message in --quiet mode for the next release.

When doing a secret key listing (which happens with -K but also in
--with-colons mode) gpg walks over all public keys and asks the agent
for each key whether a corresponding secret key exists.  With many
secret keys this is quite some overhead and thus gpg first tries to a
get a listing of all secret keys (the keygrips) and later can do a fast
memcmp instead of an IPC call.

If you use the extra-socket certain operations are forbidden so that a
rogue gpg version on the remote site won't be able to change passwords,
export secret keys, or get a listing of all available secret keys.  This
is why you see this diagnostic.


Salam-Shalom,

   Werner



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

From mailport at mikescher.com  Fri Apr  5 16:39:34 2024
From: mailport at mikescher.com (Mike S)
Date: Fri, 5 Apr 2024 16:39:34 +0200
Subject: Is there a way to forcefully re-enable allow_external_password_cache
 under KDE
Message-ID: <e00839aa-ff34-48f5-b007-b85216e0a78b@mikescher.com>

Hello,


is there a way to (re-)enable password storage and retrieval via secret 
service under KDE?

The /allow_external_password_cache/ option was disabled in this ticket:
https://dev.gnupg.org/rPefb6de7fb2c15c1e31349b80fa7c8c1d4694c6cf

But for me it would be useful to override this setting, I'm not using 
KWallet as my secret-service (I'm using KeePassXC), and are not affected 
by the possible deadlock.
I thought about somehow changing the XDG_SESSION_DESKTOP env variable 
that pinentry-gtk-2 sees, but I don't think I can do that (because 
gpg-agent is launching pinentry?)


Currently I downgraded the pinentry version.
My problem is, that I? sign my git commits and now I have to write my 
passphrase every time I commit.
(With version 1.2.1-3 it takes the passphrase out of my KeePass database)


Regards,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240405/7791b55e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xCB9123D02A51C1D3.asc
Type: application/pgp-keys
Size: 7441 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240405/7791b55e/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240405/7791b55e/attachment-0001.sig>

From omcujl92 at duck.com  Fri Apr  5 19:39:21 2024
From: omcujl92 at duck.com (omcujl92 at duck.com)
Date: Fri, 05 Apr 2024 13:39:21 -0400
Subject: Agent forwarding issue
References: <87frw0b2wo.fsf@jacob.g10code.de> <Zg94SYOkSEWPx1Jk@pobox.com>
 <48137178-E30A-40A9-A3F9-AFEABAAE3845.1@smtp-inbound1.duck.com>
Message-ID: <FC1D034C-4642-459E-B8AD-67774A047280.1@smtp-inbound1.duck.com>

In the mean time, you could put something along the lines of:

{CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
listing: Forbidden - ignored$" or something, to keep that output out
of your stderr stream.

If something else unexpected displays, you'll get more issues, but
then you probably want to know if / when / should that happen.

If you add --quiet now, even when the change below happens later, your
script above won't need to change again.

On Fri, Apr 5, 2024 at 5:01?AM Werner Koch via Gnupg-users
<gnupg-users_at_gnupg.org_omcujl92 at duck.com> wrote:
>
> Hi!
>
> >     gpg: problem with fast path key listing: Forbidden - ignored
>
> I'll suppress that message in --quiet mode for the next release.
>
> ...

On Fri, Apr 5, 2024 at 11:24?AM Mike S wrote:
>
> Hello,
>
> is there a way to (re-)enable password storage and retrieval via secret service under KDE?
>
> The allow_external_password_cache option was disabled in this ticket:
> https://dev.gnupg.org/rPefb6de7fb2c15c1e31349b80fa7c8c1d4694c6cf
>
> But for me it would be useful to override this setting, I'm not using KWallet as my secret-service (I'm using KeePassXC), and are not affected by the possible deadlock.
> I thought about somehow changing the XDG_SESSION_DESKTOP env variable that pinentry-gtk-2 sees, but I don't think I can do that (because gpg-agent is launching pinentry?)
>
>
> Currently I downgraded the pinentry version.
> My problem is, that I  sign my git commits and now I have to write my passphrase every time I commit.
> (With version 1.2.1-3 it takes the passphrase out of my KeePass database)



From tmz at pobox.com  Fri Apr  5 19:03:35 2024
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 5 Apr 2024 13:03:35 -0400
Subject: Agent forwarding issue
In-Reply-To: <87frw0b2wo.fsf@jacob.g10code.de>
References: <Zg94SYOkSEWPx1Jk@pobox.com>
 <87frw0b2wo.fsf@jacob.g10code.de>
Message-ID: <ZhAu59Uxo2iquVPx@pobox.com>

Hi Werner,

Werner Koch via Gnupg-users wrote:
>>     gpg: problem with fast path key listing: Forbidden - ignored
> 
> I'll suppress that message in --quiet mode for the next release.

Excellent, thanks!

> When doing a secret key listing (which happens with -K but also in
> --with-colons mode) gpg walks over all public keys and asks the agent
> for each key whether a corresponding secret key exists.  With many
> secret keys this is quite some overhead and thus gpg first tries to a
> get a listing of all secret keys (the keygrips) and later can do a fast
> memcmp instead of an IPC call.

In theory, would this not occur if I cleaned up the keyring
a bit.  I've got ~350 public keys.  Some are likely expired
or no longer useful.

This is without any sort of auto-key-locate enabled -- just
years or accumulating keys.  It doesn't _seem_ like that
many keys to have around...

> If you use the extra-socket certain operations are forbidden so that a
> rogue gpg version on the remote site won't be able to change passwords,
> export secret keys, or get a listing of all available secret keys.  This
> is why you see this diagnostic.

I manage the remote system and consider it reasonably
secure, to the extent any online system can be call
"secure."  It's not much less secure than the system from
which I am forwarding, other than that I'm not physically
beside it.

In such a case, it sounds like it may be reasonable to use
the normal socket?  Until the remote side is updated to
silence this via --quiet, at least.

I saw you pushed the change already, so I applied it to the
build on the remote host and can confirm it does the trick.

Thanks for the quick reply, fix, and additional details!

Cheers,

-- 
Todd


From tmz at pobox.com  Fri Apr  5 22:59:45 2024
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 5 Apr 2024 16:59:45 -0400
Subject: Agent forwarding issue
In-Reply-To: <FC1D034C-4642-459E-B8AD-67774A047280.1@smtp-inbound1.duck.com>
References: <87frw0b2wo.fsf@jacob.g10code.de> <Zg94SYOkSEWPx1Jk@pobox.com>
 <48137178-E30A-40A9-A3F9-AFEABAAE3845.1@smtp-inbound1.duck.com>
 <FC1D034C-4642-459E-B8AD-67774A047280.1@smtp-inbound1.duck.com>
Message-ID: <ZhBmQfAglkbQPzvv@pobox.com>

Bee via Gnupg-users wrote:
> In the mean time, you could put something along the lines of:
> 
> {CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
> listing: Forbidden - ignored$" or something, to keep that output out
> of your stderr stream.

I think there's a downside to that (but I could always be
wrong).  Redirecting stderr to stdout would prevent mutt (or
whatever tool was using being used) from being be able to
display output only from stderr.  That is helpful when the
exit status is 0 but there were warnings, as in this case.

> If something else unexpected displays, you'll get more issues, but
> then you probably want to know if / when / should that happen.
> 
> If you add --quiet now, even when the change below happens later, your
> script above won't need to change again.

Indeed, if Werner weren't so quick, perhaps I would have
considered some sort of adjustment.  Though I try to use the
mutt's contrib/gpg.rc unaltered so I don't have to remember
to merge in fixes they make there.

This does remind me that I should re-evaluate using  gpgme
as the backend.  I don't recall why I disabled that now.  It
may have been for an issue which is long-since resolved. ;)

-- 
Todd


From moses.mason at gmail.com  Mon Apr  8 04:38:17 2024
From: moses.mason at gmail.com (Moses)
Date: Mon, 8 Apr 2024 02:38:17 +0000
Subject: Can not import private key (Not enough space)
Message-ID: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>

Hi,

I've encountered an issue while trying to import a private key into GnuPG,
resulting in an unexpected error message. Below are the details including
the version of GnuPG and the error messages received:

c:\> gpg --version
gpg (GnuPG) 2.4.5
libgcrypt 1.10.3
...


c:\> gpg --import private-keys.asc
gpg: enabled compatibility flags:
[snipped]
gpg: key xxxxxxxxxxxxxxxxxxxxxxx: error sending to agent: Not enough space
gpg: error reading 'private-keys.asc': Not enough space
gpg: import from 'private-keys.asc' failed: Not enough space
gpg: Total number processed: 0
gpg: unchanged: 1
gpg: secret keys read: 1


Interestingly, my disk has ample space available, so this error seems to be
misleading. Furthermore, when attempting to import the same file on an
older GnuPG installation, the import is successful:

c:\> gpg --version
gpg (GnuPG) 2.2.15
libgcrypt 1.8.4
...


c:\> gpg --import private-keys.asc
[snipped]
gpg: Total number processed: 2
gpg: unchanged: 2
gpg: secret keys read: 2
gpg: secret keys unchanged: 2


Could you please provide any advice on this matter?

Thank you in advance for your assistance.

Best regards,

--
M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240408/4871c87e/attachment.html>

From wk at gnupg.org  Mon Apr  8 08:47:55 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 Apr 2024 08:47:55 +0200
Subject: Agent forwarding issue
In-Reply-To: <ZhAu59Uxo2iquVPx@pobox.com> (Todd Zullinger via Gnupg-users's
 message of "Fri, 5 Apr 2024 13:03:35 -0400")
References: <Zg94SYOkSEWPx1Jk@pobox.com> <87frw0b2wo.fsf@jacob.g10code.de>
 <ZhAu59Uxo2iquVPx@pobox.com>
Message-ID: <871q7gbbac.fsf@jacob.g10code.de>

On Fri,  5 Apr 2024 13:03, Todd Zullinger said:

> In such a case, it sounds like it may be reasonable to use
> the normal socket?  Until the remote side is updated to

In fact, I also did this for some time but later came up with 

  CommitDate: Wed Oct 12 11:30:35 2022 +0200

    agent: Introduce attribute "Remote-list" to KEYINFO.
    
    * agent/command.c (do_one_keyinfo): Add arg list_mode.  Check
    attribute Remote-list.
    (cmd_keyinfo): Change semantics to return nothing in restricted list
    mode.

which is

  *** Remote-list
  Allow to list the key with the KEYINFO command from a remote machine
  via the extra socket.  A boolean value is expected; the default is
  "no".  Note that KEYINFO will anyway provide information if the
  keygrip is specified.

Not exactly your problem but somehow related.


Salam-Shalom,

   Werner

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

From wk at gnupg.org  Mon Apr  8 10:02:33 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 Apr 2024 10:02:33 +0200
Subject: Can not import private key (Not enough space)
In-Reply-To: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 (Moses via Gnupg-users's message of "Mon, 8 Apr 2024 02:38:17 +0000")
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
Message-ID: <87v84s9t9i.fsf@jacob.g10code.de>

Hi!

On Mon,  8 Apr 2024 02:38, Moses said:

> gpg: key xxxxxxxxxxxxxxxxxxxxxxx: error sending to agent: Not enough space

That is a ENOMEM which is commonly returned for a failed malloc call.
Could happen at a lot of places.

Try:

  gpg-connect-agent -v

and tehre a command like "getinfo version" to check whether tehre is a
problem with the IPC connection.

  gpgconf -L

also gives important information.

> c:\> gpg --version
> gpg (GnuPG) 2.2.15

That version is pretty old and in terms of IPC ("error sending to
agent") one idfference is that this version uses %APPDATA%\gnupg for the
socket files but modern versions use %LOCALAPPDATA%\gnupg.



Shalom-Salam,

   Werner

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

From moses.mason at gmail.com  Mon Apr  8 13:42:03 2024
From: moses.mason at gmail.com (Moses)
Date: Mon, 8 Apr 2024 11:42:03 +0000
Subject: Can not import private key (Not enough space)
In-Reply-To: <87v84s9t9i.fsf@jacob.g10code.de>
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
Message-ID: <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>

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

Hi,

I tried the command you gave and the results are as follows:

C:\> gpg-connect-agent -v
> getinfo version
D 2.4.5
OK
> gpgconf -L
ERR 67109139 Unknown IPC command <GPG Agent>

I downloaded and installed gpg4win from the official website, and the
signature/sha-256 of the installer matches.

Thanks

- --
M.






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

iQIzBAEBCAAdFiEEtS81xZ6ggCm51urXjBWeIrrYv8gFAmYT14wACgkQjBWeIrrY
v8g/DRAAlgbnQ8wLj9vnJXfEpf9yh+uXRs0A6r6DV0/44ni/AzyqcRzCDKhbHXOO
dSdsA2RKmv+7QB9p3X1c/d09YmAF1qzgiA7zT2EQXKmPoMCJRLWTfeY3wlCqeldd
OCsXIZzE9rQifMn8YjvPe8A//Fc6Y+EomQpYP8qVBWISwpQ7eOdq6uLyLT/nid0O
66CjTdGyRwyni+PKKHNjDjvkJAKm+m5AGK3OEvxSnYWq0qgLNW6xizhZmzShU5lR
Jvbsz66H6VZM+I0kLLB63bdqwDJPy6KcfpOeT62K1U+pQ++mcLI3GpYw76mrnHL2
odTrZ5/yADX+zcKyqEiXLVGjZQMm/PrmNvKoZ0hC6svA3lfryOhgqdVmh6TME5x9
mLnDwawqacxy6Y2YJxUHnMbIPyAI+0L2Kd7GGoGHvjjWBqYsU//5DN3dmPw5W9+C
OfSyzYWgV3fBW29+rcW/mSZS4uZZuArFsYqbqU/mpTiG9rSeeVkEymcSjSH6PEdy
AUQQN4xQDhqQNY7IXLKzD6fh6/felEl5qU2PehKMMIjX5z6AQCldAwhbxVLbGOXj
DGnsXIqvoXMLt3LhJIers1aDnaWhs6ebC4dWcx3N+Pfsbo6rQEkTcgHDKHCo4dxd
fkBQs3xEahy2JMWNtxi34gcPcdVC2AbUnzO6erpM7hN8f5udSQM=
=soqR
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240408/a2e92ef0/attachment-0001.html>

From dan at telarity.com  Tue Apr  9 06:50:33 2024
From: dan at telarity.com (Dan Fandrich)
Date: Mon, 8 Apr 2024 21:50:33 -0700
Subject: OpenPGP card not available
Message-ID: <ZhTJGTmNlcZm8N5G@coneharvesters.com>

Running "gpg --card-status" with a configured Yubikey plugged in on an x86_64
Linux machine just gives me these errors when running 2.4.5:

gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

However, leaving everything else the same and just running 2.2.42 (& earlier
2.2.x) gives me the output I'd expect with that command.  I've tried some of
the advice I've found of adding "reader-port Yubico Yubi" and "pcsc-shared" to
scdaemon.conf didn't make a difference. Enabling some scdaemon logging shows
this interesting bit in the log file:

2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 <- SERIALNO
2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: BAI=70202
2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: new device=70202
2024-04-08 16:45:28 scdaemon[62168] ccid open error: skip
2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 -> ERR 100696144 No such device <SCD>

With 2.2.42, I see this (with an actual serial number) and all works well:

2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 <- SERIALNO
2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: BAI=70202
2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: new device=70202
2024-04-08 16:38:43 scdaemon[36563] ccid open error: skip
2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> S SERIALNO D0000000000000000000000000000000
2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> OK
...

Running "echo SERIALNO | scd/scdaemon --server" is enough.  I've tried both
pcsc-lite 1.9.9 and 2.0.3 without a difference.  I'm not sure how to drill
down to figure out further to figure out what else could be causing the
failure. One obvious difference is that the working version is linked against
libpthread.so.0 but the failing one is linked against libnpth.so.0, but that
seems to have to do with locking which I wouldn't expect to make difference
with a simple local test.

I was hoping to bisect to the problem except that the 2.3 and 2.4 branches fail
at their .0 versions. Does someone have a suggestion to debug further?

Dan


From wk at gnupg.org  Tue Apr  9 12:04:27 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Apr 2024 12:04:27 +0200
Subject: Can not import private key (Not enough space)
In-Reply-To: <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
 (Moses via Gnupg-users's message of "Mon, 8 Apr 2024 11:42:03 +0000")
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
 <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
Message-ID: <87a5m2am38.fsf@jacob.g10code.de>

On Mon,  8 Apr 2024 11:42, Moses said:

> C:\> gpg-connect-agent -v
>> getinfo version
> D 2.4.5

Okay, that works.

>> gpgconf -L
> ERR 67109139 Unknown IPC command <GPG Agent>

Please enter this on the command line not at the gpg-connect-agent
prompt.


Salam-Shalom,

   Werner

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

From wk at gnupg.org  Tue Apr  9 12:11:31 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Apr 2024 12:11:31 +0200
Subject: OpenPGP card not available
In-Reply-To: <ZhTJGTmNlcZm8N5G@coneharvesters.com> (Dan Fandrich's message of
 "Mon, 8 Apr 2024 21:50:33 -0700")
References: <ZhTJGTmNlcZm8N5G@coneharvesters.com>
Message-ID: <875xwqalrg.fsf@jacob.g10code.de>

On Mon,  8 Apr 2024 21:50, Dan Fandrich said:

> Running "echo SERIALNO | scd/scdaemon --server" is enough.  I've tried both
> pcsc-lite 1.9.9 and 2.0.3 without a difference.  I'm not sure how to drill

By default we are not using PC/SC on Linux but direct access to the
reader via USB.  Now if pcscd is already running and has access to the
reader scdaemon won't be able to access the reader via USB.

2.2 falls back to PC/SC if it can't use the reader via USB.

Either shutdown pcscd or add

disable-ccid-driver

to ~/.gnupg/scdaemon.conf

More debug output can be logged by adding

debug cardio
debug-ccid-reader


Shalom-Salam,

   Werner


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

From dan at telarity.com  Tue Apr  9 02:00:51 2024
From: dan at telarity.com (Dan Fandrich)
Date: Mon, 8 Apr 2024 17:00:51 -0700
Subject: OpenPGP card not available
Message-ID: <ZhSFM1wsPapSPc5d@coneharvesters.com>

Running "gpg --card-status" with a configured Yubikey plugged in on an x86_64
Linux machine just gives me these errors when running 2.4.5:

gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

However, leaving everything else the same and just running 2.2.42 (& earlier
2.2.x) gives me the output I'd expect with that command.  I've tried some of
the advice I've found of adding "reader-port Yubico Yubi" and "pcsc-shared" to
scdaemon.conf didn't make a difference. Enabling some scdaemon logging shows
this interesting bit in the log file:

2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 <- SERIALNO
2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: BAI=70202
2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: new device=70202
2024-04-08 16:45:28 scdaemon[62168] ccid open error: skip
2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 -> ERR 100696144 No such device <SCD>

With 2.2.42, I see this (with an actual serial number) and all works well:

2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 <- SERIALNO
2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: BAI=70202
2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: new device=70202
2024-04-08 16:38:43 scdaemon[36563] ccid open error: skip
2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> S SERIALNO D0000000000000000000000000000000
2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> OK
...

Running "echo SERIALNO | scd/scdaemon --server" is enough.  I've tried both
pcsc-lite 1.9.9 and 2.0.3 without a difference.  I'm not sure how to drill
down to figure out further to figure out what else could be causing the
failure. One obvious difference is that the working version is linked against
libpthread.so.0 but the failing one is linked against libnpth.so.0, but that
seems to have to do with locking which I wouldn't expect to make difference
with a simple local test.

I was hoping to bisect to the problem except that the 2.3 and 2.4 branches fail
at their .0 versions. Does someone have a suggestion to debug further?

Dan


From moses.mason at gmail.com  Tue Apr  9 14:21:36 2024
From: moses.mason at gmail.com (Moses)
Date: Tue, 9 Apr 2024 12:21:36 +0000
Subject: Can not import private key (Not enough space)
In-Reply-To: <87a5m2am38.fsf@jacob.g10code.de>
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
 <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
 <87a5m2am38.fsf@jacob.g10code.de>
Message-ID: <CAAYZpmSyBLQ8e+5Mb32=Vi-GM1c9FnJ7gg_yVsc++Sdj=MfHhQ@mail.gmail.com>

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

Returns as follows:
(just blacked out the username...)

C:\>gpgconf -L
sysconfdir:C%3a\ProgramData\GNU\etc\gnupg
bindir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin
libexecdir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin
libdir:D%3a\software\GNU\Gpg4win\..\GnuPG\lib\gnupg
datadir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\gnupg
localedir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\locale
socketdir:C%3a\Users\?????\AppData\Local\gnupg
dirmngr-socket:C%3a\Users\?????\AppData\Local\gnupg\S.dirmngr
keyboxd-socket:C%3a\Users\?????\AppData\Local\gnupg\S.keyboxd
agent-ssh-socket:C%3a\Users\?????\AppData\Local\gnupg\S.gpg-agent.ssh
agent-extra-socket:C%3a\Users\?????\AppData\Local\gnupg\S.gpg-agent.extra
agent-browser-socket:C%3a\Users\?????\AppData\Local\gnupg\S.gpg-agent.browser
agent-socket:C%3a\Users\?????\AppData\Local\gnupg\S.gpg-agent
homedir:C%3a\Users\?????\AppData\Roaming\gnupg




On Tue, Apr 9, 2024 at 10:05?AM Werner Koch <wk at gnupg.org> wrote:
>
> On Mon,  8 Apr 2024 11:42, Moses said:
>
> > C:\> gpg-connect-agent -v
> >> getinfo version
> > D 2.4.5
>
> Okay, that works.
>
> >> gpgconf -L
> > ERR 67109139 Unknown IPC command <GPG Agent>
>
> Please enter this on the command line not at the gpg-connect-agent
> prompt.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEtS81xZ6ggCm51urXjBWeIrrYv8gFAmYVMnsACgkQjBWeIrrY
v8hGFRAAq2Y7Rzahrz3nBKoLkO29rzKMpurp0XXhOk0ONPXcJGKCLDq6UvDa1VmH
yowbbY87lOSucAKjyekrr1qr0as7p76/rRQPQeorXjQF/GeEFTUEzolRWJk70M3C
+Wcxi9WbNV/VmZsnJUjpsG4FKyqgBqhKdildPm1CvTF4mmF+X5cOK1swi3GoWf3I
LGF9zJ+Gbm5Shs65htJ9xCSryCYEHciZHev5zMt6yQM1ZBBjKbkOC2OLRoFSBCej
CDHcmY4tA6a//De4jUyv3ypoxBv4bPOLOgvDzRVne62hhOwAQqtFF8ZgX+McS4cs
Zw+xJycPZVDegFvlQW2qwhtJWYfUXCGpxlrsi/1zoOgHp1uaR8O/8x8gszBuiXKj
kuLIojRZWRnt1lYItO3oUO6t/z95HfNUE1aT4hKcGuDx/yK4/1h4i9VFb48W0qAu
WoWuiON8Q36SsLA2C6cuPfpjx5gusX31iiuMoNH5IoujN6Ip4al9v0Goo76CSe7l
Sqy4iLmAh3DhTt2prw70k93GAMD3oORT/AGk1SyxDoRzRmV99BELdr4ZGFyJnhqW
wvBjxtl0ynRg7UOKilug+tZbTRSlAqNMeBAKLn90aSsmy8f/MZuPvyDnhowpoL/a
7jpZaLlTvKvzi++Yd5MHvyX97rOrzIndsVyC1Qr1yN+EuQa1ubI=
=3+BK
-----END PGP SIGNATURE-----


From wk at gnupg.org  Tue Apr  9 16:58:46 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Apr 2024 16:58:46 +0200
Subject: Can not import private key (Not enough space)
In-Reply-To: <CAAYZpmSyBLQ8e+5Mb32=Vi-GM1c9FnJ7gg_yVsc++Sdj=MfHhQ@mail.gmail.com>
 (Moses via Gnupg-users's message of "Tue, 9 Apr 2024 12:21:36 +0000")
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
 <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
 <87a5m2am38.fsf@jacob.g10code.de>
 <CAAYZpmSyBLQ8e+5Mb32=Vi-GM1c9FnJ7gg_yVsc++Sdj=MfHhQ@mail.gmail.com>
Message-ID: <87il0qziop.fsf@jacob.g10code.de>

Hi!

On Tue,  9 Apr 2024 12:21, Moses said:
> C:\>gpgconf -L

which merely shows that you installed the software on d:\software and
kep the user data at the usual C: directories.  I see nothing strange.

To recap your problem was:

c:\> gpg --import private-keys.asc
gpg: enabled compatibility flags:
[snipped]
gpg: key xxxxxxxxxxxxxxxxxxxxxxx: error sending to agent: Not enough space

I don't known why you get that error which might hint at a out of memory
(not out of disk space) problem.    We could look at the output of

  gpgconf -V

and

  gpgconf -X

but I doubt that this will show anything useful for your case.  Can you
start kleopatra?  If so, what does its selftest tell?

What you can do is:

  gpgconf -K all

to stop all background processes (or use the taskmgr or logout and in
again).

  cd %APPDATA%
  ren gnupg gnupg.save
  cd %LOCALAPPDATA%
  ren gnupg gnupg.save

and then try agin.  If this does work you might have insufficent
permissions somewhere below %APPDATA%\gnupg .  If kleopatra starts you
can also teh DbgViewer tool from Sysinternals to see the diagnostics
from Kleopatra.


Shalom-Salam,

   Werner

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

From dan at telarity.com  Tue Apr  9 18:15:05 2024
From: dan at telarity.com (Dan Fandrich)
Date: Tue, 9 Apr 2024 09:15:05 -0700
Subject: OpenPGP card not available
In-Reply-To: <875xwqalrg.fsf@jacob.g10code.de>
References: <ZhTJGTmNlcZm8N5G@coneharvesters.com>
 <875xwqalrg.fsf@jacob.g10code.de>
Message-ID: <ZhVpiTPjECiF-Klk@coneharvesters.com>

On Tue, Apr 09, 2024 at 12:11:31PM +0200, Werner Koch wrote:
> By default we are not using PC/SC on Linux but direct access to the
> reader via USB.  Now if pcscd is already running and has access to the
> reader scdaemon won't be able to access the reader via USB.
> 
> 2.2 falls back to PC/SC if it can't use the reader via USB.

That explains the difference it nicely.

> Either shutdown pcscd or add
> 
> disable-ccid-driver
> 
> to ~/.gnupg/scdaemon.conf

Shutting down pcscd fixed it!  But I have other software that needs pcscd to
access the card, so I added "disable-ccid" to scdaemon.conf and gpg now works
even though pcscd is running.  Thanks for the help.

Dan


From moses.mason at gmail.com  Wed Apr 10 07:35:04 2024
From: moses.mason at gmail.com (Moses)
Date: Wed, 10 Apr 2024 05:35:04 +0000
Subject: Can not import private key (Not enough space)
In-Reply-To: <87il0qziop.fsf@jacob.g10code.de>
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
 <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
 <87a5m2am38.fsf@jacob.g10code.de>
 <CAAYZpmSyBLQ8e+5Mb32=Vi-GM1c9FnJ7gg_yVsc++Sdj=MfHhQ@mail.gmail.com>
 <87il0qziop.fsf@jacob.g10code.de>
Message-ID: <CAAYZpmQ=jSiUiS2b_qjkRHV-0ptx_pRFJx8vR2eWXrvu24oh_g@mail.gmail.com>

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

Hi,

Thank you for your continued follow-up. I executed commands. Here are
the results:

C:\>gpgconf -V
* GnuPG 2.4.5 (cbff323b3)
MingW32
Windows 10.0 build 19045

* Libgcrypt 1.10.3 (aa161086)
version:1.10.3:10a03:1.48:13000:
cc:100000:gcc:10-win32 20210110:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3:
rnd-mod:w32:
cpu-arch:x86:
mpi-asm:i386/mpih-add1.S:i386/mpih-sub1.S:i386/mpih-mul1.S:i386/mpih-mul2.S:i386/mpih-mul3.S:i386/mpih-lshift.S:i386/mpih-rshift.S:
hwflist:intel-cpu:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc:
fips-mode:n:::
rng-type:standard:1:3030000:1:
compliance:::

* GpgRT 1.48 (77b7c5f)

* Libassuan 2.5.7 (cc2f776)

* KSBA 1.6.6 (3a43822)

* NTBTLS 0.3.2 (2c38007)


C:\>gpgconf -X
### Dump of all standard config files
### GnuPG 2.4.5 (cbff323b3)
### MingW32
### [VERSION file not found]
### Windows 10.0 build 19045
### Libgcrypt 1.10.3
### GpgRT 1.48
### Codepages: 65001 936 936
###

sysconfdir:C%3a\ProgramData\GNU\etc\gnupg
bindir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin
libexecdir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin
libdir:D%3a\software\GNU\Gpg4win\..\GnuPG\lib\gnupg
datadir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\gnupg
localedir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\locale
socketdir:C%3a\Users\???\AppData\Local\gnupg
dirmngr-socket:C%3a\Users\???\AppData\Local\gnupg\S.dirmngr
keyboxd-socket:C%3a\Users\???\AppData\Local\gnupg\S.keyboxd
agent-ssh-socket:C%3a\Users\???\AppData\Local\gnupg\S.gpg-agent.ssh
agent-extra-socket:C%3a\Users\???\AppData\Local\gnupg\S.gpg-agent.extra
agent-browser-socket:C%3a\Users\???\AppData\Local\gnupg\S.gpg-agent.browser
agent-socket:C%3a\Users\???\AppData\Local\gnupg\S.gpg-agent
homedir:C%3a\Users\???\AppData\Roaming\gnupg

PATH=D:\software\VMware\bin\;C:\Program Files\Common
Files\Oracle\Java\javapath;C:\Program
Files\Microsoft\jdk-11.0.12.7-hotspot\bin;C:\Program Files
(x86)\Common Files\Intel\Shared
Libraries\redist\intel64\compiler;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program
Files\dotnet\;C:\Program Files\Microsoft SQL
Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client
SDK\ODBC\170\Tools\Binn\;D:\software\GNU\GnuWin32\bin;D:\software\Git\cmd;D:\software\Python\Python39\Scripts;D:\software\Python\Python39\;D:\software\emacs\bin;C:\Program
Files\Azure Data Studio\bin;C:\Program Files\Microsoft SQL
Server\150\Tools\Binn\;C:\Users\???\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\???\App;D:\software\Calibre\;C:\Program
Files (x86)\Microsoft SQL Server\160\DTS\Binn\;C:\Program Files
(x86)\cloudflared\.;D:\software\GNU\Gpg4win\..\GnuPG\bin;C:\Program
Files\WireGuard\;C:\Users\???\AppData\Local\Programs\Python\Python310\;C:\Users\???\AppData\Local\Microsoft\WindowsApps;C:\Users\???\.dotnet\tools;C:\Program
Files\Azure Data
Studio\bin;D:\software\Google\CloudSDK\google-cloud-sdk\bin

###
### global config "C:\ProgramData\GNU\etc\gnupg\common.conf": not installed
###
###
### local config "C:\Users\???\AppData\Roaming\gnupg\common.conf": not installed
###

###
### global config "C:\ProgramData\GNU\etc\gnupg\gpg-agent.conf": not installed
###
###
### local config "C:\Users\???\AppData\Roaming\gnupg\gpg-agent.conf"
###
- --8<---------------cut here---------------start------------->8---

###+++--- GPGConf ---+++###
verbose
verbose
debug-level guru
###log-file C:\Users\???\AppData\Roaming\gnupg\gpg-agent.log
###+++--- GPGConf ---+++### 03/08/24 12:14:59 Coordinated Universal Time
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
- --8<---------------cut here---------------end--------------->8---

###
### global config "C:\ProgramData\GNU\etc\gnupg\scdaemon.conf": not installed
###
###
### local config "C:\Users\???\AppData\Roaming\gnupg\scdaemon.conf"
###
- --8<---------------cut here---------------start------------->8---

###+++--- GPGConf ---+++###
verbose
verbose
verbose
verbose
verbose
###+++--- GPGConf ---+++### 03/08/24 10:46:59 Coordinated Universal Time
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
- --8<---------------cut here---------------end--------------->8---

###
### global config "C:\ProgramData\GNU\etc\gnupg\dirmngr.conf": not installed
###
###
### local config "C:\Users\???\AppData\Roaming\gnupg\dirmngr.conf"
###
- --8<---------------cut here---------------start------------->8---

###+++--- GPGConf ---+++###
#allow-version-check
allow-version-check
honor-http-proxy
keyserver hkps://keys.openpgp.org
verbose
verbose
debug-level advanced
###+++--- GPGConf ---+++### 03/08/24 12:15:00 Coordinated Universal Time
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
- --8<---------------cut here---------------end--------------->8---

###
### global config "C:\ProgramData\GNU\etc\gnupg\gpg.conf": not installed
###
###
### local config "C:\Users\???\AppData\Roaming\gnupg\gpg.conf"
###
- --8<---------------cut here---------------start------------->8---

###+++--- GPGConf ---+++###
utf8-strings
auto-key-locate local
max-cert-depth 6
keyserver hkps://keys.openpgp.org
verbose
verbose
###+++--- GPGConf ---+++### 03/08/24 12:11:57 Coordinated Universal Time
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
- --8<---------------cut here---------------end--------------->8---

###
### global config "C:\ProgramData\GNU\etc\gnupg\gpgsm.conf": not installed
###
###
### local config "C:\Users\???\AppData\Roaming\gnupg\gpgsm.conf"
###
- --8<---------------cut here---------------start------------->8---

###+++--- GPGConf ---+++###
verbose
verbose
verbose
verbose
verbose
auto-issuer-key-retrieve
###+++--- GPGConf ---+++### 03/08/24 12:14:59 Coordinated Universal Time
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
- --8<---------------cut here---------------end--------------->8---

###
### Registry entries:
###
###
### GnuPG Desktop related:
### HKLM\Software\Gpg4win:Install Directory
###   ->D:\software\GNU\Gpg4win<-
###

C:\>gpgconf -K all

C:\>cd %APPDATA%

C:\Users\???\AppData\Roaming>ren gnupg gnupg.save

C:\Users\???\AppData\Roaming>cd %LOCALAPPDATA%

C:\Users\???\AppData\Local>ren gnupg gnupg.save

C:\Users\???\AppData\Local>cd \

C:\>gpg --import private-keys.asc
gpg: C:\\Users\\???\\AppData\\Roaming\\gnupg\\trustdb.gpg: trustdb created
gpg: key ??????????????????????????? imported
gpg: key ?????????: error sending to agent: Not enough space
gpg: error building skey array: Not enough space
gpg: error reading 'private-keys.asc': Not enough space
gpg: import from 'private-keys.asc' failed: Not enough space
gpg: Total number processed: 0
gpg:               imported: 1
gpg:       secret keys read: 1

C:\>

I'm executing on a workstation with 64GB of RAM. The Kleopatra can
start, self-test is all passed except "VS-NfD compliant", here is the
snapshot: https://i.postimg.cc/CLc1ny05/image.png

Also, maybe related, someone in the IRC channel guided me to enable
and check the log of gpg-agent, and here is the result,

2024-04-08 08:03:37 gpg-agent[27040] command 'KEYINFO' failed: System
error w/o errno
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc -> ERR
67125245 System error w/o errno <GPG Agent>
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
KEYWRAP_KEY --import
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc ->
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc -> OK
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
SETKEYDESC ?????????????????
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc -> OK
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
IMPORT_KEY --timestamp=20190920T043443
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc ->
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] command 'IMPORT_KEY' failed: File exists
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc -> ERR
67141667 File exists <GPG Agent>
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
SETKEYDESC ?????????????????
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc -> OK
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
IMPORT_KEY --timestamp=20190920T043443
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc ->
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <-
[[Confidential data not shown]]
2024-04-08 08:03:37 gpg-agent[27040] starting a new PIN Entry
2024-04-08 08:03:37 gpg-agent[27040] DBG: connection to PIN entry established
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc -> INQUIRE
PINENTRY_LAUNCHED 35184 qt 1.2.1 - - - - 0/0 -
2024-04-08 08:03:37 gpg-agent[27040] DBG: chan_0x000002cc <- END
2024-04-08 08:03:41 gpg-agent[27040] DBG: agent_cache_housekeeping
2024-04-08 08:03:45 gpg-agent[27040] DBG: agent_cache_housekeeping
2024-04-08 08:03:49 gpg-agent[27040] DBG: agent_cache_housekeeping
2024-04-08 08:03:51 gpg-agent[27040] DBG: rsa_testkey    => Success
2024-04-08 08:03:51 gpg-agent[27040] command 'IMPORT_KEY' failed: Not
enough space
2024-04-08 08:03:51 gpg-agent[27040] DBG: chan_0x000002cc -> ERR
67141718 Not enough space <GPG Agent>
2024-04-08 08:03:51 gpg-agent[27040] DBG: chan_0x000002cc <- [eof]
2024-04-08 08:03:51 gpg-agent[27040] DBG: chan_0x0000014c -> RESTART
2024-04-08 08:03:51 gpg-agent[27040] DBG: chan_0x0000014c <- OK
2024-04-08 08:03:53 gpg-agent[27040] DBG: agent_cache_housekeeping
2024-04-08 08:03:57 gpg-agent[27040] DBG: agent_cache_housekeeping
2024-04-08 08:03:57 gpg-agent[27040] DBG: chan_0x00000324 -> OK
Pleased to meet you
2024-04-08 08:03:57 gpg-agent[27040] DBG: chan_0x00000324 <- GETINFO pid
2024-04-08 08:03:57 gpg-agent[27040] DBG: chan_0x00000324 -> D 27040
2024-04-08 08:03:57 gpg-agent[27040] DBG: chan_0x00000324 -> OK
2024-04-08 08:03:57 gpg-agent[27040] socket is still served by this server


- --
M.

On Tue, Apr 9, 2024 at 2:59?PM Werner Koch <wk at gnupg.org> wrote:
>
> Hi!
>
> On Tue,  9 Apr 2024 12:21, Moses said:
> > C:\>gpgconf -L
>
> which merely shows that you installed the software on d:\software and
> kep the user data at the usual C: directories.  I see nothing strange.
>
> To recap your problem was:
>
> c:\> gpg --import private-keys.asc
> gpg: enabled compatibility flags:
> [snipped]
> gpg: key xxxxxxxxxxxxxxxxxxxxxxx: error sending to agent: Not enough space
>
> I don't known why you get that error which might hint at a out of memory
> (not out of disk space) problem.    We could look at the output of
>
>   gpgconf -V
>
> and
>
>   gpgconf -X
>
> but I doubt that this will show anything useful for your case.  Can you
> start kleopatra?  If so, what does its selftest tell?
>
> What you can do is:
>
>   gpgconf -K all
>
> to stop all background processes (or use the taskmgr or logout and in
> again).
>
>   cd %APPDATA%
>   ren gnupg gnupg.save
>   cd %LOCALAPPDATA%
>   ren gnupg gnupg.save
>
> and then try agin.  If this does work you might have insufficent
> permissions somewhere below %APPDATA%\gnupg .  If kleopatra starts you
> can also teh DbgViewer tool from Sysinternals to see the diagnostics
> from Kleopatra.
>
>
> Shalom-Salam,
>
>    Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEtS81xZ6ggCm51urXjBWeIrrYv8gFAmYWJNwACgkQjBWeIrrY
v8gHFQ//bGLZ3F37lRZHrNYyuSZSOT6Epx3qBXa528QkxpaLTDp8PHFtIFTpsm9h
sHJNlXem45grhM/I4+LbVcniMp+plz+geW2MvFsrn6SO2QlJpsh3hTjS/hzVmU4Z
MUgkiRroQS+zWAK+msQewImg5LWmj5L2vk1VQ6HqlPPa04AOm2oXAF0+Qrb7skoV
qWcfAInyJihCSobE0HUFk60XNhXLr5RQ+udLDoA4wJA9yCZWZADN4pwxWXXDx9+e
VLybWmo6Is/doKTcmv9yLzr2XIRUnSwNikTqNAyBgIlnQFD03TbqEXazT1nOnKOi
nWZoRgY+Le6A2QJKMJTQ2mrvj1bf0HbSYuT6ZzS4aYUAQd6yLu8sYSLdoJQFA3F8
cTjV+AMPfJcwy9b1wutDxxLikv7vU3WLEQkqDP5pNT5UCz3Wb86M+pkCn0yIMDoH
dYOGTre0/61lUqIlp/2FLBJTskVoC/1AvRm0VjfJGb/foDuSITqigrcJiAtZt6uz
Ouy5N7N1cby3J2J6Eqf8F/g/zAU9r48E+wFTJXMpi1uVVxHqqJ5patUGrWzxje8X
MTGfly/C35DpcRyH4d2ORRiNBz2lYXFNjtbA3TLXNNfZ5RN5YWoWJfcflI/R7jMH
7g/ZEgo8NG0SWz5+uqMxC2wiY9ZM4Cid2r5vL6H288Pm88oC9nI=
=+qb0
-----END PGP SIGNATURE-----


From wk at gnupg.org  Wed Apr 10 17:34:15 2024
From: wk at gnupg.org (Werner Koch)
Date: Wed, 10 Apr 2024 17:34:15 +0200
Subject: Can not import private key (Not enough space)
In-Reply-To: <CAAYZpmQ=jSiUiS2b_qjkRHV-0ptx_pRFJx8vR2eWXrvu24oh_g@mail.gmail.com>
 (Moses via Gnupg-users's message of "Wed, 10 Apr 2024 05:35:04 +0000")
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
 <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
 <87a5m2am38.fsf@jacob.g10code.de>
 <CAAYZpmSyBLQ8e+5Mb32=Vi-GM1c9FnJ7gg_yVsc++Sdj=MfHhQ@mail.gmail.com>
 <87il0qziop.fsf@jacob.g10code.de>
 <CAAYZpmQ=jSiUiS2b_qjkRHV-0ptx_pRFJx8vR2eWXrvu24oh_g@mail.gmail.com>
Message-ID: <875xwpp6yw.fsf@jacob.g10code.de>

Hi,

I see in your PATH

  D:\software\GNU\GnuWin32\bin

prior to

  D:\software\GNU\Gpg4win\..\GnuPG\bin

May it be that you use a gpg version picked up from the GnuWin32?  Check
also whether there is a gpg binary in the Git program directory.

My educated guess is that Gnuwin32 is a Cygwin based collection of
utilities which might also include gpg.  Cygwin uses a slightly
different and incompatiple socket emulation which would explain the
error your get.  As a workaround you may try to run

  D:\software\GNU\GnuPG\bin\gpg --import foo

to use the correct gpg.


Shalom-Salam,

   Werner


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

From tmz at pobox.com  Wed Apr 10 18:15:42 2024
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 10 Apr 2024 12:15:42 -0400
Subject: Agent forwarding issue
In-Reply-To: <871q7gbbac.fsf@jacob.g10code.de>
References: <Zg94SYOkSEWPx1Jk@pobox.com> <87frw0b2wo.fsf@jacob.g10code.de>
 <ZhAu59Uxo2iquVPx@pobox.com> <871q7gbbac.fsf@jacob.g10code.de>
Message-ID: <Zha7Lm6IM8fKjnPX@pobox.com>

Hi,

Werner Koch via Gnupg-users wrote:
> On Fri,  5 Apr 2024 13:03, Todd Zullinger said:
> 
>> In such a case, it sounds like it may be reasonable to use
>> the normal socket?  Until the remote side is updated to
> 
> In fact, I also did this for some time but later came up with 
> 
>   CommitDate: Wed Oct 12 11:30:35 2022 +0200
> 
>     agent: Introduce attribute "Remote-list" to KEYINFO.
>     
>     * agent/command.c (do_one_keyinfo): Add arg list_mode.  Check
>     attribute Remote-list.
>     (cmd_keyinfo): Change semantics to return nothing in restricted list
>     mode.
> 
> which is
> 
>   *** Remote-list
>   Allow to list the key with the KEYINFO command from a remote machine
>   via the extra socket.  A boolean value is expected; the default is
>   "no".  Note that KEYINFO will anyway provide information if the
>   keygrip is specified.
> 
> Not exactly your problem but somehow related.

Neat.  I have probably read agent/keyformat.txt before, but
not in a long time and I never had any reason to consider
editing the .key files.

This caused me to re-read the document and I'll likely add
an additional Token: line to note the two cards which hold a
new key (which I have yet to start using).  That should make
it easier to move between the cards, it sounds like.

In the process, I spotted a few minor typos and sent a patch
to gnupg-devel.

Thanks again, Werner!

-- 
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240410/c680fe97/attachment.sig>

From wk at gnupg.org  Thu Apr 11 08:25:18 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 11 Apr 2024 08:25:18 +0200
Subject: Agent forwarding issue
In-Reply-To: <Zha7Lm6IM8fKjnPX@pobox.com> (Todd Zullinger via Gnupg-users's
 message of "Wed, 10 Apr 2024 12:15:42 -0400")
References: <Zg94SYOkSEWPx1Jk@pobox.com> <87frw0b2wo.fsf@jacob.g10code.de>
 <ZhAu59Uxo2iquVPx@pobox.com> <871q7gbbac.fsf@jacob.g10code.de>
 <Zha7Lm6IM8fKjnPX@pobox.com>
Message-ID: <87msq0o1pt.fsf@jacob.g10code.de>

On Wed, 10 Apr 2024 12:15, Todd Zullinger said:

> This caused me to re-read the document and I'll likely add
> an additional Token: line to note the two cards which hold a
> new key (which I have yet to start using).  That should make

That is actually there (TOKEN, see the example) and gpg-agent updates
the file if it find another card with the same key.  See for example
https://dev.gnupg.org/T6135 . However, you are free to edit/add such
entries.

Talking about keyformat.txt: I think it is time to move that over to
doc/ where people would expect it.


Shalom-Salam,

   Werner

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

From moses.mason at gmail.com  Thu Apr 11 14:24:33 2024
From: moses.mason at gmail.com (Moses)
Date: Thu, 11 Apr 2024 12:24:33 +0000
Subject: Can not import private key (Not enough space)
In-Reply-To: <875xwpp6yw.fsf@jacob.g10code.de>
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
 <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
 <87a5m2am38.fsf@jacob.g10code.de>
 <CAAYZpmSyBLQ8e+5Mb32=Vi-GM1c9FnJ7gg_yVsc++Sdj=MfHhQ@mail.gmail.com>
 <87il0qziop.fsf@jacob.g10code.de>
 <CAAYZpmQ=jSiUiS2b_qjkRHV-0ptx_pRFJx8vR2eWXrvu24oh_g@mail.gmail.com>
 <875xwpp6yw.fsf@jacob.g10code.de>
Message-ID: <CAAYZpmQw-OZ5t7ZxytJR-KCwKBdu_HOD0AY7+GkOn-S8oywGQQ@mail.gmail.com>

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

Hi,

I checked my D:\software\GNU\GnuWin32\bin. There is no gpg.exe in it,
only gpg-error.exe and gpg-error-config. But there is gpg.exe in my
git folder. I adjusted the PATH and temporarily removed it. Then I
tried to import again, and the same error still occurred. The same
error happened when I tried to directly execute the
D:\software\GNU\GnuPG\bin\gpg --import command.

- --
M.

On Wed, Apr 10, 2024 at 3:35?PM Werner Koch <wk at gnupg.org> wrote:
>
> Hi,
>
> I see in your PATH
>
>   D:\software\GNU\GnuWin32\bin
>
> prior to
>
>   D:\software\GNU\Gpg4win\..\GnuPG\bin
>
> May it be that you use a gpg version picked up from the GnuWin32?  Check
> also whether there is a gpg binary in the Git program directory.
>
> My educated guess is that Gnuwin32 is a Cygwin based collection of
> utilities which might also include gpg.  Cygwin uses a slightly
> different and incompatiple socket emulation which would explain the
> error your get.  As a workaround you may try to run
>
>   D:\software\GNU\GnuPG\bin\gpg --import foo
>
> to use the correct gpg.
>
>
> Shalom-Salam,
>
>    Werner
>
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEtS81xZ6ggCm51urXjBWeIrrYv8gFAmYX1lQACgkQjBWeIrrY
v8hC/xAAkRIsAYlONRBS2Rg30AMB4ghMbU3SKlJ6mNpOcXmdv4U547Ie9iV0F6vl
UkPIn1CTThzffMuRvkWkbB+hccZTWC/lzjEUnpub4cQXG/MWZqX/KZY2ujqHwqSz
RTwv9Nirxw01bP+t6R/BIct4ReIePoI7nyD06JhAOMR3iuE7FCFOg8vaYC7ooZHG
4CUbAptK7l04hPxpfJ5drfqNCeTy2Bh/mHmVADFu43lq9AW9vhcpOabo+8jcNtQn
4FYITjq/P16c1cnNL5CZdWHqGK/+7T4VyIFowGL6/HYRiQR+Nokr1XRLI6+aJ2HU
soRaHc0r2UFVie71jgvPfc+R0dekffW/OCir4Eye3o1KmLrCpHjFKKknYca0pOeA
R4IO1U8tSHzRru3w7GTX9A2V4ziAcrdzmFjBrCWjLSaJJc9FLZbKyXLG9F9nAvIQ
6s+mf3/RaR8AURaO9WLE32Cvi3K2i1vhnPkJgMcgWpvH3MZA8rcrEX0+tSSUuMes
3owKpgKVNmpMsKdtgJEd0HV1VRKk2UV5mUf+b1MAv7jxrH5nApBAJdxrrqrK1hXP
X7v5S/GSgK0gv1zl0MAeyJfgeqJKgDP4VZMl2O3z98Z8DW3stzWMqZv/PR+vZYPY
EExISfJxQxLQtMNVIXm8tkGVEg0kmtCQIkNEnMQJLce+nbnw6mQ=
=VoTO
-----END PGP SIGNATURE-----


From wk at gnupg.org  Thu Apr 11 21:25:32 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 11 Apr 2024 21:25:32 +0200
Subject: Can not import private key (Not enough space)
In-Reply-To: <CAAYZpmQw-OZ5t7ZxytJR-KCwKBdu_HOD0AY7+GkOn-S8oywGQQ@mail.gmail.com>
 (Moses via Gnupg-users's message of "Thu, 11 Apr 2024 12:24:33 +0000")
References: <CAAYZpmQW7iMHjYXWkNj2dBfWhq=EWOGsjfycz_fVGneXyxH_nA@mail.gmail.com>
 <87v84s9t9i.fsf@jacob.g10code.de>
 <CAAYZpmRoeUVxMK8s9Z9_wQjiHrs3UOACXi1NHP88OOBOg6s1ww@mail.gmail.com>
 <87a5m2am38.fsf@jacob.g10code.de>
 <CAAYZpmSyBLQ8e+5Mb32=Vi-GM1c9FnJ7gg_yVsc++Sdj=MfHhQ@mail.gmail.com>
 <87il0qziop.fsf@jacob.g10code.de>
 <CAAYZpmQ=jSiUiS2b_qjkRHV-0ptx_pRFJx8vR2eWXrvu24oh_g@mail.gmail.com>
 <875xwpp6yw.fsf@jacob.g10code.de>
 <CAAYZpmQw-OZ5t7ZxytJR-KCwKBdu_HOD0AY7+GkOn-S8oywGQQ@mail.gmail.com>
Message-ID: <874jc7og5v.fsf@jacob.g10code.de>

On Thu, 11 Apr 2024 12:24, Moses said:
> tried to import again, and the same error still occurred. The same
> error happened when I tried to directly execute the
> D:\software\GNU\GnuPG\bin\gpg --import command.

Well, I have no more idea on how to debug this by mail :-(.

On Linux you would now use strace and on Windows we have the
sysinternals tools to trace the system calls.  And there is printf
debugging - I would here start with libassuan (src/assuan-socket.c).


Salam-Shalom,

   Werner

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

From daniele at grinta.net  Sun Apr 14 15:39:35 2024
From: daniele at grinta.net (Daniele Nicolodi)
Date: Sun, 14 Apr 2024 15:39:35 +0200
Subject: Lost GPG private key passphrase
Message-ID: <c3436c76-49a1-4f42-ad9a-c616fc4e3890@grinta.net>

Hello,

I have an oldish GPG key for which I have lost the passphrase. I have a 
very good idea of what the passphrase is constructed but there are some 
characters substitution that I must have used back then really escape my 
memory now. I think that a tool like John the Ripper could make easy 
work in retrieving it.

Does anyone know how to run john on a private key stored in the format 
used by the new keystore used by gpg2?

Thank you.

Cheers,
Dan


From andrewg at andrewg.com  Wed Apr 17 13:00:38 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 17 Apr 2024 12:00:38 +0100
Subject: x488 vs all other : keyid flip
In-Reply-To: <CAEK3fpDujwUWqSML3pygheXbeSSxc-ye9Aw8DLtgyjFdXedMEg@mail.gmail.com>
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CAEK3fpDujwUWqSML3pygheXbeSSxc-ye9Aw8DLtgyjFdXedMEg@mail.gmail.com>
Message-ID: <CB887DCD-7A8C-40DC-8F07-0B3B4F54F0CA@andrewg.com>

On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> when explicitly telling GnuPG to display x448 fingerprints (gpg
> --fingerprint) it just spits out the "abbreviated hex format" by takes
> the first 50 bytes and sweeping the rest under the rug! Not very nice.

Hi, Christian.

This seems to depend on whether you have ?with-fingerprint? enabled in your gpg.conf file. I commented out this line from my own gpg.conf, and I was able to reproduce Werner?s full 64-character v5 fingerprint output. With this configuration line enabled I could only see your 50-character fingerprint output.

Hope this helps,
Andrew.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240417/0ccdf439/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240417/0ccdf439/attachment-0001.sig>

From code.soma.kurisu at gmail.com  Wed Apr 17 16:43:45 2024
From: code.soma.kurisu at gmail.com (Christian Sommer)
Date: Wed, 17 Apr 2024 16:43:45 +0200
Subject: x488 vs all other : keyid flip
In-Reply-To: <CB887DCD-7A8C-40DC-8F07-0B3B4F54F0CA@andrewg.com>
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CAEK3fpDujwUWqSML3pygheXbeSSxc-ye9Aw8DLtgyjFdXedMEg@mail.gmail.com>
 <CB887DCD-7A8C-40DC-8F07-0B3B4F54F0CA@andrewg.com>
Message-ID: <CAEK3fpD+YNpzh2MYEUcif+YxxX+mcK9WLF+0b_abJ8bi5ChL8A@mail.gmail.com>

You are right Andrew!

I indeed choose to preset the "with-fingerprint" option in my
gpg.conf. By removing it, listing my keys give back the full 64
character long fingerprint of my X448 key.

Very nice to come back on this, thx.
Kris.

On Wed, Apr 17, 2024 at 1:00?PM Andrew Gallagher <andrewg at andrewg.com> wrote:
>
> On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users <gnupg-users at gnupg.org> wrote:
>
>
> when explicitly telling GnuPG to display x448 fingerprints (gpg
> --fingerprint) it just spits out the "abbreviated hex format" by takes
> the first 50 bytes and sweeping the rest under the rug! Not very nice.
>
>
> Hi, Christian.
>
> This seems to depend on whether you have ?with-fingerprint? enabled in your gpg.conf file. I commented out this line from my own gpg.conf, and I was able to reproduce Werner?s full 64-character v5 fingerprint output. With this configuration line enabled I could only see your 50-character fingerprint output.
>
> Hope this helps,
> Andrew.
>


From andrewg at andrewg.com  Wed Apr 17 16:57:27 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 17 Apr 2024 15:57:27 +0100
Subject: x488 vs all other : keyid flip
In-Reply-To: <CAEK3fpD+YNpzh2MYEUcif+YxxX+mcK9WLF+0b_abJ8bi5ChL8A@mail.gmail.com>
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CAEK3fpDujwUWqSML3pygheXbeSSxc-ye9Aw8DLtgyjFdXedMEg@mail.gmail.com>
 <CB887DCD-7A8C-40DC-8F07-0B3B4F54F0CA@andrewg.com>
 <CAEK3fpD+YNpzh2MYEUcif+YxxX+mcK9WLF+0b_abJ8bi5ChL8A@mail.gmail.com>
Message-ID: <00C37A75-E93C-496D-801D-B9013576E1C6@andrewg.com>

On 17 Apr 2024, at 15:43, Christian Sommer <code.soma.kurisu at gmail.com> wrote:
> 
> You are right Andrew!
> 
> I indeed choose to preset the "with-fingerprint" option in my
> gpg.conf. By removing it, listing my keys give back the full 64
> character long fingerprint of my X448 key.

Good to hear!

I think the best solution is for gnupg to ignore the `with-fingerprint` configuration option. Modern versions display primary key fingerprints by default anyway, so the alternative display format is both redundant and potentially confusing.

I would be particularly concerned that people with different settings in their gpg.conf would see a mismatch between the 50-character fingerprint on one machine and the 64-character fingerprint on another, and incorrectly infer that something shady was going on. Differences in whitespace formatting are broadly expected (ref: credit card numbers) but truncation is not.

And to pick up on an earlier point, short key IDs should never be displayed or processed under any circumstances. Evil32 was a whole decade ago.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240417/cdf366d7/attachment.sig>

From wk at gnupg.org  Thu Apr 18 13:53:59 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 18 Apr 2024 13:53:59 +0200
Subject: x488 vs all other : keyid flip
In-Reply-To: <CAEK3fpD+YNpzh2MYEUcif+YxxX+mcK9WLF+0b_abJ8bi5ChL8A@mail.gmail.com>
 (Christian Sommer via Gnupg-users's message of "Wed, 17 Apr 2024
 16:43:45 +0200")
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CAEK3fpDujwUWqSML3pygheXbeSSxc-ye9Aw8DLtgyjFdXedMEg@mail.gmail.com>
 <CB887DCD-7A8C-40DC-8F07-0B3B4F54F0CA@andrewg.com>
 <CAEK3fpD+YNpzh2MYEUcif+YxxX+mcK9WLF+0b_abJ8bi5ChL8A@mail.gmail.com>
Message-ID: <87a5lqkht4.fsf@jacob.g10code.de>

On Wed, 17 Apr 2024 16:43, Christian Sommer said:

> I indeed choose to preset the "with-fingerprint" option in my
> gpg.conf. By removing it, listing my keys give back the full 64
> character long fingerprint of my X448 key.

We once agreed that it is better to show a shortened fingerprint for
human consumption.  However, the mahine interface (--woth-colons) always
provides the full fingerprint.

Further it seems that most users appreciate the non-formatted
fingerprint because that makes it easier to copy+paste.


Shalom-Salam,

   Werner

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

From bwalzer at 59.ca  Thu Apr 18 17:26:39 2024
From: bwalzer at 59.ca (Bruce Walzer)
Date: Thu, 18 Apr 2024 10:26:39 -0500
Subject: x488 vs all other : keyid flip
In-Reply-To: <87a5lqkht4.fsf@jacob.g10code.de>
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CAEK3fpDujwUWqSML3pygheXbeSSxc-ye9Aw8DLtgyjFdXedMEg@mail.gmail.com>
 <CB887DCD-7A8C-40DC-8F07-0B3B4F54F0CA@andrewg.com>
 <CAEK3fpD+YNpzh2MYEUcif+YxxX+mcK9WLF+0b_abJ8bi5ChL8A@mail.gmail.com>
 <87a5lqkht4.fsf@jacob.g10code.de>
Message-ID: <ZiE7r0jGmJXlL4lf@watt.59.ca>

On Thu, Apr 18, 2024 at 01:53:59PM +0200, Werner Koch via Gnupg-users wrote:
> On Wed, 17 Apr 2024 16:43, Christian Sommer said:
> 
> > I indeed choose to preset the "with-fingerprint" option in my
> > gpg.conf. By removing it, listing my keys give back the full 64
> > character long fingerprint of my X448 key.
> 
> We once agreed that it is better to show a shortened fingerprint for
> human consumption.  However, the mahine interface (--woth-colons) always
> provides the full fingerprint.
> 
> Further it seems that most users appreciate the non-formatted
> fingerprint because that makes it easier to copy+paste.

Perhaps things that accept key fingerprints should ignore anything
other than hex digits?

Bruce


From matt at dafacto.com  Thu Apr 18 19:00:59 2024
From: matt at dafacto.com (Matt Henderson)
Date: Thu, 18 Apr 2024 19:00:59 +0200
Subject: Disable integrity check
Message-ID: <6EEDDFDC-A628-4C9E-A50A-59BA3312E658@dafacto.com>

Hello,

I?m a user of the macOS version of GPGTools, and am trying to decrypt literally thousands of files that I PGP encrypted decades ago.

The problem I?m facing is that during the decryption of each file, I?m prompted to manually confirm to overlook a failed integrity check.

Since these files were all encrypted by me, I?d be fine to temporarily disable the integrity check altogether. In fact, that?s the only way decrypting them can be done practically.

However, the fine folks at GPGTools indicated that they didn?t know how to do this, and suggested posting the question to this list.

Thanks so much, in advance.

-- Matt

From kloecker at kde.org  Thu Apr 18 20:20:30 2024
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 18 Apr 2024 20:20:30 +0200
Subject: Disable integrity check
In-Reply-To: <6EEDDFDC-A628-4C9E-A50A-59BA3312E658@dafacto.com>
References: <6EEDDFDC-A628-4C9E-A50A-59BA3312E658@dafacto.com>
Message-ID: <7658058.EvYhyI6sBW@daneel>

On Donnerstag, 18. April 2024 19:00:59 CEST Matt Henderson wrote:
> The problem I?m facing is that during the decryption of each file, I?m
> prompted to manually confirm to overlook a failed integrity check.
> 
> Since these files were all encrypted by me, I?d be fine to temporarily
> disable the integrity check altogether. In fact, that?s the only way
> decrypting them can be done practically.

Try putting `ignore?mdc?error` in your ~/.gnupg/gpg.conf.

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

From wk at gnupg.org  Sat Apr 20 15:50:20 2024
From: wk at gnupg.org (Werner Koch)
Date: Sat, 20 Apr 2024 15:50:20 +0200
Subject: x488 vs all other : keyid flip
In-Reply-To: <ZiE7r0jGmJXlL4lf@watt.59.ca> (Bruce Walzer's message of "Thu, 18
 Apr 2024 10:26:39 -0500")
References: <CAEK3fpCeBNRALZzvUveo4e=yHiWStCtJNiZXM72Q=ZYT_RQz1w@mail.gmail.com>
 <87ttkqg01x.fsf@jacob.g10code.de>
 <CAEK3fpDujwUWqSML3pygheXbeSSxc-ye9Aw8DLtgyjFdXedMEg@mail.gmail.com>
 <CB887DCD-7A8C-40DC-8F07-0B3B4F54F0CA@andrewg.com>
 <CAEK3fpD+YNpzh2MYEUcif+YxxX+mcK9WLF+0b_abJ8bi5ChL8A@mail.gmail.com>
 <87a5lqkht4.fsf@jacob.g10code.de> <ZiE7r0jGmJXlL4lf@watt.59.ca>
Message-ID: <87o7a4i1nn.fsf@jacob.g10code.de>

On Thu, 18 Apr 2024 10:26, Bruce Walzer said:

> Perhaps things that accept key fingerprints should ignore anything
> other than hex digits?

Double clicking a word makes things really easy.  I also doubt that
anyone will compare a 64 hex digit fingerprint visually.  Thus better
paste it and let some software do the comare.

Which reminds me that the gpg --edit-key -> sign dialog should also
accept a fingerprint on the "Really sign? (y/N)" prompt.


Salam-Shalom,

   Werner


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

From eric.pruitt at gmail.com  Wed Apr 24 06:39:16 2024
From: eric.pruitt at gmail.com (Eric Pruitt)
Date: Tue, 23 Apr 2024 21:39:16 -0700
Subject: Is there built-in a way validate a signature against a specific key?
Message-ID: <ZiiM9NSeb1_7LUne@sinister.lan.codevat.com>

I have multiple public keys in my GPG keyring. When validating
signatures, I sometimes want to validate them against a specific key so
if the file is signed by someone other than the individual or
organization I expect, it will fail. Currently, I do this by creating a
keyring that consists of only one key and using that, and some cursory
searching didn't uncover any alternatives. If there still isn't a GPG
option for validating a signature against a specific key, is there a
particular reason it doesn't exist?

Eric


From wk at gnupg.org  Wed Apr 24 11:14:06 2024
From: wk at gnupg.org (Werner Koch)
Date: Wed, 24 Apr 2024 11:14:06 +0200
Subject: Is there built-in a way validate a signature against a specific
 key?
In-Reply-To: <ZiiM9NSeb1_7LUne@sinister.lan.codevat.com> (Eric Pruitt via
 Gnupg-users's message of "Tue, 23 Apr 2024 21:39:16 -0700")
References: <ZiiM9NSeb1_7LUne@sinister.lan.codevat.com>
Message-ID: <877cgngm1t.fsf@jacob.g10code.de>

On Tue, 23 Apr 2024 21:39, Eric Pruitt said:
> I have multiple public keys in my GPG keyring. When validating
> signatures, I sometimes want to validate them against a specific key so

The classcc tool for this is gpgv with its --keyring option.  This is
what for example Debian uses to validate signatures.

A newer way is the --assert-signer option we introduced with version
2.4.1:

     --assert-signer fpr_or_file
     
              This option checks whether at least one valid signature on
              a file has been made with the specified key.  The key is
              either specified as a fingerprint or a file listing
              fingerprints.  The fingerprint must be given or listed in
              compact format (no colons or spaces in between).  This
              option can be given multiple times and each fingerprint is
              checked against the signing key as well as the
              corresponding primary key.  If fpr_or_file specifies a
              file, empty lines are ignored as well as all lines
              starting with a hash sign.  With this option gpg is
              guaranteed to return with an exit code of 0 if and only if
              a signature has been encountered, is valid, and the key
              matches one of the fingerprints given by this option.


Shalom-Salam,

   Werner

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

From eric.pruitt at gmail.com  Sat Apr 27 06:53:38 2024
From: eric.pruitt at gmail.com (Eric Pruitt)
Date: Fri, 26 Apr 2024 21:53:38 -0700
Subject: Is there built-in a way validate a signature against a specific
 key?
In-Reply-To: <877cgngm1t.fsf@jacob.g10code.de>
References: <ZiiM9NSeb1_7LUne@sinister.lan.codevat.com>
 <877cgngm1t.fsf@jacob.g10code.de>
Message-ID: <ZiyE0g4WeXw_1ZvL@sinister.lan.codevat.com>

On Wed, Apr 24, 2024 at 11:14:06AM +0200, Werner Koch via Gnupg-users wrote:
> On Tue, 23 Apr 2024 21:39, Eric Pruitt said:
> > I have multiple public keys in my GPG keyring. When validating
> > signatures, I sometimes want to validate them against a specific key so
> 
> The classcc tool for this is gpgv with its --keyring option.  This is
> what for example Debian uses to validate signatures.

I think this is what I'm already doing and what I meant when I wrote "I
do this by creating a keyring that consists of only one key and using
that [...]" or have I misunderstood what you suggested?

> A newer way is the --assert-signer option we introduced with version
> 2.4.1:

Thanks, this does what I want.

Eric


From subscribernamegoeshere+201207 at gmail.com  Sat Apr 27 18:32:47 2024
From: subscribernamegoeshere+201207 at gmail.com (sngh)
Date: Sat, 27 Apr 2024 18:32:47 +0200
Subject: Lost GPG private key passphrase
In-Reply-To: <c3436c76-49a1-4f42-ad9a-c616fc4e3890@grinta.net>
References: <c3436c76-49a1-4f42-ad9a-c616fc4e3890@grinta.net>
Message-ID: <CAKaMYHnT+x=z2Okd7nUZnMojetghoSe7Bhyyn0-CEYxK5YQ+QQ@mail.gmail.com>

On Sun, Apr 14, 2024 at 4:55?PM Daniele Nicolodi via Gnupg-users <
gnupg-users at gnupg.org> wrote:

> I have an oldish GPG key for which I have lost the passphrase. I have a
> very good idea of what the passphrase is constructed but there are some
> characters substitution that I must have used back then really escape my
> memory now. I think that a tool like John the Ripper could make easy
> work in retrieving it.
> Does anyone know how to run john on a private key stored in the format
> used by the new keystore used by gpg2?
>

dunno much about new format or so? can this still work in this old blog
post?
maybe use an older gpg release on the private key file to export?

> <
https://blog.atucom.net/2015/08/cracking-gpg-key-passwords-using-john.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240427/68c45a62/attachment.html>

From omcujl92 at duck.com  Sun Apr 28 19:02:09 2024
From: omcujl92 at duck.com (omcujl92 at duck.com)
Date: Sun, 28 Apr 2024 13:02:09 -0400
Subject: Example of 'PINENTRY_USER_DATA which can fulfill the'
 (envpassphrase) 'task'?
References: <CAH9E=nXMQRhUAofXa1biL4mneDewivP6LsJwiHBsUHg+s9Tp2w@mail.gmail.com>
Message-ID: <6E56B57E-9464-433B-9BD5-B20144D93CD2.1@smtp-inbound1.duck.com>

> At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
environment variable', there is a comment of "I don't see why we
should add yet more clumsy passphrase workarounds to gpg. We already
have PINENTRY_USER_DATA which can fulfill the same task."

Of course, the reference here to PINENTRY_USER_DATA is specious. To
incorporate the processing of such a customized PINENTRY_USER_DATA requires
the coding of a corresponding pinentry executable to receive it.

And if one has the capacity to code one's own unique pinentry executable
... they could code around the stated problem outside of using
PINENTRY_USER_DATA in the first place.

And the T4154 request would never have been made, in the first place.


So, given the above, a solution towards:

>+ (https://dev.gnupg.org/T4154)
>+
>+ So this patch adds a new form of passphrase-passing, using an environment
>+ variable. In POSIX shell, this looks like (for example):
>+
>+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \
>+   --passphrase-env=mypass --decrypt < message.txt
>+

can be effected without resorting to PINENTRY_USER_DATA - so no need to
code, customize, maintain, update per gpg upgrades, or apply patches to
in-house self-solutions.


> Can anyone give an example of doing so?

> I am looking to effect the equivalent of ...

> Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA
which can fulfill the same task' of gpg picking up its passphrase from an
environment variable?


Examine https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067030.html
('How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?') for
a more detailed example script solution, but in brief for this thread:


gs_myfifo="$(mktemp -ut fifo.XXX)"
mkfifo -m 0600 "${gs_myfifo}"

gs_mysecretpassphrase="KXhtctw4_zFfhRop"

echo -e "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
unset gs_mysecretpassphrase

echo -e "Stuff to be encrypted." \
| gpg --pinentry-mode loopback --passphrase-fd 3 -c 3< "${gs_myfifo}"

rm "${gs_myfifo}"


Of course, 'gs_mysecretpassphrase="KXhtctw4_zFfhRop"' would be replaced
with some other mechanism of acquiring the passphrase. Perhaps via
something such as:

export GPG_TERM="${TERM}"
echo -e "GETPIN\nBYE\n" \
| pinentry --ttyname "${GPG_TTY}" \
| sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //"

On Thu, Mar 21, 2024 at 7:45?PM B.S. <bs27975 at gmail.com> wrote:

> At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
> environment variable', there is a comment of "I don't see why we
> should add yet more clumsy passphrase workarounds to gpg. We already
> have PINENTRY_USER_DATA which can fulfill the same task."
>
> Can anyone give an example of doing so?
>
> I am looking to effect the equivalent of:
> '@rem Get passhrase into (env.) var. programmatically (in your
> favourite manner)'
> 'set /p myenvpassphrase="Enter symmetric keyphrase to use:"
> 'echo "Secret data" | gpg.exe -c --envpassphrase myenvpassphrase >
> secretdata.gpg'
> - thereby avoiding storing any passphrase (even temporarily) on a
> storage medium, nor have it visible as the command line (via tasklist
> or ps).
> - in this case, the 'secret data' is actually confidential
> information, piped from elsewhere, on the fly.
>
> Of course, the '-envpassphrase' option doesn't exist in gpg currently,
> but the comment at the above link indicates that there is another way
> to effect the same intent.
>
> Can anyone give an example of so doing?
>
> A current means of effecting the same is, of course, '--passphase-fd
> 3", for something like:
> 'echo "Secret data" | gpg.exe -c --passphrase-fd 3 3< echo %PASSWORD%
> > secretdata.gpg'
> - except I have no idea [in (Win 10) DOS, not powershell, cmd] how to
> get anything into file descriptor 3.
> = let alone get an echo into fd 3 (without actually landing on a
> filesystem, even temporarily).
>
> Of course:
> 'echo "Secret data" | gpg.exe -c --passphrase > secretdata.gpg'
> - doesn't work, as stdin can't be 'in two places at once', both
> passphrase input, and data input.
> = Remember, "Secret data" isn't on disk, either - it's being piped in, too.
>
> Has anyone got a link to a working example of '3<' or
> 'PINENTRY_USER_DATA which can fulfill the same task' of gpg picking up
> its passphrase from an environment variable?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240428/3a9ebe93/attachment.html>

From wk at gnupg.org  Mon Apr 29 11:42:20 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 29 Apr 2024 11:42:20 +0200
Subject: Example of 'PINENTRY_USER_DATA which can fulfill the'
 (envpassphrase) 'task'?
In-Reply-To: <6E56B57E-9464-433B-9BD5-B20144D93CD2.1@smtp-inbound1.duck.com>
 (Bee via Gnupg-users's message of "Sun, 28 Apr 2024 13:02:09 -0400")
References: <CAH9E=nXMQRhUAofXa1biL4mneDewivP6LsJwiHBsUHg+s9Tp2w@mail.gmail.com>
 <6E56B57E-9464-433B-9BD5-B20144D93CD2.1@smtp-inbound1.duck.com>
Message-ID: <87frv48pz7.fsf@jacob.g10code.de>

On Sun, 28 Apr 2024 13:02, Bee said:

>>+ (https://dev.gnupg.org/T4154)
[...]
>>+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \
>>+   --passphrase-env=mypass --decrypt < message.txt
>>+
>
> can be effected without resorting to PINENTRY_USER_DATA - so no need to
> code, customize, maintain, update per gpg upgrades, or apply patches to
> in-house self-solutions.

Simply don't use a passphrase if you need to resort to such a thing.  On
many systems you - and other users - can easily look at the
environment.  It is also part of all kind of bug reports.


Shalom-Salam,

   Werner


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

From omcujl92 at duck.com  Mon Apr 29 13:03:36 2024
From: omcujl92 at duck.com (omcujl92 at duck.com)
Date: Mon, 29 Apr 2024 07:03:36 -0400
Subject: Example of 'PINENTRY_USER_DATA which can fulfill the'
 (envpassphrase) 'task'?
References: <CAH9E=nXMQRhUAofXa1biL4mneDewivP6LsJwiHBsUHg+s9Tp2w@mail.gmail.com>
 <CAH9E=nWw8Ed_Mr=ehqauXKU9dnC4+xEq5Y8RO-yyba7fvJjNBA@mail.gmail.com>
Message-ID: <ECA2E24C-2143-4E28-AB46-615D0310FFC8.1@smtp-inbound1.duck.com>

Again, specious.

> Simply don't use a passphrase if you need to resort to such a thing.  On
> many systems you - and other users - can easily look at the
> environment.

But that environment is not passed and used by pinentry - it has no
knowledge of them. PINENTRY_USER_DATA may exist, but it has no
knowledge as to how to interpret it. Ergo, some other mechanism must
be used. Such as an environment variable. So that the passphrase is
not visible within the script or a command line listing of the process
table. And preferably not even stored anywhere, in plain text.

A script (containing a hardwired passphrase) may well remain in
existence for some time, even, as a service, forever. The passphrase
remaining visible - both script, and/or command line, for the
duration. The solution given, for example, leaves no passphrase
visible in script or command line - in plain text only for the minimal
number of script lines - assuming a nefarious user is even present for
those microseconds,
never mind a casual one, -AND- that they have superuser privileges to
even be able to examine foreign (to the userid) process variables.
While even casual users can view scripts and process tables [but not
foreign process' environment variables].

It is quite evident that passphrase use is intended by gpg design.
Search 'passphrase' within 'man gpg' and one cannot escape such a
conclusion. Particularly '-c'.

e.g. echo "Secret data to be encrypted" | gpg -c ...

Examples of on the fly script use without key overhead have been
requested [here (thread(s) earlier) and elsewhere], that do not involve keys or
hardwiring a passphrase - without answer. If you have such, please
post. If I missed it, apologies, please advise of links.

If passphrase use was not to be used, then all code and documentation
containing the word 'passphrase' would have been stripped from the
content long ago. That it hasn't been can only be taken to mean that
it is intended and desired functionality.

A working alternative algorithm posted to the end of
https://dev.gnupg.org/T4154 would be welcome, and websearch visible to
those so looking. As it stands, things are circular - the suggested
solution is a custom PINENTRY_USER_DATA, and ergo a customized gpg
environment crafted to receive it, but if that were in place or desired, the
requested and delivered enhancement wouldn't be needed. This is
circular.

A working alternative (key-free and clear text free) algorithm posted
to the end of
https://dev.gnupg.org/T4154 would be welcome, and websearch visible to
those so looking.


On Sun, Apr 28, 2024 at 12:53?PM B.S. <bs27975 at gmail.com> wrote:
>
>
> > At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
> environment variable', there is a comment of "I don't see why we
> should add yet more clumsy passphrase workarounds to gpg. We already
> have PINENTRY_USER_DATA which can fulfill the same task."
>
> Of course, the reference here to PINENTRY_USER_DATA is specious. To incorporate the processing of such a customized PINENTRY_USER_DATA requires the coding of a corresponding pinentry executable to receive it.
>
> And if one has the capacity to code one's own unique pinentry executable ... they could code around the stated problem outside of using PINENTRY_USER_DATA in the first place.
>
> And the T4154 request would never have been made, in the first place.
>
>
> So, given the above, a solution towards:
>
> >+ (https://dev.gnupg.org/T4154)
> >+
> >+ So this patch adds a new form of passphrase-passing, using an environment
> >+ variable. In POSIX shell, this looks like (for example):
> >+
> >+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \
> >+   --passphrase-env=mypass --decrypt < message.txt
> >+
>
> can be effected without resorting to PINENTRY_USER_DATA - so no need to code, customize, maintain, update per gpg upgrades, or apply patches to in-house self-solutions.
>
>
> > Can anyone give an example of doing so?
>
> > I am looking to effect the equivalent of ...
>
> > Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA which can fulfill the same task' of gpg picking up its passphrase from an environment variable?
>
>
> Examine https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067030.html ('How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?') for a more detailed example script solution, but in brief for this thread:
>
>
> gs_myfifo="$(mktemp -ut fifo.XXX)"
> mkfifo -m 0600 "${gs_myfifo}"
>
> gs_mysecretpassphrase="KXhtctw4_zFfhRop"
>
> echo -e "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
> unset gs_mysecretpassphrase
>
> echo -e "Stuff to be encrypted." \
> | gpg --pinentry-mode loopback --passphrase-fd 3 -c 3< "${gs_myfifo}"
>
> rm "${gs_myfifo}"
>
>
> Of course, 'gs_mysecretpassphrase="KXhtctw4_zFfhRop"' would be replaced with some other mechanism of acquiring the passphrase. Perhaps via something such as:
>
> export GPG_TERM="${TERM}"
> echo -e "GETPIN\nBYE\n" \
> | pinentry --ttyname "${GPG_TTY}" \
> | sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //"
>
> On Thu, Mar 21, 2024 at 7:45?PM B.S. <bs27975 at gmail.com> wrote:
>>
>> At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
>> environment variable', there is a comment of "I don't see why we
>> should add yet more clumsy passphrase workarounds to gpg. We already
>> have PINENTRY_USER_DATA which can fulfill the same task."
>>
>> Can anyone give an example of doing so?
>>
>> I am looking to effect the equivalent of:
>> '@rem Get passhrase into (env.) var. programmatically (in your
>> favourite manner)'
>> 'set /p myenvpassphrase="Enter symmetric keyphrase to use:"
>> 'echo "Secret data" | gpg.exe -c --envpassphrase myenvpassphrase >
>> secretdata.gpg'
>> - thereby avoiding storing any passphrase (even temporarily) on a
>> storage medium, nor have it visible as the command line (via tasklist
>> or ps).
>> - in this case, the 'secret data' is actually confidential
>> information, piped from elsewhere, on the fly.
>>
>> Of course, the '-envpassphrase' option doesn't exist in gpg currently,
>> but the comment at the above link indicates that there is another way
>> to effect the same intent.
>>
>> Can anyone give an example of so doing?
>>
>> A current means of effecting the same is, of course, '--passphase-fd
>> 3", for something like:
>> 'echo "Secret data" | gpg.exe -c --passphrase-fd 3 3< echo %PASSWORD%
>> > secretdata.gpg'
>> - except I have no idea [in (Win 10) DOS, not powershell, cmd] how to
>> get anything into file descriptor 3.
>> = let alone get an echo into fd 3 (without actually landing on a
>> filesystem, even temporarily).
>>
>> Of course:
>> 'echo "Secret data" | gpg.exe -c --passphrase > secretdata.gpg'
>> - doesn't work, as stdin can't be 'in two places at once', both
>> passphrase input, and data input.
>> = Remember, "Secret data" isn't on disk, either - it's being piped in, too.
>>
>> Has anyone got a link to a working example of '3<' or
>> 'PINENTRY_USER_DATA which can fulfill the same task' of gpg picking up
>> its passphrase from an environment variable?



From wk at gnupg.org  Mon Apr 29 13:45:57 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 29 Apr 2024 13:45:57 +0200
Subject: Example of 'PINENTRY_USER_DATA which can fulfill the'
 (envpassphrase) 'task'?
In-Reply-To: <ECA2E24C-2143-4E28-AB46-615D0310FFC8.1@smtp-inbound1.duck.com>
 (Bee via Gnupg-users's message of "Mon, 29 Apr 2024 07:03:36 -0400")
References: <CAH9E=nXMQRhUAofXa1biL4mneDewivP6LsJwiHBsUHg+s9Tp2w@mail.gmail.com>
 <CAH9E=nWw8Ed_Mr=ehqauXKU9dnC4+xEq5Y8RO-yyba7fvJjNBA@mail.gmail.com>
 <ECA2E24C-2143-4E28-AB46-615D0310FFC8.1@smtp-inbound1.duck.com>
Message-ID: <8734r48k96.fsf@jacob.g10code.de>

On Mon, 29 Apr 2024 07:03, Bee said:

> But that environment is not passed and used by pinentry - it has no
> knowledge of them. PINENTRY_USER_DATA may exist, but it has no
> knowledge as to how to interpret it. Ergo, some other mechanism must

Its is called "USER DATA" for a reason - you have to decide what to do
with it.  If your really really want a passphrase, what about passing
the filename of a file holding the passphrase.  Or a socket or some
another secure IPC mechanism locator.

For unattended use the only reason for a passphrase - which protects the
private key against local users - are stupid policy requirements you
have to follow.  In all other cases, first come up with an attack tree
to show that a passphrase is of any use for your application.


Salam-Shalom,

   Werner

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

From omcujl92 at duck.com  Mon Apr 29 14:07:58 2024
From: omcujl92 at duck.com (omcujl92 at duck.com)
Date: Mon, 29 Apr 2024 08:07:58 -0400
Subject: Example of 'PINENTRY_USER_DATA which can fulfill the'
 (envpassphrase) 'task'?
References: <CAH9E=nXMQRhUAofXa1biL4mneDewivP6LsJwiHBsUHg+s9Tp2w@mail.gmail.com>
 <CAH9E=nWw8Ed_Mr=ehqauXKU9dnC4+xEq5Y8RO-yyba7fvJjNBA@mail.gmail.com>
 <8734r48k96.fsf@jacob.g10code.de>
 <ECA2E24C-2143-4E28-AB46-615D0310FFC8.1@smtp-inbound1.duck.com>
 <E70D9883-BD31-41EC-9456-66F05B58B895.1@smtp-inbound1.duck.com>
Message-ID: <6C0F43D2-15A0-4A2C-BB00-98507501F080.1@smtp-inbound1.duck.com>

> Its is called "USER DATA" for a reason - you have to decide what to do
> with it.

But a novel pinentry must be created to receive the data. Again, this
is circular.

> If your really really want a passphrase, what about passing
> the filename of a file holding the passphrase.

AGAIN, this requires clear text storage trying to be avoided in the
first place, or ... decrypting the encrypted file on the fly ... which
requires a passphrase to be passed ... and we're circular again.

>  Or a socket or some
> another secure IPC mechanism locator.

Or ... 3 lines of script in the example you seem to be ignoring?
mkfifo myfifo
secret="passphrase"
echo $secret > myfifo &
unset secret
echo "secret stuff" | gpg -c ... -fd 3 3< myfifo

> For unattended use

Unattended has not been mentioned.

> For unattended use the only reason for a passphrase - which protects the
> private key

There is no private key in any scenario listed here. The point has
been to avoid key infrastructure overhead entirely.
[Yes, the passphrase is the key, but that is irrelevant semantics for
purposes here.]

Again ... 'echo "secret stuff" | gpg -c ...'

Again, posting an actual workaround to the bottom of
https://dev.gnupg.org/T4154 would be very welcome, and websearch
visible to
those so looking.

- and the providing of such an example was the only purpose in writing
the message you responded to, first, today.

Saying the expressly desired use (e.g. dev.gnupg) is inappropriate is
specious and counter-productive. Clearly the use is intended, given
the presence of the word 'passphrase', even within 'man gpg'.


On Mon, Apr 29, 2024 at 7:44?AM Werner Koch
<wk_at_gnupg.org_omcujl92 at duck.com> wrote:
>
> On Mon, 29 Apr 2024 07:03, Bee said:
>
> > But that environment is not passed and used by pinentry - it has no
> > knowledge of them. PINENTRY_USER_DATA may exist, but it has no
> > knowledge as to how to interpret it. Ergo, some other mechanism must
>
> Its is called "USER DATA" for a reason - you have to decide what to do
> with it.  If your really really want a passphrase, what about passing
> the filename of a file holding the passphrase.  Or a socket or some
> another secure IPC mechanism locator.
>
> For unattended use the only reason for a passphrase - which protects the
> private key against local users - are stupid policy requirements you
> have to follow.  In all other cases, first come up with an attack tree
> to show that a passphrase is of any use for your application.



From jcb62281 at gmail.com  Tue Apr 30 02:14:40 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Mon, 29 Apr 2024 19:14:40 -0500
Subject: Example of 'PINENTRY_USER_DATA which can fulfill the'
 (envpassphrase) 'task'?
In-Reply-To: <6C0F43D2-15A0-4A2C-BB00-98507501F080.1@smtp-inbound1.duck.com>
References: <CAH9E=nXMQRhUAofXa1biL4mneDewivP6LsJwiHBsUHg+s9Tp2w@mail.gmail.com>
 <CAH9E=nWw8Ed_Mr=ehqauXKU9dnC4+xEq5Y8RO-yyba7fvJjNBA@mail.gmail.com>
 <8734r48k96.fsf@jacob.g10code.de>
 <ECA2E24C-2143-4E28-AB46-615D0310FFC8.1@smtp-inbound1.duck.com>
 <E70D9883-BD31-41EC-9456-66F05B58B895.1@smtp-inbound1.duck.com>
 <6C0F43D2-15A0-4A2C-BB00-98507501F080.1@smtp-inbound1.duck.com>
Message-ID: <663037F0.9090409@gmail.com>

Bee via Gnupg-users wrote:
>> Its is called "USER DATA" for a reason - you have to decide what to do
>> with it.
>>     
>
> But a novel pinentry must be created to receive the data. Again, this
> is circular.
>
>   
>> If your really really want a passphrase, what about passing
>> the filename of a file holding the passphrase.
>>     
>
> AGAIN, this requires clear text storage trying to be avoided in the
> first place, or ... decrypting the encrypted file on the fly ... which
> requires a passphrase to be passed ... and we're circular again.
>   

Yes, this is a fundamental limitation of public-key cryptography:  to 
decrypt a message or generate a signature, the private key must be 
available in cleartext.  Some would say that that is the point.

If you are trying to have some semblance of security with an unattended 
application, have you considered using a smartcard or HSM to store the key?


-- Jacob


From omcujl92 at duck.com  Tue Apr 30 04:23:29 2024
From: omcujl92 at duck.com (omcujl92 at duck.com)
Date: Mon, 29 Apr 2024 22:23:29 -0400
Subject: Example of 'PINENTRY_USER_DATA which can fulfill the'
 (envpassphrase) 'task'?
References: <CAH9E=nXMQRhUAofXa1biL4mneDewivP6LsJwiHBsUHg+s9Tp2w@mail.gmail.com>
 <CAH9E=nWw8Ed_Mr=ehqauXKU9dnC4+xEq5Y8RO-yyba7fvJjNBA@mail.gmail.com>
 <8734r48k96.fsf@jacob.g10code.de>
 <ECA2E24C-2143-4E28-AB46-615D0310FFC8.1@smtp-inbound1.duck.com>
 <E70D9883-BD31-41EC-9456-66F05B58B895.1@smtp-inbound1.duck.com>
 <663037F0.9090409@gmail.com>
 <6C0F43D2-15A0-4A2C-BB00-98507501F080.1@smtp-inbound1.duck.com>
 <50F7668A-D611-4207-8C76-16546913BCCD.1@smtp-inbound1.duck.com>
Message-ID: <8CBA319C-F767-486A-9538-62707F4724EC.1@smtp-inbound1.duck.com>

> Yes, this is a fundamental limitation of public-key cryptography:  to
decrypt a message or generate a signature, the private key must be
available in cleartext.  Some would say that that is the point.

But NOT necessarily saved in clear text to a storage medium.

Which is what >  Some would say that that is the point.

[And if not in clear text, then some mechanism such as 'gpg -d
-passphrase...' must be employed ... and we're circular back to the
point of this thread.]

> If you are trying to have some semblance of security with an unattended
application, have you considered using a smartcard or HSM to store the key?

[Again, unattended has not been an element herein. (Which doesn't mean
it is contraindicated.)]

If trying to avoid cleartext storage, and the infrastructure overhead
of key storage, inherently there is no tolerance for the overhead of a
smartcard or usb stewardship. And there is certainly no tolerance, and
probably no capacity, for the creation or maintenance of a customized
PINENTRY_USER_DATA (to receive the parameter) as T4154 suggests.

Elements such as 'gpg -c ...' exist, for reasonable reasons, or the
effort to code and document things such as passphrases would not have
been made in the first place.

I can understand, coming from the premise of 'public-key
cryptography', that the assumption and requirement of one's own
public-key storage infrastructure be in place. But the presence of
'passphrase' and 'gpg -c' notes that 'gpg' doesn't exist -only-
-within- a public-key storage infrastructure. And thank all for having
so. [This all matters because of the well deserved trust attached to
'gpg', its coding, its auditing, and every other good thing making it
the world's 'go to' for this stuff - including passphrase use. It's a
well known and trusted hammer, and everything herein IS a nail.
Inherently, one wants to stay within the facilities it provides (like
passphrases), rather than customize surroundings to be maintained that
break those predicates.]

Within the subject of this thread: "Example of 'PINENTRY_USER_DATA
which can fulfill the' (envpassphrase) 'task'?" I simply provided one
solution for later readers and web searchers.

[Avoiding everyone easily visible command line and scripted storage of
passphrase, and minimal time of visibility to sensitive data within a
processes superuser-only visible environment variable storage. tmpfs
being a memdisk and duration so short as to be unlikely to be swapped
to physical medium.]

If it is not entirely satisfactory, most certainly alternative
passphrase examples would be most appreciated.

And noted that appending an alternative workaround to the given patch
provided therein at https://dev.gnupg.org/T4154 would be useful to web
searchers.

On Mon, Apr 29, 2024 at 8:14?PM Jacob Bachmeyer
<jcb62281_at_gmail.com_omcujl92 at duck.com> wrote:
>
> Bee via Gnupg-users wrote:
> >> Its is called "USER DATA" for a reason - you have to decide what to do
> >> with it.
> >>
> >
> > But a novel pinentry must be created to receive the data. Again, this
> > is circular.
> >
> >
> >> If your really really want a passphrase, what about passing
> >> the filename of a file holding the passphrase.
> >>
> >
> > AGAIN, this requires clear text storage trying to be avoided in the
> > first place, or ... decrypting the encrypted file on the fly ... which
> > requires a passphrase to be passed ... and we're circular again.
> >
>
> Yes, this is a fundamental limitation of public-key cryptography:  to
> decrypt a message or generate a signature, the private key must be
> available in cleartext.  Some would say that that is the point.
>
> If you are trying to have some semblance of security with an unattended
> application, have you considered using a smartcard or HSM to store the key?
>
>
> -- Jacob