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: References: <87y1a2stow.fsf@cassou.me> <87sf07wv11.fsf@cassou.me> 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 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: (Andrew Gallagher via Gnupg-users's message of "Fri, 29 Mar 2024 13:00:38 +0000") References: <87ttkqg01x.fsf@jacob.g10code.de> 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: 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: <87ttkqg01x.fsf@jacob.g10code.de> <87sf04c9pm.fsf@jacob.g10code.de> Message-ID: <99950276-1E2F-4538-B192-FE0D0A7ABA4C@andrewg.com> On 2 Apr 2024, at 11:58, Werner Koch 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: 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: 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 > (.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: 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: <87ttkqg01x.fsf@jacob.g10code.de> <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: 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: <87ttkqg01x.fsf@jacob.g10code.de> <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 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: 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: <87ttkqg01x.fsf@jacob.g10code.de> <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: 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: <87ttkqg01x.fsf@jacob.g10code.de> <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 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: 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: 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: (Todd Zullinger via Gnupg-users's message of "Fri, 5 Apr 2024 00:04:25 -0400") References: 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: 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xCB9123D02A51C1D3.asc Type: application/pgp-keys Size: 7441 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: 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> <48137178-E30A-40A9-A3F9-AFEABAAE3845.1@smtp-inbound1.duck.com> Message-ID: 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 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: <87frw0b2wo.fsf@jacob.g10code.de> Message-ID: 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: References: <87frw0b2wo.fsf@jacob.g10code.de> <48137178-E30A-40A9-A3F9-AFEABAAE3845.1@smtp-inbound1.duck.com> Message-ID: 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: 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: 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: (Todd Zullinger via Gnupg-users's message of "Fri, 5 Apr 2024 13:03:35 -0400") References: <87frw0b2wo.fsf@jacob.g10code.de> 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: 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: (Moses via Gnupg-users's message of "Mon, 8 Apr 2024 02:38:17 +0000") References: 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: 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: <87v84s9t9i.fsf@jacob.g10code.de> Message-ID: -----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 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: 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: 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 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: (Moses via Gnupg-users's message of "Mon, 8 Apr 2024 11:42:03 +0000") References: <87v84s9t9i.fsf@jacob.g10code.de> 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 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: 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: (Dan Fandrich's message of "Mon, 8 Apr 2024 21:50:33 -0700") References: 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: 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: 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 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: <87v84s9t9i.fsf@jacob.g10code.de> <87a5m2am38.fsf@jacob.g10code.de> Message-ID: -----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 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 > > 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: (Moses via Gnupg-users's message of "Tue, 9 Apr 2024 12:21:36 +0000") References: <87v84s9t9i.fsf@jacob.g10code.de> <87a5m2am38.fsf@jacob.g10code.de> 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: 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: <875xwqalrg.fsf@jacob.g10code.de> Message-ID: 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: <87v84s9t9i.fsf@jacob.g10code.de> <87a5m2am38.fsf@jacob.g10code.de> <87il0qziop.fsf@jacob.g10code.de> Message-ID: -----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 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 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 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 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: (Moses via Gnupg-users's message of "Wed, 10 Apr 2024 05:35:04 +0000") References: <87v84s9t9i.fsf@jacob.g10code.de> <87a5m2am38.fsf@jacob.g10code.de> <87il0qziop.fsf@jacob.g10code.de> 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: 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: <87frw0b2wo.fsf@jacob.g10code.de> <871q7gbbac.fsf@jacob.g10code.de> Message-ID: 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: 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: (Todd Zullinger via Gnupg-users's message of "Wed, 10 Apr 2024 12:15:42 -0400") References: <87frw0b2wo.fsf@jacob.g10code.de> <871q7gbbac.fsf@jacob.g10code.de> 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: 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: <87v84s9t9i.fsf@jacob.g10code.de> <87a5m2am38.fsf@jacob.g10code.de> <87il0qziop.fsf@jacob.g10code.de> <875xwpp6yw.fsf@jacob.g10code.de> Message-ID: -----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 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: (Moses via Gnupg-users's message of "Thu, 11 Apr 2024 12:24:33 +0000") References: <87v84s9t9i.fsf@jacob.g10code.de> <87a5m2am38.fsf@jacob.g10code.de> <87il0qziop.fsf@jacob.g10code.de> <875xwpp6yw.fsf@jacob.g10code.de> 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: 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: 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: References: <87ttkqg01x.fsf@jacob.g10code.de> Message-ID: On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: 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: References: <87ttkqg01x.fsf@jacob.g10code.de> Message-ID: 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 wrote: > > On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users 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: References: <87ttkqg01x.fsf@jacob.g10code.de> Message-ID: <00C37A75-E93C-496D-801D-B9013576E1C6@andrewg.com> On 17 Apr 2024, at 15:43, Christian Sommer 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: 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: (Christian Sommer via Gnupg-users's message of "Wed, 17 Apr 2024 16:43:45 +0200") References: <87ttkqg01x.fsf@jacob.g10code.de> 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: 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: <87ttkqg01x.fsf@jacob.g10code.de> <87a5lqkht4.fsf@jacob.g10code.de> Message-ID: 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: 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: (Bruce Walzer's message of "Thu, 18 Apr 2024 10:26:39 -0500") References: <87ttkqg01x.fsf@jacob.g10code.de> <87a5lqkht4.fsf@jacob.g10code.de> 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: 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: 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: (Eric Pruitt via Gnupg-users's message of "Tue, 23 Apr 2024 21:39:16 -0700") References: 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: 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: <877cgngm1t.fsf@jacob.g10code.de> Message-ID: 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: References: Message-ID: 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: 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: 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. 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: 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: <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: 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: Message-ID: 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. 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. 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: (Bee via Gnupg-users's message of "Mon, 29 Apr 2024 07:03:36 -0400") References: 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: 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: <8734r48k96.fsf@jacob.g10code.de> 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 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: <8734r48k96.fsf@jacob.g10code.de> <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: <8734r48k96.fsf@jacob.g10code.de> <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 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