From kloecker at kde.org Fri Mar 1 17:06:09 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 01 Mar 2024 17:06:09 +0100 Subject: On the security of ~/.password-store/.gpg-id [was: Re: Second OpenPGP-card] In-Reply-To: <87plwf81ih.fsf@fifthhorseman.net> References: <2320106.ElGaqSPkdT@daneel> <87plwf81ih.fsf@fifthhorseman.net> Message-ID: <1883763.tdWV9SEqCh@daneel> On Donnerstag, 29. Februar 2024 21:21:42 CET Daniel Kahn Gillmor wrote: > human-readable names for certificates. But i don't see how to use that > safely while dealing with GnuPG's risky implementation choices here. Allowing recipients to be specified by email address (or some other part of a user ID) was inherited from PGP. And I guess it's part of the reason for the success of PGP (and GnuPG) that one could specify keys of recipients by email addresses instead of by hard to remember key IDs (when those could still be considered unique) or by impossible to remember fingerprints (or by file name as sequoia-pgp seems to prefer). Calling this a risky implementation choice of GnuPG is ridiculous. If anything then it's a risky implementation choice of pass to allow using anything other than a fingerprint in ~/.password-store/.gpg-id. 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 dkg at fifthhorseman.net Sat Mar 2 03:56:45 2024 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 Mar 2024 21:56:45 -0500 Subject: On the security of ~/.password-store/.gpg-id [was: Re: Second OpenPGP-card] In-Reply-To: <1883763.tdWV9SEqCh@daneel> References: <2320106.ElGaqSPkdT@daneel> <87plwf81ih.fsf@fifthhorseman.net> <1883763.tdWV9SEqCh@daneel> Message-ID: <87cysd8hoy.fsf@fifthhorseman.net> On Fri 2024-03-01 17:06:09 +0100, Ingo Kl?cker wrote: > On Donnerstag, 29. Februar 2024 21:21:42 CET Daniel Kahn Gillmor wrote: >> human-readable names for certificates. But i don't see how to use that >> safely while dealing with GnuPG's risky implementation choices here. > > Allowing recipients to be specified by email address (or some other > part of a user ID) was inherited from PGP. And I guess it's part of > the reason for the success of PGP (and GnuPG) that one could specify > keys of recipients by email addresses instead of by hard to remember > key IDs (when those could still be considered unique) or by impossible > to remember fingerprints (or by file name as sequoia-pgp seems to > prefer). I agree with you that it's nice to refer to people by human-memorable names. I just wish it was safe to do so. > Calling this a risky implementation choice of GnuPG is ridiculous. Is it really ridiculous? It seems factual to me. Note that I'm not saying GnuPG is the only one to make such an implementation choice, but I really do think it's risky. For example, GnuPG could instead offer an interface with explicit options to allow the user to choose to match certificates by fingerprint, or by e-mail address, or by name, or by full User ID, but not a mishmash of all of the above. > If anything then it's a risky implementation choice of pass to allow > using anything other than a fingerprint in ~/.password-store/.gpg-id. I agree, that's risky too! But as you say above (and as the message that i sent, but which doesn't appear to have been delivered to the list, also said), it's an understandable urge to want to use human-readable names. It seems totally reasonable to put my own own name there, for example! who knew that it could cause problems? Anyway, for `pass` to restrict the contents of .gpg-id to being a fingerprint, the GnuPG API(?) requires `pass` to know exactly how to match a fingerprint so that GnuPG also is also guaranteed to treat it as a fingerprint. If a new version of GnuPG ever accepts other forms of fingerprint, or requires a different form, then pass would need to be updated to match the new expectations. That seems clumsy, and likely to lead to upgrade friction down the line. I agree with you that these kinds of tools should let the user do the sort of things that users generally want to do. The tools should also let them do those things safely by default, and without confusion. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 324 bytes Desc: not available URL: From mysidia at gmail.com Sat Mar 2 07:02:59 2024 From: mysidia at gmail.com (Jay Acuna) Date: Sat, 2 Mar 2024 00:02:59 -0600 Subject: On the security of ~/.password-store/.gpg-id [was: Re: Second OpenPGP-card] In-Reply-To: <87cysd8hoy.fsf@fifthhorseman.net> References: <2320106.ElGaqSPkdT@daneel> <87plwf81ih.fsf@fifthhorseman.net> <1883763.tdWV9SEqCh@daneel> <87cysd8hoy.fsf@fifthhorseman.net> Message-ID: On Fri, Mar 1, 2024 at 8:57?PM Daniel Kahn Gillmor via Gnupg-users wrote: > I agree with you that it's nice to refer to people by human-memorable > names. I just wish it was safe to do so. I would consider it is safe to do so. It is in fact mostly the entire purpose of GPG to identify the correct certificates to send messages for you. If PGP did not choose the certificate for you, then it would just be Openssl; I.e. it would not be useful for the very purpose of the software. > > Calling this a risky implementation choice of GnuPG is ridiculous. > Is it really ridiculous? It seems factual to me. Note that I'm not It is not factual. > For example, GnuPG could instead offer an interface with explicit > options to allow the user to choose to match certificates by > fingerprint, or by e-mail address, or by name, or by full User ID, but > not a mishmash of all of the above. No.. either you trust the authenticity of the certificate, including the Email address, Name, and Full User IDs, or you don't. If you trust the certificate, then it should be safe to match it based on all the attributes. If you own a certificate that should no longer be trusted, then you should revoke it. Trust is determined based on the chain of Certificate signatures, and the contents of your Key storage indicating which certificate signers you trust. If your Public Key storage is compromised so that is configured to Trust certificates you should not, then so is that whole PGP installation. The Unsafe condition would be allowing yourself to have Public key storage containing certificates or signers you should not trust marked trusted. > > If anything then it's a risky implementation choice of pass to allow > > using anything other than a fingerprint in ~/.password-store/.gpg-id. Pass isn't part of GPG, so who knows whether what they are doing is safe or not. I would say inputting a full Key ID or e-mail address is safe enough. If your GPG Installation is so badly damaged that you have Incorrect keys marked trusted in your public key storage, then you should consider your whole software installation compromised. Software with a compromised installation (damaged binaries or config) would be inherently unsafe to use -- -J From wk at gnupg.org Sat Mar 2 12:17:53 2024 From: wk at gnupg.org (Werner Koch) Date: Sat, 02 Mar 2024 12:17:53 +0100 Subject: On the security of ~/.password-store/.gpg-id [was: Re: Second OpenPGP-card] In-Reply-To: <87cysd8hoy.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Fri, 01 Mar 2024 21:56:45 -0500") References: <2320106.ElGaqSPkdT@daneel> <87plwf81ih.fsf@fifthhorseman.net> <1883763.tdWV9SEqCh@daneel> <87cysd8hoy.fsf@fifthhorseman.net> Message-ID: <871q8syja6.fsf@jacob.g10code.de> On Fri, 1 Mar 2024 21:56, Daniel Kahn Gillmor said: > For example, GnuPG could instead offer an interface with explicit > options to allow the user to choose to match certificates by > fingerprint, or by e-mail address, or by name, or by full User ID, but Simply prefix the fingerprint with 0x and gpg will only consider fingerprints. RTFM. You know that very well given that you are the person who was so keen to be able to maintain a "curated" keyring. -- 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 mcepl at cepl.eu Sat Mar 2 20:54:46 2024 From: mcepl at cepl.eu (mcepl at cepl.eu) Date: Sat, 02 Mar 2024 20:54:46 +0100 Subject: [gpg-agent] Empty OPTION =?UTF-8?Q?xauthority=3D?= Message-ID: <2febd63a8596d872121f5d9bf417f676@cepl.eu> Hello, I am running MicroOS-based distro (which means read-only host and all work done in podman containers using distrobox). Because I am afraid gpg-agent got confused when it was started from inside a container, I am running it on host with systemd --user services (configuration according to https://wiki.archlinux.org/title/GnuPG#gpg-agent). When trying to decrypt a GPG-encrypted file on host, everything works fine, but when I try to decrypt a file in a container (or when using pass(1)) suddenly I get an error (it worked for months before, and I am really not certain what did change now): tumbleweed-pkg~$ LANG=en_GB.utf8 gpg --decrypt ~/.local/share/password-store/mozilla/identita.csob.cz.gpg gpg: encrypted with rsa4096 key, ID 77D15A36BD4211B2, created 2016-04-27 "Mat?j Cepl " gpg: Warning: not using 'D96484AC' as default key: No secret key gpg: Warning: not using '880BC9D8' as default key: No secret key gpg: all values passed to '--default-key' ignored gpg: keydb_search failed: IPC syntax error gpg: public key decryption failed: No secret key gpg: decryption failed: No secret key tumbleweed-pkg~$ When looking at log-file I see this: 2024-03-02 10:53:20 gpg-agent[2434] DBG: chan_10 <- OPTION xauthority= 2024-03-02 10:53:20 gpg-agent[2434] DBG: chan_10 -> ERR 67109140 Chyba syntaxe IPC - option argument expected 2024-03-02 10:53:20 gpg-agent[2434] DBG: chan_10 <- BYE (?Chyba syntaxe? means obviously ?A syntax error? in Czech). I have to admit I am a bit lost in that protocol log. Who is sending that ?OPTION xauhtor?ty=? line and what should be the right value of it, when running on Wayland (no Xorg around)? Thank you for any advice, Mat?j Cepl -- http://matej.ceplovi.cz/blog/, @mcepl at floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 [?] sleep is no substitute for caffeine. -- Robert Storey in review of Debian (when describing re-compilation of kernel :-)) From wk at gnupg.org Sun Mar 3 10:05:07 2024 From: wk at gnupg.org (Werner Koch) Date: Sun, 03 Mar 2024 10:05:07 +0100 Subject: [gpg-agent] Empty OPTION xauthority= In-Reply-To: <2febd63a8596d872121f5d9bf417f676@cepl.eu> (mcepl@cepl.eu's message of "Sat, 02 Mar 2024 20:54:46 +0100") References: <2febd63a8596d872121f5d9bf417f676@cepl.eu> Message-ID: <87sf17wurg.fsf@jacob.g10code.de> Hi! On Sat, 2 Mar 2024 20:54, mcepl at cepl.eu said: > am running it on host with systemd --user services (configuration Take care, the use of systemd is racy and support will be removed in 2.6. > gpg: all values passed to '--default-key' ignored > gpg: keydb_search failed: IPC syntax error (You may use --debug=ipc alsowith gpg to see what is going on) > 2024-03-02 10:53:20 gpg-agent[2434] DBG: chan_10 <- OPTION xauthority= gpg-gent receives this from gpg. Look: $ gpg-connect-agent > option xauthority= ERR 67109140 IPC syntax error - option argument expected > option xauthority OK gpg takes the value for xauthority from the envvar XAUTHORITY. In your case it seems that this envvar is set to the empty string which results in the above synax error. Using xauthority without a value and thus without the '=' removes the value from gpg-agent's environment. In theory it would be possible to ignore the empty string but given that we have the code this way for 20 year the risk of a regression is to high. Please figure out why XAUTHORITY is set to the empty sting. XAUTHORITY is only needed if you don't use ~/.Xauthority to store the X11 magic cookies; see xauth(1). 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 mcepl at cepl.eu Sun Mar 3 20:41:21 2024 From: mcepl at cepl.eu (=?utf-8?q?Mat=C4=9Bj_Cepl?=) Date: Sun, 03 Mar 2024 20:41:21 +0100 Subject: [gpg-agent] Empty OPTION xauthority= In-Reply-To: <87sf17wurg.fsf@jacob.g10code.de> References: <2febd63a8596d872121f5d9bf417f676@cepl.eu> <87sf17wurg.fsf@jacob.g10code.de> Message-ID: On Sun Mar 3, 2024 at 10:05 AM CET, Werner Koch wrote: > > am running it on host with systemd --user services (configuration > > Take care, the use of systemd is racy and support will be removed in > 2.6. 1. Could you please explain why it is racy? Why from all services only gpg is unsuitable for systemd treatment? It is just one socket as any other, isn?t it? Could you point to some issue ticket, email thread, blog post explaining the problem? 2. When running on MicroOS system (or Fedora Atomic) how could you guarantee that there is only one gpg-agent and gpg doesn't try to run it inside of a container, thus making it inacessible to other containers on the system (Flatpak or podman) and to the host system? I don't see any other solution than running permanently one gpg-agent on the host system open to everybody, which systemd --user service seems to provide nicely. > gpg takes the value for xauthority from the envvar XAUTHORITY. In your > case it seems that this envvar is set to the empty string which results > in the above synax error. Using xauthority without a value and thus > without the '=' removes the value from gpg-agent's environment. Yes, thank you for kicking me in the right direction, I found a bug in distrobox (https://github.com/89luca89/distrobox/pull/1252). > In theory it would be possible to ignore the empty string but given that > we have the code this way for 20 year the risk of a regression is to > high. What? You know there is a vulnerability in gpg (actually, couldn't the particularly modified environment be abused for some DoD style attack?) and you don't want to fix it, because you had that bug there long enough? I probably do not understand what you were trying to say. > Please figure out why XAUTHORITY is set to the empty sting. > XAUTHORITY is only needed if you don't use ~/.Xauthority to store the > X11 magic cookies; see xauth(1). I have Wayland-only system (based on sway), so whole XAUTH* variables are nonsensical here. Best, Mat?j -- http://matej.ceplovi.cz/blog/, @mcepl at floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Monday, December 9th. We skip the bus tour of Stockholm to attend the economics lecture. Our guest status is again good for front row seats. We hear about the theory of auctions. There are integrals and derivatives. It?s like physics except physics works. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From mcepl at cepl.eu Sun Mar 3 20:38:57 2024 From: mcepl at cepl.eu (=?utf-8?q?Mat=C4=9Bj_Cepl?=) Date: Sun, 03 Mar 2024 20:38:57 +0100 Subject: [gpg-agent] Empty OPTION xauthority= In-Reply-To: <87sf17wurg.fsf@jacob.g10code.de> References: <2febd63a8596d872121f5d9bf417f676@cepl.eu> <87sf17wurg.fsf@jacob.g10code.de> Message-ID: On Sun Mar 3, 2024 at 10:05 AM CET, Werner Koch wrote: > > am running it on host with systemd --user services (configuration > > Take care, the use of systemd is racy and support will be removed in > 2.6. 1. Could you please explain why it is racy? Why from all services only gpg is unsuitable for systemd treatment? It is just one socket as any other, isn?t it? Could you point to some issue ticket, email thread, blog post explaining the problem? 2. When running on MicroOS system (or Fedora Atomic) how could you guarantee that there is only one gpg-agent and gpg doesn't try to run it inside of a container, thus making it inacessible to other containers on the system (Flatpak or podman) and to the host system? I don't see any other solution than running permanently one gpg-agent on the host system open to everybody, which systemd --user service seems to provide nicely. > gpg takes the value for xauthority from the envvar XAUTHORITY. In your > case it seems that this envvar is set to the empty string which results > in the above synax error. Using xauthority without a value and thus > without the '=' removes the value from gpg-agent's environment. Yes, thank you for kicking me in the right direction, I found a bug in distrobox (https://github.com/89luca89/distrobox/pull/1252). > In theory it would be possible to ignore the empty string but given that > we have the code this way for 20 year the risk of a regression is to > high. What? You know there is a vulnerability in gpg (actually, couldn't the particularly modified environment be abused for some DoD style attack?) and you don't want to fix it, because you had that bug there long enough? I probably do not understand what you were trying to say. > Please figure out why XAUTHORITY is set to the empty sting. > XAUTHORITY is only needed if you don't use ~/.Xauthority to store the > X11 magic cookies; see xauth(1). I have Wayland-only system (based on sway), so whole XAUTH* variables are nonsensical here. Best, Mat?j -- http://matej.ceplovi.cz/blog/, @mcepl at floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Monday, December 9th. We skip the bus tour of Stockholm to attend the economics lecture. Our guest status is again good for front row seats. We hear about the theory of auctions. There are integrals and derivatives. It?s like physics except physics works. -------------- next part -------------- A non-text attachment was scrubbed... Name: E09FEF25D96484AC.asc Type: application/pgp-keys Size: 45433 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From wk at gnupg.org Mon Mar 4 09:13:14 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2024 09:13:14 +0100 Subject: [gpg-agent] Empty OPTION xauthority= In-Reply-To: (=?utf-8?Q?=22Mat=C4=9Bj?= Cepl"'s message of "Sun, 03 Mar 2024 20:38:57 +0100") References: <2febd63a8596d872121f5d9bf417f676@cepl.eu> <87sf17wurg.fsf@jacob.g10code.de> Message-ID: <87le6ywh2d.fsf@jacob.g10code.de> On Sun, 3 Mar 2024 20:38, Mat?j Cepl said: > 1. Could you please explain why it is racy? Why from all services Because all components of gnupg will start gpg-agent and the other daemons oin the fly and make sure that only one is started. Systemd does not know about this specific start mechanism and thus you might see two daemon processes for some time until their self-check detects this situation. In most cases this is just a annoying but it may very well happen that the two processes receove different information and are not abale to properly handle the caching. With smartcards you may also run into lockups becuase only one process may hold access to a smartcard. With keyboxd we even didn't implement the systemd start thingy because keyboxd acquires a process lifetime lock on the database and thus a second process won't be abale to get that lock and timeout after some time. > 2. When running on MicroOS system (or Fedora Atomic) how could > you guarantee that there is only one gpg-agent and gpg > doesn't try to run it inside of a container, thus making it I have no idea what this is about. In case you need to play interesting games with the sockets, the gpgconf.ctl mechanism might be helpful. Using no-autostart in the common.conf might be useful. We use it always when running a remote gpg. > What? You know there is a vulnerability in gpg (actually, > couldn't the particularly modified environment be abused for some Please read again what I wrote: An empty string for the value is simply invalid syntax. That is different from not giving a value which is specified as removing the envvar (cf. "" vs. NULL). > I have Wayland-only system (based on sway), so whole XAUTH* > variables are nonsensical here. Others might be: $ gpg-connect-agent 'getinfo std_env_names' /bye D GPG_TTY D TERM D DISPLAY D XAUTHORITY D XMODIFIERS D WAYLAND_DISPLAY D XDG_SESSION_TYPE D QT_QPA_PLATFORM D GTK_IM_MODULE D DBUS_SESSION_BUS_ADDRESS D QT_IM_MODULE D INSIDE_EMACS D PINENTRY_USER_DATA D PINENTRY_GEOM_HINT 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 bostrom.richardh at proton.me Mon Mar 4 07:11:33 2024 From: bostrom.richardh at proton.me (Richard Bostrom) Date: Mon, 04 Mar 2024 06:11:33 +0000 Subject: No secret key Message-ID: <0uhMLAzzgK6fVBndpJ2fOnkMMv7jjG7c21sJo4o5vng6GR2asGq2ULoghWng1BbGCr9NhQpZ0ugsFg2RHDb0J5z9uV1nzVF4tO-5uhhWUmo=@proton.me> Sirs and ladie! I received this message when using --clear-sign. gpg: no default secret key: No secret key gpg: clear-sign dialed: No secret key Both my public and private key has been imported. The key was made with a different user (as sudo)The current user is a non-sudo user. Yours truly Richardh Bostrom Sent with [Proton Mail](https://proton.me/) secure email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tl at stonemx.de Mon Mar 4 12:03:41 2024 From: tl at stonemx.de (Tobias Leupold) Date: Mon, 04 Mar 2024 12:03:41 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? Message-ID: <2174068.KiezcSG77Q@ginuog> Hi all :-) Apparently, there are some problems with the new defaults that are set when one creates a PGP key using a recent version of GnuPG (2.4). I ran into this after generating a new ECC/ED25519 key to replace my "old" RSA one. The problem showed up when I re-encrypted my pass password store passwords with the new key: After transferring the key to my Android phone and importing it into OpenKeychain, I could not decrypt any passwords anymore. After some research, I found https://github.com/open-keychain/open-keychain/issues/2886 , describing this exact issue. As a possible fix, disabling the unsupported AEAD mechanism in the key itself was mentioned, the Arch folks write: https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism They also claim that "many downstreams attempt to remove this new default by patching the GnuPG sources". I'm not that deep into cryptography. I'm not sure I completely grasp what AEAD and OCB mean. So: Is it wise and/or necessary to disable that for new GnuPG generated keys, for the sake of interoperability? Or will the others catch up and implement it? Or is there a good reason not to do so? Should one keep using legacy RSA keys? Is it too early to switch to more modern ones? Thanks to all cryptography experts for all clarification! Cheers, Tobias From Eva.Bolten at gnupg.com Mon Mar 4 16:12:50 2024 From: Eva.Bolten at gnupg.com (Eva Bolten) Date: Mon, 04 Mar 2024 16:12:50 +0100 Subject: No secret key In-Reply-To: <0uhMLAzzgK6fVBndpJ2fOnkMMv7jjG7c21sJo4o5vng6GR2asGq2ULoghWng1BbGCr9NhQpZ0ugsFg2RHDb0J5z9uV1nzVF4tO-5uhhWUmo=@proton.me> References: <0uhMLAzzgK6fVBndpJ2fOnkMMv7jjG7c21sJo4o5vng6GR2asGq2ULoghWng1BbGCr9NhQpZ0ugsFg2RHDb0J5z9uV1nzVF4tO-5uhhWUmo=@proton.me> Message-ID: <5048581.znia3AlyCT@jackson> Hi, First of all: The usual procedure when asking for advice is to tell us which gpg version you are using. And on which operation system. But it seems likely that in this case the info is not necessary. > I received this message when using --clear-sign. > gpg: no default secret key: No secret key > gpg: clear-sign dialed: No secret key Please always post complete gpg comand lines and the corresponding output - you can of course obfuscate names and other personal info. I assume you have entered something like: gpg --clear-sign test.txt without specifiying the key to use on the command line and no default key defined in you gpg.conf. The gpg man page describes how to specify that key: --clearsign Make a cleartext signature. The content in a cleartext sig? nature is readable without any special software. OpenPGP software is only needed to verify the signature. cleartext signatures may modify end-of-line whitespace for platform in? dependence and are not intended to be reversible. The sign? ing key is chosen by default or can be set explicitly using the --local-user and --default-key options Therefore, If you did not set a default key in your gpg.conf, you have to provide the key to use on the command line as described. Regards Eva From wk at gnupg.org Mon Mar 4 16:16:08 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2024 16:16:08 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <2174068.KiezcSG77Q@ginuog> (Tobias Leupold via Gnupg-users's message of "Mon, 04 Mar 2024 12:03:41 +0100") References: <2174068.KiezcSG77Q@ginuog> Message-ID: <87ttlmuix3.fsf@jacob.g10code.de> On Mon, 4 Mar 2024 12:03, Tobias Leupold said: > So: Is it wise and/or necessary to disable that for new GnuPG generated keys, > for the sake of interoperability? Or will the others catch up and implement No, it is not because you are delaying the deployment of new and a much faster algorithm mode. Although OpenPGP provides a nice preference system to convey the capabilities of your software it has the obvious problem that you need to change the preferences when moving to another software. In fact gpg has always asked you to update the preferences if it detected a different set. Using the same key with different software is and will always be problematic. I would also consider the security drawbacks of doing so. The attack surface of an Android phone is far higher than of your well maintained Unix or Windows desktop. Thus it may be useful to reflect this by using different keys or at least subkeys. All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js) took great care to first deploy the software with support for the new mode before actually creating keys with a preference for that mode [1]. Unfortunately a small group of people seem to sabotage this strategy by rejecting the new mode despite that it has been implemented by their crypto library. Well, or your version on Android is too old - which would indicate a severe security problem anyway. > it? Or is there a good reason not to do so? Should one keep using legacy RSA > keys? Is it too early to switch to more modern ones? RSA has nothing to do with this. You can safely switch to curve25519 (ed25519/cv25519) for new keys - they are supported even longer than OCB mode (aka AEAD). Salam-Shalom, Werner [1] OCB (AEAD) decryption implemented by GnuPG with versions: 2.3.0-beta (January 2018) - interop tested with RNP and OpenPGP.js 2.3.0 (April 2021) 2.2.21 (July 2021) -- 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 Mar 4 16:24:57 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2024 16:24:57 +0100 Subject: [gpg-agent] Empty OPTION xauthority= In-Reply-To: (=?utf-8?Q?=22Mat=C4=9Bj?= Cepl"'s message of "Mon, 04 Mar 2024 14:19:35 +0100") References: <2febd63a8596d872121f5d9bf417f676@cepl.eu> <87sf17wurg.fsf@jacob.g10code.de> <87le6ywh2d.fsf@jacob.g10code.de> Message-ID: <87plwauiie.fsf@jacob.g10code.de> On Mon, 4 Mar 2024 14:19, Mat?j Cepl said: > Do I understand it correctly that gnupg contains smaller version > of systemd (dependency activation) inside of itself and that No. It is not required. Just don't let systemd start gpg-agent or dirmngr with option --supervised. If you use ssh just make sure that gpg-agent has been started - this is the same as with ssh-agent. > MicroOS by openSUSE (and Fedora Atomic and many others, > every Linux distro has its own variant of this, I guess) are > container-oriented systems, where only minimal host system > is used to run multiple isolated containers (Docker/Podman, > distrobox, or Flatpak). SELinux and other methods are used to I see. We once looked into running a gpg-agent under a different account and with the right glue it should work. Definitely needs some more work but given that remote use works, it should not be a major hassle. The gpgconf.ctl hack might come handy to force the use of a different socket directory - see the latest gpgconf man page. Depends on how things are actually done. There is even a --chuid option to gpgconf to handle things for a user during session startup. 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 mcepl at cepl.eu Mon Mar 4 14:19:35 2024 From: mcepl at cepl.eu (=?utf-8?q?Mat=C4=9Bj_Cepl?=) Date: Mon, 04 Mar 2024 14:19:35 +0100 Subject: [gpg-agent] Empty OPTION xauthority= In-Reply-To: <87le6ywh2d.fsf@jacob.g10code.de> References: <2febd63a8596d872121f5d9bf417f676@cepl.eu> <87sf17wurg.fsf@jacob.g10code.de> <87le6ywh2d.fsf@jacob.g10code.de> Message-ID: On Mon Mar 4, 2024 at 9:13 AM CET, Werner Koch wrote: > Because all components of gnupg will start gpg-agent and the other > daemons oin the fly and make sure that only one is started. Do I understand it correctly that gnupg contains smaller version of systemd (dependency activation) inside of itself and that clashes with systemd? Is there some way how to switch it off and to make individual parts of gnupg behaving just The Unix Way?, do one thing (cryptographic operations, gpg-agenting or whatever) and do it well? > I have no idea what this is about. In case you need to play interesting > games with the sockets, the gpgconf.ctl mechanism might be helpful. MicroOS by openSUSE (and Fedora Atomic and many others, every Linux distro has its own variant of this, I guess) are container-oriented systems, where only minimal host system is used to run multiple isolated containers (Docker/Podman, distrobox, or Flatpak). SELinux and other methods are used to keep these containers isolated from the host system and one from another, sockets are under proper circumstances accessible. > Using no-autostart in the common.conf might be useful. We use it always > when running a remote gpg. That looks interesting, I will look into that. Best, Mat?j -- http://matej.ceplovi.cz/blog/, @mcepl at floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Ludwig Boltzmann, who spent much of his life studying statistical mechanics, died in 1906, by his own hand. Paul Ehrenfest, carrying on the work, died similarly in 1933. Now it is our turn to study statistical mechanics. -- David L. Goodstein ?States of Matter? -------------- next part -------------- A non-text attachment was scrubbed... Name: E09FEF25D96484AC.asc Type: application/pgp-keys Size: 45433 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From mcepl at cepl.eu Mon Mar 4 15:34:50 2024 From: mcepl at cepl.eu (=?utf-8?q?Mat=C4=9Bj_Cepl?=) Date: Mon, 04 Mar 2024 15:34:50 +0100 Subject: Your message to Gnupg-users awaits moderator approval In-Reply-To: References: Message-ID: On Mon Mar 4, 2024 at 2:19 PM CET, gnupg-users-owner wrote: > Your mail to 'Gnupg-users' with the subject > > Re: [gpg-agent] Empty OPTION xauthority= > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Message body is too big: 63276 bytes with a limit of 40 KB > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > https://lists.gnupg.org/mailman/confirm/gnupg-users/c419b7597f95abe2ff1d83ed3340aeb711643a59 Hi, I have enabled in my email client the feature attaching signing key and I thought that the attachment is just few (in single units) kB long, but suddenly I am getting the warning messages like this one. My key has been signed by 60+ signatures, but still 45K just for that seems excessive. Is there some way how to generate something meaningful, which would be smaller? Best, Mat?j -- http://matej.ceplovi.cz/blog/, @mcepl at floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A philosopher like Plato, according to Luther?s colorful imagery, remains like a cow who looks at a new door, refusing to enter? -------------- next part -------------- A non-text attachment was scrubbed... Name: E09FEF25D96484AC.asc Type: application/pgp-keys Size: 45433 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From tl at stonemx.de Mon Mar 4 19:05:03 2024 From: tl at stonemx.de (Tobias Leupold) Date: Mon, 04 Mar 2024 19:05:03 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <87ttlmuix3.fsf@jacob.g10code.de> References: <2174068.KiezcSG77Q@ginuog> <87ttlmuix3.fsf@jacob.g10code.de> Message-ID: <2482234.uoxibFcf9D@ginuog> Hi Werner, thanks for the clarification! > All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js) > took great care to first deploy the software with support for the new > mode before actually creating keys with a preference for that mode [1]. > Unfortunately a small group of people seem to sabotage this strategy by > rejecting the new mode despite that it has been implemented by their > crypto library. Well, or your version on Android is too old - which > would indicate a severe security problem anyway. This is not about (my) Android (version), I think this is more about OpenKeychain (still) not having implemented this. For whatever reason. However, I filed an issue for that: https://github.com/open-keychain/open-keychain/issues/2900 IMO interoperability with GnuPG is crucial for this project. Most people using that on their phones will come from Linux, or they will at least be GnuPG users. Let's hope for the best ... > RSA has nothing to do with this. You can safely switch to curve25519 > (ed25519/cv25519) for new keys - they are supported even longer than OCB > mode (aka AEAD). Good to know! From bwalzer at 59.ca Mon Mar 4 21:53:26 2024 From: bwalzer at 59.ca (Bruce Walzer) Date: Mon, 4 Mar 2024 14:53:26 -0600 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <2174068.KiezcSG77Q@ginuog> References: <2174068.KiezcSG77Q@ginuog> Message-ID: On Mon, Mar 04, 2024 at 12:03:41PM +0100, Tobias Leupold via Gnupg-users wrote: [...] > After some research, I found > > https://github.com/open-keychain/open-keychain/issues/2886 , > > describing this exact issue. That would be the cipher block mode proliferation issue. > As a possible fix, disabling the unsupported AEAD > mechanism in the key itself was mentioned, the Arch folks write: > > https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism Thank you for this. Up to now I did not know how to do this for GnuPG. > > They also claim that "many downstreams attempt to remove this new default by > patching the GnuPG sources". I don't know if this is true, but I would not be surprised. It turns out that the current existing cipher block mode (OCFB-MDC, SEIP) is cryptographically secure, even though there are lot of misleading legends that insist that it is not. So as a user, I have no incentive to use another block mode unless I want higher encryption performance or different error handling. Few users actually want or need those features. All users want interoperability. That, after all, is why the OpenPGP standard exists. People with special needs normally use dedicated encryption utilities with no interoperability with anything else. > > I'm not that deep into cryptography. I'm not sure I completely grasp what AEAD > and OCB mean. Just different terms for the same new and incompatible cipher block mode for the purposes of this discussion. > > So: Is it wise and/or necessary to disable that for new GnuPG generated keys, > for the sake of interoperability? Ah... That question leads to an awkward discussion these days. There was a IETF standards process that led to the OCB mode now supported by GnuPG and others. GnuPG (and others) implemented it before the new standard was officially released (there seemed to be consensus). That standards process then dropped the GnuPG OCB mode and created 3 new modes. So currently, there are the two modes that the OpenPGP standard currently specifies and four proposed modes for a total of 6 modes, each completely incompatible with any other mode. So there is a potential for a interoperability disaster here. > Or will the others catch up and implement it? Which mode(s) should they implement? There are at least two factions. It seems unlikely that any faction will implement the other faction's modes. > Or is there a good reason not to do so? At this point I personally believe that everyone should step back from this potential war and stop generating new modes by default. As a user I can happily wait until an actual consensus is reached. Heck, I can happily wait past that. There is no hurry here. The big usability problem now is that the implementations are not making all this clear. GnuPG for instance doesn't even have an entry in the FAQ about this problem. Most users will not be able to overcome this sort of issue and will have to just give up. Anyway, I wrote a whole rant about this: * https://articles.59.ca/doku.php?id=pgpfan:schism I have added your Openkeychain references to my list of problems caused by new OpenPGP cipher block modes. Thanks. * https://articles.59.ca/doku.php?id=pgpfan:noae_shame Bruce From tl at stonemx.de Mon Mar 4 22:37:29 2024 From: tl at stonemx.de (Tobias Leupold) Date: Mon, 04 Mar 2024 22:37:29 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: References: <2174068.KiezcSG77Q@ginuog> Message-ID: <2265949.KTMopqUuYO@ginuog> > Ah... That question leads to an awkward discussion these days. There > was a IETF standards process that led to the OCB mode now supported by > GnuPG and others. GnuPG (and others) implemented it before the new > standard was officially released (there seemed to be consensus). That > standards process then dropped the GnuPG OCB mode and created 3 new > modes. So currently, there are the two modes that the OpenPGP standard > currently specifies and four proposed modes for a total of 6 modes, > each completely incompatible with any other mode. So there is a > potential for a interoperability disaster here. > At this point I personally believe that everyone should step back from > this potential war and stop generating new modes by default. As a user > I can happily wait until an actual consensus is reached. Heck, I can > happily wait past that. There is no hurry here. Oh my. So the answer to my question "Should one really disable AEAD for recent GnuPG created PGP keys" (or OCB/AEAD or whatever) is maybe "yes" after all ... I mean, it's hard enough for most people to use public key encryption at all. Even if there are no interoperability issues. Maybe, one should agree on the lowest common denominator here. I encrypt passwords, sign software releases and sometimes (rarely), I encrypt an email. A text email. Which is like 4 KB or such. So, for me, I see no performance problem for my use-case. > The big usability problem now is that the implementations are not > making all this clear. GnuPG for instance doesn't even have an entry > in the FAQ about this problem. Most users will not be able to overcome > this sort of issue and will have to just give up. ... like most of them do anyway, when it comes to public key cryptography. > Anyway, I wrote a whole rant about this: > > * https://articles.59.ca/doku.php?id=pgpfan:schism > > I have added your Openkeychain references to my list of problems > caused by new OpenPGP cipher block modes. Thanks. > > * https://articles.59.ca/doku.php?id=pgpfan:noae_shame Thanks for this reference! Cheers, Tobias From look at my.amazin.horse Tue Mar 5 00:23:46 2024 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 5 Mar 2024 00:23:46 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: References: <2174068.KiezcSG77Q@ginuog> Message-ID: <8ecc3811-722d-4de6-ace3-2aa87690f31c@my.amazin.horse> Hey Bruce, On 04.03.24 21:53, Bruce Walzer wrote: > * https://articles.59.ca/doku.php?id=pgpfan:noae_shame There is more if you search for it: https://kagi.com/search?q=gpg+%22packet+type+20%22&r=no_region&sh=HeSUA3hoI5SeCuA2TTrNig Cheers - V From look at my.amazin.horse Tue Mar 5 00:16:45 2024 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 5 Mar 2024 00:16:45 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <87ttlmuix3.fsf@jacob.g10code.de> References: <2174068.KiezcSG77Q@ginuog> <87ttlmuix3.fsf@jacob.g10code.de> Message-ID: Hey list, OpenKeychain maintainer here. As Werner chose to omit some details here that seem pertinent, I will add: > No, it is not because you are delaying the deployment of new and a much > faster algorithm mode. The packet format referred to here is GnuPG-specific. In November 2023, GnuPG forked the OpenPGP standard as "LibrePGP", in protest of the upcoming OpenPGP revision. See https://librepgp.org/ LibrePGP specifies the packet format that GnuPG now emits by default. However, this packet format will be different from the upcoming RFC specifying the next OpenPGP revision. You can find the LibrePGP mailing list here: https://lists.gnupg.org/pipermail/librepgp-discuss/ > Unfortunately a small group of people seem to sabotage this strategy > by rejecting the new mode despite that it has been implemented by > their crypto library. The "small group of people" that Werner is accusing of sabotage here is the IETF OpenPGP working group, and implementations that choose to implement the new OpenPGP RFC over LibrePGP. The background on this whole ordeal is complicated to say the least, but it is well established that the points of contention are rooted in personal conflict, and thus by nature extremely difficult to work with. > All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js) > took great care to first deploy the software with support for the new > mode before actually creating keys with a preference for that mode [1]. Ultimately, as a user you can currently choose between a format that will not be part of the upcoming RFC, but is supported by GnuPG (and many other implementations, including those mentioned above). Or a format that will be standardized as an RFC, but is not supported by GnuPG (but many other implementations, including all mentioned above). Due to this situation, many distributors (at least: Thunderbird, Debian, Arch, Fedora, NixOS, GPG Suite for macOS) have decided to hold back emission of the LibrePGP packet format for now. OpenKeychain will also follow suit here. Cheers - V From tl at stonemx.de Tue Mar 5 08:42:11 2024 From: tl at stonemx.de (Tobias Leupold) Date: Tue, 5 Mar 2024 08:42:11 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: References: <2174068.KiezcSG77Q@ginuog> <87ttlmuix3.fsf@jacob.g10code.de> Message-ID: <31296c11-9241-4c87-b4cd-dbd55fe873e4@stonemx.de> Hi Vincent! Thanks a lot for this insight! When it comes to encryption, I would consider myself a "power user", but still a user. I never heard of all this until now. What I, from the perspective of an end-user, saw was: I generate a new key. And then: "Pass no work on me phone anymore, OpenKeychain bad!" ;-) This whole thing is awkward. As a normal user, you currently have no chance to even know this. So, is what they propose in the Arch wiki the way to go to stick to non-embattled interoperable settings? (setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP)? I see the rationale for a performant block cipher. But that's nothing I need for my use-case; there's simply no advantage at all. Most probably for most users. So if there's no broad consensus about this, such an option should be hidden behind some "expert" flag, for people knowing what they do, and who are willing to trade off interoperability for performance. It should not be a default setting letting users like me run into problems they can't grasp without deep research. I don't want to join a "faction". I don't want to participate in a religious war. I just want to use encryption ... I'll file a Gentoo bug about this and see what the devs/maintainers say. Cheers, Tobias From wk at gnupg.org Tue Mar 5 09:40:42 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Mar 2024 09:40:42 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: (Vincent Breitmoser via Gnupg-users's message of "Tue, 5 Mar 2024 00:16:45 +0100") References: <2174068.KiezcSG77Q@ginuog> <87ttlmuix3.fsf@jacob.g10code.de> Message-ID: <87le6xul4l.fsf@jacob.g10code.de> On Tue, 5 Mar 2024 00:16, Vincent Breitmoser said: > The packet format referred to here is GnuPG-specific. In November Vincent, please stop spreading wrong facts. That is not a GnuPG specific but an agreed upon format by the participants of the OpenPGP WG and implemented by all major implementations. This was done in the same way we handle that since 1997 - the implementers agreed upon some format, implemented it and later described it some draft document. For example the current AEAD mode (CFB+MDC) was agreed upon in the year 2000 and implemented by both existing implementations (PGP and GnuPG). If took then 8 years before it was codified in an RFC. Same thing for modern ECC curves - implemented by everyone but no detailed specs out there. Modern AEAD mode (OCB) was specified and cross-tested in 2018 but some people, driving their own agenda, dropped that in fall 2021 and came up with another format with no solid reason. Bruce: I understand your claims and we have been very careful not to break anything when implementing a modern mode. That mode is really required because the old CFB+MDC is slow and policy makers don';t like it because it is not on their list of modern algorithms. The problem here is that group of newcomers with their niche implementations who want to gain an advantage compared to the existing implementations. Unfortunately supported by a few people like Vincent who patch out things or don't use their existing stuff. OTOH, it is not a real problem because they are, well, niche implementations, albeit with a loud voice. > 2023, GnuPG forked the OpenPGP standard as "LibrePGP", in protest of Right, Ribose and GnuPG came up with that site to explain what was going wrong and to have a descriptive name for the actual OpenPGP standard in current use. All has been said and there is no need to continue spreading wrong facts from your rebellion group aiming to discredit the most widely used standard for mail and data encryption. Please go to your own list and continue there. Here is no place to repeat that. My last word on this on this ML. 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 Mar 5 09:43:06 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Mar 2024 09:43:06 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <2482234.uoxibFcf9D@ginuog> (Tobias Leupold via Gnupg-users's message of "Mon, 04 Mar 2024 19:05:03 +0100") References: <2174068.KiezcSG77Q@ginuog> <87ttlmuix3.fsf@jacob.g10code.de> <2482234.uoxibFcf9D@ginuog> Message-ID: <87h6hlul0l.fsf@jacob.g10code.de> On Mon, 4 Mar 2024 19:05, Tobias Leupold said: > IMO interoperability with GnuPG is crucial for this project. Most > people using that on their phones will come from Linux, or they will Actually most users will come from Windows ;-) 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 Mar 5 09:47:33 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Mar 2024 09:47:33 +0100 Subject: Your message to Gnupg-users awaits moderator approval In-Reply-To: (=?utf-8?Q?=22Mat=C4=9Bj?= Cepl"'s message of "Mon, 04 Mar 2024 15:34:50 +0100") References: Message-ID: <87cys9ukt6.fsf@jacob.g10code.de> On Mon, 4 Mar 2024 15:34, Mat?j Cepl said: > like this one. My key has been signed by 60+ signatures, but > still 45K just for that seems excessive. Is there some way how to > generate something meaningful, which would be smaller? gpg --export -a --export-options export-minimal FOO >foo.asc this keeps just your self-signatures. There are other ways too but they are more complicated. Ley me quickly raise the limit on the mailing list. I has been setup a loooong time ago. I guess 100k should be sufficient. BTW, thanks to the nice folks who silently do their moderator jobs for years and years. 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 tl at stonemx.de Tue Mar 5 12:39:02 2024 From: tl at stonemx.de (Tobias Leupold) Date: Tue, 05 Mar 2024 12:39:02 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <87le6xul4l.fsf@jacob.g10code.de> References: <2174068.KiezcSG77Q@ginuog> <87le6xul4l.fsf@jacob.g10code.de> Message-ID: <3762036.VQhiAETyHQ@ginuog> Sorry for asking another thing about this. For sure, I didn't want to set off an avalanche, and I still don't want to. But from a user's perspective, this is simply very confusing and also unsettling. I think that somewhere, there should be some documentation, FAQ or whatever, as a definitive source for the correct facts. Because we have this statement: > That is not a GnuPG specific but an agreed upon format by the participants > of the OpenPGP WG and implemented by all major implementations. Which does not match what others say (apart from Vincent's statement) ... e.g. I also asked for what to do on Stack Exchange: https://security.stackexchange.com/questions/275883/should-one-really-disable-aead-for-recent-gnupg-created-pgp-keys The answer started with: > While authenticated encryption (AEAD) is good - especially for something > like OpenPGP, which is an old and over-complicated standard that has a > concerning large attack surface for vulnerabilities or simple implementation > errors - I definitely can't recommend enabling a non-standardized > compatibility-breaking feature by default, and frankly feel that GnuPG made > a major error in doing so from somebody with an impressive reputation on the network, for whom I suppose he knows what he's talking about. So: Is this standardized, or is it not? As said: I don't want to provoke a flame war. I'm just interested in objective facts ... From wk at gnupg.org Tue Mar 5 14:56:52 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Mar 2024 14:56:52 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <3762036.VQhiAETyHQ@ginuog> (Tobias Leupold via Gnupg-users's message of "Tue, 05 Mar 2024 12:39:02 +0100") References: <2174068.KiezcSG77Q@ginuog> <87le6xul4l.fsf@jacob.g10code.de> <3762036.VQhiAETyHQ@ginuog> Message-ID: <878r2wvl23.fsf@jacob.g10code.de> Hi! On Tue, 5 Mar 2024 12:39, Tobias Leupold said: > Sorry for asking another thing about this. For sure, I didn't want to set off > an avalanche, and I still don't want to. But from a user's perspective, this > is simply very confusing and also unsettling. You are right. What I can do is to give my perspective of this which is based on my experience re-implementing a free PGP version since 1997 and while doing that taking part in the OpenPGP specification process which started at the same time. > https://security.stackexchange.com/questions/275883/should-one-really-disable-aead-for-recent-gnupg-created-pgp-keys > > The answer started with: > >> While authenticated encryption (AEAD) is good - especially for something >> like OpenPGP, which is an old and over-complicated standard that has a >> concerning large attack surface for vulnerabilities or simple implementation This introduction is pretty unfair but unfortunately as common on the net as the "PGP is way too complicate for anyone to use" claim. In reality PGP (in the form of GnuPG and Thunderbird) is used daily by million of people who consciously choose to protect their mails and data. If you want to see an over-complicated standard, have a look at S/MIME (aka CMS, X.509) which is implemented by all major mailers but has not the good repudiation of *PGP. See also [1]. The above answer by CBHacking continues: I definitely can't recommend enabling a non-standardized compatibility-breaking feature by default, and frankly feel that GnuPG made a major error in doing so. That is factual wrong. RNP, the core of Thunderbird's OpenPGP implementation, implemented this too. But instead of fixing all the stuff which got lost during the migration from Enigmail to TB's new OpenPGP code the TB maintainer now wants to remove support for OCB from TB. IETF specifications are not a standard but a specification how certain things are commonly implemented. The meanwhile most used public key algorithm (Curve25519) is not specified in OpenPGP but nevertheless less widely used and accepted. From a security perspective, I'm not even sure that just adding an OCB-based AEAD mode actually helps anything, in expectation; OpenPGP messages can already be authenticated in a few different ways, so arguably the likeliest source of security flaws is that the message S/he is right that formats get more complex and that we already have Authenticated Encryption (the core feature of AEAD) in OpenPGP but exactly that old format is complex and hard to implement. OTOH, the new OCB based Authenticated Encryption is a straightforward implementation of a well reseached mode and the gold standard for all block cipher modes. The old format in OpenPG was an ad-hoc implementation of Authenticated Encryption on top of the legacy PGP-2 format. Thus in the long run the new OCB mode will reduce the complexity. The answer shows in bold: Given that you work with non-GnuPG clients, and that this feature is not part of the OpenPGP specification, and that OpenPGP already includes message authentication and integrity, I recommend disabling this feature for now. With the same argument you could also stop using TLS 1.3 and instead keep on using TLS 1.2 in eternity. In most cases 1.3 has no real world advantages when done right. However, most sites allow for both 1.3 and 1.2 and only a few disallow 1.2 which leads to the same problems as we see with the removal of support by some application and some Linux distros. Note that you'll have to re-encrypt the data for non-GPG clients after disabling this non-standard feature. Also most other things CBHacking wrote are okay, this one is simply wrong. This is not a gpg only feature. > from somebody with an impressive reputation on the network, for whom I > suppose Well, some anonmyous account on stackexchange. I can't tell. Salam-Shalom, Werner [1] Let me quote Peter Gutman, a really well repudiated expert on all things security, on S/MIME: "As a result there's no pressure on the people involved in PKI standardisation to create anything that meets any real-world requirement, allowing them instead to spend their time building great gothic cathedrals of infinite complexity whose sole purpose seems to be to strike awe and terror into the masses." I hope that *PGP stops evolving into this direction. -- 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 Tue Mar 5 18:15:15 2024 From: bwalzer at 59.ca (Bruce Walzer) Date: Tue, 5 Mar 2024 11:15:15 -0600 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <2174068.KiezcSG77Q@ginuog> References: <2174068.KiezcSG77Q@ginuog> Message-ID: It seems to me that there are at least 3 decisions to make when considering the implementation a new block cipher mode: 1. If your implementation will receive the block mode. Receiving a block mode does not cause an interoperability problem. If anything, this improves interoperability. 2. If your implementation will generate the block mode. This can possibly cause incompatibility. 3. If your implementation will cause other implementations to generate the block mode. This can also possibly cause incompatibility. So if you were interested in seeing a new block mode in OpenPGP, there is no reason not to do #1. The controversial parts are #2 and #3. If you were interested, in say, having the OCB block mode in OpenPGP then you would have the greatest chance of success by implementing the most popular version of the available 2 proposals. Correct me if I am wrong, but that would be the LibrePGP (4880bis) version. So just to be clear, I am not complaining that GnuPG implemented the LibrePGP version of OCB. I am complaining that GnuPGP did #2 and #3 before implementation was close to universal and did not clearly spell out the implications to the users. Speaking of documentation, the implementations that support LibrePGP OCB could be promoting the the non-controversial aspects of the new mode. That could help with adoption. Dunno, something like: Now with super ultra performance! Just add the "--performance" option and get up to 400% faster encryption! ... where "--performance" would turn off compression, enable the OCB block cipher mode and do whatever else will speed things up. The user, of course, would be made aware the the resulting files might not be decryptable everywhere. Arch Linux is just dropping #3 with their patch. Their version of GnuPGP still supports the OCB mode and can generate it. So they are not really taking a political stance. The history of Linux distribution patches for stuff like this is not good (the Debian patch against Openssl for example). It would be better if Linux distributions were not tempted to issue such patches. There really should be a better way of doing this. Otherwise the users will encounter different behaviour on different Linux distributions. Bruce From wk at gnupg.org Wed Mar 6 09:43:00 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Mar 2024 09:43:00 +0100 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: (Bruce Walzer's message of "Tue, 5 Mar 2024 11:15:15 -0600") References: <2174068.KiezcSG77Q@ginuog> Message-ID: <87o7bru4x7.fsf@jacob.g10code.de> On Tue, 5 Mar 2024 11:15, Bruce Walzer said: > So just to be clear, I am not complaining that GnuPG implemented the > LibrePGP version of OCB. I am complaining that GnuPGP did #2 and #3 > before implementation was close to universal and did not clearly spell Sorry, this is not true. OCB mode is only used if all recipient's key have the flag that they support this mode. This is not different from the preferences for a certain cipher algorithm. For example AES in the old days. The migration from CAST5 to AES worked without any noticeable problems because after we implemented AES, we announced that in the keys and the peers started to use AES iff all recipients claimed that they support this flags. Same thing for for compression algorithms. At some point we were talked round to implement bzip2. The WG agreed on a code point for this and GnuPG implemented it. It is really rare that you get messages which you can't decrypt due to the non-supported compression algo. The preference system does it works. Now, when you move to another software with less capabilities, you need to announce that to your peers by sending an updated key with the new set of preferences. Sure there is a problem with low end mobile device software which you use with the same key - in this case you need to drop the preferences which are not supported by your mobile device software. > block cipher mode and do whatever else will speed things up. The user, > of course, would be made aware the the resulting files might not be > decryptable everywhere. If your key claims that it supports this feature it is decryptable - or you forgot to distribute the fact that you moved to a less capable software. Right, for symmetric only encryption the preferences don't work. But in this case you need to negotiate parameters and passwords anyway. > Arch Linux is just dropping #3 with their patch. Their version of > GnuPGP still supports the OCB mode and can generate it. So they are Sure they can do that. However, I don't think that this is a good decision. With the same argument we would still be using CAST5 or Twofish or even Blowfish. > distributions were not tempted to issue such patches. There really > should be a better way of doing this. Otherwise the users will > encounter different behaviour on different Linux distributions. Agreed. Let the preferences work for you. And also nag Vincent et al to stop crippling their software (rejecting OCB). After all BouncyCastle supports ed25519 which is also not specified by an RFC or anything else except the way gpg implemented the details of that curve. Such public key algorithms can't even be managed by the preference system. 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 lockywolf at gmail.com Wed Mar 6 13:20:35 2024 From: lockywolf at gmail.com (Vladimir Nikishkin) Date: Wed, 6 Mar 2024 20:20:35 +0800 Subject: How to download commit packages from gnupg phabricator? Message-ID: Dear All, I would like to try the GnuPG Password Manager (https://dev.gnupg.org/source/gpgpass/) However, I don't seem to be able to find a way to download a tarball of the commit in any way. I looked at the source of Phabricator, and it seems that support for downloading zips exists: https://secure.phabricator.com/rP8bb6e807f097b2eb58f863822d64c5078878355d But for some reason the links like https://dev.gnupg.org/source/gpgpass/zip/master/;f46437b49b30257a7e98f98803c42c369b0748e8.zip or https://dev.gnupg.org/source/gpgpass/zip/;f46437b49b30257a7e98f98803c42c369b0748e8.zip don't seem to work -- Yours sincerely, Vladimir Nikishkin (Sent from GMail web interface.) From wk at gnupg.org Wed Mar 6 16:20:44 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Mar 2024 16:20:44 +0100 Subject: How to download commit packages from gnupg phabricator? In-Reply-To: (Vladimir Nikishkin via Gnupg-users's message of "Wed, 6 Mar 2024 20:20:35 +0800") References: Message-ID: <877ciftmib.fsf@jacob.g10code.de> Hi! On Wed, 6 Mar 2024 20:20, Vladimir Nikishkin said: > However, I don't seem to be able to find a way to download a tarball > of the commit in any way. You man a tarball made from the repository at that commit? In general we only publish traballs. If you want to use a working thing (i.e. git) then you need to build from git. We like well versioned releases. > But for some reason the links like > https://dev.gnupg.org/source/gpgpass/zip/master/;f46437b49b30257a7e98f98803c42c369b0748e8.zip That is quite possible; we never configured it. dev.gnupg.org is in most cases only a "mirror"[1] of our main repo server. Salam-Shalom, Werner [1] For a distributed VCS like Git the term "mirror" is of course a bit questionable. -- 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 mr_shortchange at proton.me Wed Mar 6 18:31:59 2024 From: mr_shortchange at proton.me (mr_shortchange) Date: Wed, 06 Mar 2024 17:31:59 +0000 Subject: Clearsign Message-ID: Dear Fellows! Importing my private key is flawless but signing is faulty. May I ask for your help? Sent with [Proton Mail](https://proton.me/) secure email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalzer at 59.ca Wed Mar 6 23:14:37 2024 From: bwalzer at 59.ca (Bruce Walzer) Date: Wed, 6 Mar 2024 16:14:37 -0600 Subject: Should one really disable AEAD for recent GnuPG created PGP keys? In-Reply-To: <87o7bru4x7.fsf@jacob.g10code.de> References: <2174068.KiezcSG77Q@ginuog> <87o7bru4x7.fsf@jacob.g10code.de> Message-ID: On Wed, Mar 06, 2024 at 09:43:00AM +0100, Werner Koch wrote: > On Tue, 5 Mar 2024 11:15, Bruce Walzer said: > > > So just to be clear, I am not complaining that GnuPG implemented the > > LibrePGP version of OCB. I am complaining that GnuPGP did #2 and #3 > > before implementation was close to universal and did not clearly spell > [...] > OCB mode is only used if all recipient's key have the flag that they > support this mode. Yes, and I agree that the preference system here is helpful. But I have a list of 22 instances where it did not work. Those are up to this point entirely from GnuPGP emitting new block cipher modes and are mostly between different versions of GnuPG. Things could easily get worse going forward. > This is not different from the preferences for a certain cipher > algorithm. For example AES in the old days. The migration from > CAST5 to AES worked without any noticeable problems because after we > implemented AES, we announced that in the keys and the peers started > to use AES iff all recipients claimed that they support this flags. The difference here is that most users have a general idea of what these algorithms are and what it means when support for decytption is not available. Few people know about cipher block modes. The messages that they get won't even refer to cipher block modes, instead it will be some sort of obscure internal error. For example, GnuPG says this: gpg: [don't know]: partial length for invalid packet type 20 > Same thing for for compression algorithms. At some point we were > talked round to implement bzip2. How many implementations specify bzip2 as the most desired compression mode by default? Back in the day, most OpenPGP users were on the same mailing lists. That is no longer true. This is a good thing. The OpenPGP standard and GnuPGP in particular are widely and routinely used. [...] > Now, when you move to another software with less capabilities, you > need to announce that to your peers by sending an updated key with > the new set of preferences. Sure there is a problem with low end > mobile device software which you use with the same key - in this > case you need to drop the preferences which are not supported by > your mobile device software. Mailvelope for example, provides no way to modify preferences. Most implementations do not. So, practically, this will be done with the GnuPGP editor. That editor is not very accessible for most users. The user would have to export then import to GnuPGP. Then somehow determine the capabilities of all their implementations (and all the versions of those implementations they are using). Then they would find a common subset and edit it into the new key. Then they would export the key back to all the implementations, keyservers and non-server using correspondents. Certainly possible but it is a lot to ask. These are the sorts of things that allow others to claim that the OpenPGP ecosystem is complex and unusable. Anyway, this is not about my greatest fear. That fear is that the cryto refresh will someday be released as the official RFC-4880. If any significant implementation follows this exclusively, then there will be an actual "schism". If everyone emits new modes by default then the two islands of compatibility will not be able to interoperate. To the extent that the preferences were helpful, it would be by using the existing block cipher mode to bridge the gap. I would be OK with this but I doubt that most would. It would make the introduction of the new modes seem pointless. What happens then? Making this personal, I sometimes write PGP advocacy articles. How should I attempt to sell this new change? Faster encryption and different error handling, great. But that doesn't seem enough to justify obscure, possibly time delayed, interoperability problems even if they are rare. Bruce From mcepl at cepl.eu Thu Mar 7 10:05:09 2024 From: mcepl at cepl.eu (=?utf-8?q?Mat=C4=9Bj_Cepl?=) Date: Thu, 07 Mar 2024 10:05:09 +0100 Subject: How to download commit packages from gnupg phabricator? In-Reply-To: References: Message-ID: On Wed Mar 6, 2024 at 1:20 PM CET, Vladimir Nikishkin via Gnupg-users wrote: > Dear All, > > I would like to try the GnuPG Password Manager > (https://dev.gnupg.org/source/gpgpass/) https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgpass.git;a=summary And it has ability to download a snapshot of each commit. Mat?j -- http://matej.ceplovi.cz/blog/, @mcepl at floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 To err is human, to purr feline. -------------- next part -------------- A non-text attachment was scrubbed... Name: E09FEF25D96484AC.asc Type: application/pgp-keys Size: 45433 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From mr_shortchange at proton.me Thu Mar 7 09:31:53 2024 From: mr_shortchange at proton.me (mr_shortchange) Date: Thu, 07 Mar 2024 08:31:53 +0000 Subject: Sign detach Message-ID: <2DPSLBZjfV0iuY5D-N72lB8vf0bPVC8iofEZKKLgZjval86ocRCIIOicTpz1Dk6WQbvthJIDrZgGMOCs9gEkT31Dg_8P3kb5xXDePb3i4jI=@proton.me> --sign --detach is also not working properly. If I may say so. Sent with [Proton Mail](https://proton.me/) secure email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuartl at longlandclan.id.au Thu Mar 7 13:04:00 2024 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Thu, 7 Mar 2024 22:04:00 +1000 Subject: Clearsign In-Reply-To: References: Message-ID: On 7/3/24 03:31, mr_shortchange via Gnupg-users wrote: > Dear Fellows! > Importing my private key is flawless but signing is faulty. May I ask for your help? Okay, a big tip? don't ask to ask, just ask. All we know is you have a problem with generating signatures, and apparently your key is "flawless" (whatever that means). We don't know what version of GnuPG you're running (or even if you are using GnuPG at all). We don't know what OS you're running it with. We don't know what type of private key you're using (e.g. RSA, ED25519, etc). We don't know where the private key resides. (is it in your home directory key chain, is it on a security token?) We don't know if other operations such as encryption or authentication work. We don't know whether you're generating signatures on the command line, or through some front-end application. I might wear a pointy hat, but I'm no wizard, and I lost my crystal ball in the 2011 Brisbane floods. (It was defective anyway, otherwise I'd have known the floods were coming.) If you don't want to tell us these things, then that's fine, but you're on your own to troubleshoot the issue as we have nothing to go on, because clear-signing is working fine here. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From wk at gnupg.org Thu Mar 7 16:14:31 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Mar 2024 16:14:31 +0100 Subject: Sign detach In-Reply-To: <2DPSLBZjfV0iuY5D-N72lB8vf0bPVC8iofEZKKLgZjval86ocRCIIOicTpz1Dk6WQbvthJIDrZgGMOCs9gEkT31Dg_8P3kb5xXDePb3i4jI=@proton.me> (mr shortchange via Gnupg-users's message of "Thu, 07 Mar 2024 08:31:53 +0000") References: <2DPSLBZjfV0iuY5D-N72lB8vf0bPVC8iofEZKKLgZjval86ocRCIIOicTpz1Dk6WQbvthJIDrZgGMOCs9gEkT31Dg_8P3kb5xXDePb3i4jI=@proton.me> Message-ID: <87ttliqdk8.fsf@jacob.g10code.de> Hi, please send proper bug reports or detailed questions. Stuart have hints how how this can be done. If you don't want to follow this basic rule we have to set you on moderated. 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 stuartl at longlandclan.id.au Thu Mar 7 20:43:59 2024 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Fri, 8 Mar 2024 05:43:59 +1000 Subject: Clearsign In-Reply-To: <2YyVW7U-Ad42SNaUUuXT2gfcGBCRul0eW_ugLkMy7pewiAxvVAGtPyyVZlaMTR6IuAMUSzlQho4E1CxY_Zcs31DEJekf4Rsz5P2xTPXW1qU=@proton.me> References: <2YyVW7U-Ad42SNaUUuXT2gfcGBCRul0eW_ugLkMy7pewiAxvVAGtPyyVZlaMTR6IuAMUSzlQho4E1CxY_Zcs31DEJekf4Rsz5P2xTPXW1qU=@proton.me> Message-ID: On 8/3/24 01:24, mr_shortchange wrote: > It's very kind of you. I try to answer your questions down below. > Please help me. Thank you. > To: Stuart Longland > From: mr_shortchange You forgot to include the list. To or CC should include: gnupg-users at gnupg.org Using "Reply All" should fix that. I'm no expert, so cannot assist you personally. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From mr_shortchange at proton.me Fri Mar 8 05:11:44 2024 From: mr_shortchange at proton.me (mr_shortchange) Date: Fri, 08 Mar 2024 04:11:44 +0000 Subject: Signing documents not working properly: Message-ID: gpg (GnuPG) 2.2.40 libgcrypt 1.10.1 OS: Debian Bookworm KEY: 16.384 RSA KEY Encryption/Decryption is working. Generating signatures using command line. Is not working. Authentication might work. I don't know. I have never used it. The private key resides in my home directory. The key is not corrupted. I cannot generate signatures using TailsOS either. The problem persists with ECC NIST P-521 KEYS as well. The software is so unreliable it should not be released. In my opinion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hfollmann at itcfollmann.com Fri Mar 8 12:34:07 2024 From: hfollmann at itcfollmann.com (Henning Follmann) Date: Fri, 8 Mar 2024 06:34:07 -0500 Subject: Signing documents not working properly: In-Reply-To: References: Message-ID: On Fri, Mar 08, 2024 at 04:11:44AM +0000, mr_shortchange via Gnupg-users wrote: > gpg (GnuPG) 2.2.40 > libgcrypt 1.10.1 OS: > Debian Bookworm KEY: > > 16.384 RSA KEY > > Encryption/Decryption is working. > > Generating signatures using command line. Is not working. > > Authentication might work. I don't know. I have never used it. > > The private key resides in my home directory. > > The key is not corrupted. > > I cannot generate signatures using TailsOS either. > > The problem persists with ECC NIST P-521 KEYS as well. > > The software is so unreliable it should not be released. In my opinion. Unfortunately your second attempt is also not helpful. Can you please show what you did and the error message(s) you got? And explain what you expected. It would also be helpful to see that the keys are there. gpg --list-keys gpg --list-secret-keys or just list the one single key and its subkeys. -H -- Henning Follmann | hfollmann at itcfollmann.com From wk at gnupg.org Tue Mar 12 09:44:07 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Mar 2024 09:44:07 +0100 Subject: [Announce] GnuPG 2.4.5 released Message-ID: <87edcfon54.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG release: version 2.4.5. This version fixes a couple of bugs and comes with some new features. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.4.5 =================================== * gpg,gpgv: New option --assert-pubkey-algo. [T6946] * gpg: Emit status lines for errors in the compression layer. [T6977] * gpg: Fix invocation with --trusted-keys and --no-options. [T7025] * gpgsm: Allow for a longer salt in PKCS#12 files. [T6757] * gpgtar: Make --status-fd=2 work on Windows. [T6961] * scd: Support for the ACR-122U NFC reader. [rG1682ca9f01] * scd: Suport D-TRUST ECC cards. [T7000,T7001] * scd: Allow auto detaching of kernel drivers; can be disabled with the new compatibility-flag ccid-no-auto-detach. [rGa1ea3b13e0] * scd: Allow setting a PIN length of 6 also with a reset code for openpgp cards. [T6843] * agent: Allow GET_PASSPHRASE in restricted mode. [rGadf4db6e20] * dirmngr: Trust system's root CAs for checking CRL issuers. [T6963] * dirmngr: Fix regression in 2.4.4 in fetching keys via hkps. [T6997] * gpg-wks-client: Make option --mirror work properly w/o specifying domains. [rG37cc255e49] * g13,gpg-wks-client: Allow command style options as in "g13 mount foo". [rGa09157ccb2] * Allow tilde expansion for the foo-program options. [T7017] * Make the getswdb.sh tool usable outside the GnuPG tree. Release-info: https://dev.gnupg.org/T6960 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.5.tar.bz2 (7704k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.5.tar.bz2.sig A new release of the Windows version in the form of the full featured Gpg4win installer including this version of GnuPG is available here: https://files.gpg4win.org/gpg4win-4.3.1.exe (34M) https://files.gpg4win.org/gpg4win-4.3.1.exe.sig and its source code is https://files.gpg4win.org/gpg4win-4.3.1.tar.xz (219M) https://files.gpg4win.org/gpg4win-4.3.1.tar.xz.sig Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.4.5.tar.bz2 you would use this command: gpg --verify gnupg-2.4.5.tar.bz2.sig gnupg-2.4.5.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.4.5.tar.bz2, you run the command like this: sha1sum gnupg-2.4.5.tar.bz2 and check that the output matches the next line: ae0935ead29a2dfa34d6b48d70808652bc3ca73b gnupg-2.4.5.tar.bz2 7c5fa919c2eb90194e844de027a36e87c7be8a80 gpg4win-4.3.1.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T6960 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ralph at ml.seichter.de Tue Mar 12 13:07:19 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 12 Mar 2024 13:07:19 +0100 Subject: [Announcement] GnuPG for OS X 2.4.5 Message-ID: <874jdblklk.fsf@ra.horus-it.com> GnuPG for OS X / macOS release 2.4.5 is now available for download via https://sourceforge.net/p/gpgosx/docu/Download/ . The disk image signature key is available via public keyservers, and it can also be downloaded from https://www.seichter.de/pgp/gpgosx-signing.asc . pub ed25519/FD56297D9833FF7F 2022-07-07 [SC] [expires: 2027-07-06] Key fingerprint = EAB0 FE4F F793 D9E7 028E C8E2 FD56 297D 9833 FF7F uid [ultimate] Ralph Seichter (GnuPG for OS X signing key) GnuPG 2.4.x is installed in /usr/local/gnupg-2.4 instead of the formerly hardcoded directory /usr/local/gnupg-2.2. This enables installing both stable and LTS releases of GnuPG for OS X side by side, for advanced users' needs. The one caveat is that the latest installation will replace existing soft links in /usr/local/{bin,lib}. Please use absolute paths like /usr/local/gnupg-2.2/bin/gpg2 if necessary. Enjoy. -Ralph From bence at ferdinandy.com Fri Mar 15 20:16:45 2024 From: bence at ferdinandy.com (Bence Ferdinandy) Date: Fri, 15 Mar 2024 20:16:45 +0100 Subject: gpg-agent "forgetting" keys when getting many parallel requests Message-ID: Hi, I've been poking at this issue now for some time, and haven't been able to find any info regarding this in the man pages or online. I'm running Regolith (basically Ubuntu with i3), and normally my gpg key is unlocked by me logging into the graphical session, i.e. using the key to decrypt something does not ask for a key. What I noticed though, is that if I want to decrypt multiple things in parallel, first the decryption process seems to slow down faster than linear, and then some (not all) decrypt tasks start prompting me for a password to the key. I've done a couple of experiments, and my feeling is that even though the decrypt task are run in parallel, something is done serially, but I'm not sure what and where exactly and that there is a timeout on waiting for this. My best bet, is that the password for the key needs to be fetched from the gnome keyring (? if it's called that) and that gpg-agent times out waiting for this and just requests it from the user. I made a short script in python (attached) demonstrating this. On my machine, setting WORKERNUM=7 is enough to trigger the issue. Could somebody point me to a resources explaining what is happening here? And more importantly, is there some setting I can change to avoid the occasional password prompts? Thanks, Bence -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgtest.py Type: text/x-python Size: 545 bytes Desc: not available URL: From bs27975 at gmail.com Sun Mar 17 02:26:31 2024 From: bs27975 at gmail.com (B.S.) Date: Sat, 16 Mar 2024 21:26:31 -0400 Subject: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? Message-ID: ... (Windows 10) [DOS] cmd ... [*NOT* powershell] ... cygwin gpg ... How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? e.g. gpg -c < secretdata.json.pgp | jq | less - less is happening before gpg has 'readlined' the passphrase, and things get ... all confused. [I don't mind not seeing things (such as the password request) on stdout, but herein it seems both less and gpg are trying to consume stdin.] So if gpg could finish getting its passphrase from 'readline' before opening stdout (that less then sees to clear the screen and open its window, and start showing its incoming data), things would be ... unconfused. So far: ( gpg.exe -d somefile.gpg | jq.exe ) | less seems to do it (give gpg time to acquire the passphrase), but the '()'s involved certainly weren't intuitive. It there a way for 'gpg -d file.gpg' to finish acquiring the passphrase (via 'readline') before it starts writing to stdout (triggering less' screen clearing and stdout watching)? I have come across '--batch' which seems no help, as it cuts off stdin, preventing gpg -d from 'readlining' a passphrase. (There seems a corresponding '--pinentry-mode loopback' to '--batch', but that doesn't seem in play yet, to that point in the sequence.) From bence at ferdinandy.com Sun Mar 17 13:09:15 2024 From: bence at ferdinandy.com (Bence Ferdinandy) Date: Sun, 17 Mar 2024 13:09:15 +0100 Subject: gpg-agent "forgetting" keys when getting many parallel requests In-Reply-To: References: Message-ID: On Fri Mar 15, 2024 at 20:16, Bence Ferdinandy wrote: > Hi, > > I've been poking at this issue now for some time, and haven't been able to find > any info regarding this in the man pages or online. > > I'm running Regolith (basically Ubuntu with i3), and normally my gpg key is > unlocked by me logging into the graphical session, i.e. using the key to > decrypt something does not ask for a key. What I noticed though, is that if > I want to decrypt multiple things in parallel, first the decryption process > seems to slow down faster than linear, and then some (not all) decrypt tasks > start prompting me for a password to the key. I've done a couple of > experiments, and my feeling is that even though the decrypt task are run in > parallel, something is done serially, but I'm not sure what and where exactly > and that there is a timeout on waiting for this. My best bet, is that the > password for the key needs to be fetched from the gnome keyring (? if it's > called that) and that gpg-agent times out waiting for this and just requests it > from the user. > > I made a short script in python (attached) demonstrating this. On my machine, > setting WORKERNUM=7 is enough to trigger the issue. > > Could somebody point me to a resources explaining what is happening here? And > more importantly, is there some setting I can change to avoid the occasional > password prompts? After looking at logs even more, I found that actually gpg-agent reports running out of memory. Based on a discussion I found (https://dev.gnupg.org/T4255), I set `auto-expand-secmem 100M` in gpg-agent.conf which seems to have resolved the issue even with 100 parallel threads. I have no idea if this 100M is way too much or not, but I haven't found any mentions of a downside to such a setting and it seems to work as expected, so I'm happy for now. Best, Bence From zorionxu at gmail.com Sun Mar 17 04:29:03 2024 From: zorionxu at gmail.com (pal) Date: Sun, 17 Mar 2024 11:29:03 +0800 Subject: Feature Request: 64-bit Windows Support for GnuPG Message-ID: Dear GnuPG Developers, I am writing to express my strong interest in a 64-bit version of GnuPG for Windows. While I understand that currently only 32-bit systems (x86) are officially supported, I believe adding 64-bit compatibility would be a valuable improvement for many users. Many modern Windows machines run 64-bit architectures, and having a native 64-bit version of GnuPG would allow users to take full advantage of their system's capabilities. This could lead to improved performance, stability, and memory usage when working with encryption tasks. I noticed on your website that there is a mention of potentially working on a 64-bit version in the future, but only if there is sufficient user demand. I would like to add my voice to the request for this feature. If there's anything I or other users can do to help with the development process, such as testing or providing feedback, please don't hesitate to let us know. Thank you for your time and consideration. Sincerely, zorion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Mar 18 09:50:02 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Mar 2024 09:50:02 +0100 Subject: gpg-agent "forgetting" keys when getting many parallel requests In-Reply-To: (Bence Ferdinandy via Gnupg-users's message of "Sun, 17 Mar 2024 13:09:15 +0100") References: Message-ID: <87jzlzly9x.fsf@jacob.g10code.de> On Sun, 17 Mar 2024 13:09, Bence Ferdinandy said: > running out of memory. Based on a discussion I found > (https://dev.gnupg.org/T4255), I set `auto-expand-secmem 100M` in Right. The man page says: --auto-expand-secmem n Allow Libgcrypt to expand its secure memory area as required. The optional value n is a non-negative integer with a suggested size in bytes of each additionally allocated secure memory area. The value is rounded up to the next 32 KiB; usual C style prefixes are allowed. For an heavy loaded gpg-agent with many concurrent connection this option avoids sign or decrypt errors due to out of secure memory error returns. You should not append the 'M' - it is simply ignored. That is a bug in the option parser but we can't fix that because it would break too many configs which falsely assume that a letter can be used for some kind of unit. The value is actually irrelevant becuase any value will enable the auto-expand behaviour. Larger chunks can make maneory allocation a biut faster because every free() call needs to check the linked list of secure memory pools. I am not sure whetehr this is measurable, though. 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 Mar 18 09:57:16 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Mar 2024 09:57:16 +0100 Subject: Feature Request: 64-bit Windows Support for GnuPG In-Reply-To: (pal via Gnupg-users's message of "Sun, 17 Mar 2024 11:29:03 +0800") References: Message-ID: <87frwnlxxv.fsf@jacob.g10code.de> Hi! and thanks for asking. On Sun, 17 Mar 2024 11:29, pal said: > I am writing to express my strong interest in a 64-bit version of GnuPG for > Windows. While I understand that currently only 32-bit systems (x86) are > officially supported, I believe adding 64-bit compatibility would be a > valuable improvement for many users. Sure. In particular servers are sometimes installed w/o 32 bit support. GnuPG 2.6 will come as 64 bit Windows binary. A first beta is planned for this sommer. See https://dev.gnupg.org/T6508 for the status. 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 bence at ferdinandy.com Mon Mar 18 13:20:43 2024 From: bence at ferdinandy.com (Bence Ferdinandy) Date: Mon, 18 Mar 2024 13:20:43 +0100 Subject: gpg-agent "forgetting" keys when getting many parallel requests In-Reply-To: <87jzlzly9x.fsf@jacob.g10code.de> References: <87jzlzly9x.fsf@jacob.g10code.de> Message-ID: On Mon Mar 18, 2024 at 09:50, Werner Koch wrote: > On Sun, 17 Mar 2024 13:09, Bence Ferdinandy said: > > > running out of memory. Based on a discussion I found > > (https://dev.gnupg.org/T4255), I set `auto-expand-secmem 100M` in > > Right. The man page says: > > --auto-expand-secmem n > > Allow Libgcrypt to expand its secure memory area as required. > The optional value n is a non-negative integer with a suggested > size in bytes of each additionally allocated secure memory area. > The value is rounded up to the next 32 KiB; usual C style > prefixes are allowed. For an heavy loaded gpg-agent with many > concurrent connection this option avoids sign or decrypt errors > due to out of secure memory error returns. > > You should not append the 'M' - it is simply ignored. That is a bug in > the option parser but we can't fix that because it would break too many > configs which falsely assume that a letter can be used for some kind of > unit. > > The value is actually irrelevant becuase any value will enable the > auto-expand behaviour. Larger chunks can make maneory allocation a biut > faster because every free() call needs to check the linked list of > secure memory pools. I am not sure whetehr this is measurable, though. Thanks for the clarification! Best, Bence From wk at gnupg.org Mon Mar 18 14:54:32 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Mar 2024 14:54:32 +0100 Subject: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? In-Reply-To: (B. S. via Gnupg-users's message of "Sat, 16 Mar 2024 21:26:31 -0400") References: Message-ID: <87a5mvlk6f.fsf@jacob.g10code.de> On Sat, 16 Mar 2024 21:26, B.S. said: > ... (Windows 10) [DOS] cmd ... [*NOT* powershell] > ... cygwin gpg ... [Do not use a Cygwin build of gpg - this is not supported. Use a standard build for WIndows.] > How can I have gpg pause to receive its passphrase, before it starts > outputing decrypt to stdout? Due to the way a pipe works there is not much you can do here. Except for having some kind buffering tool in between. Howeverm if you known the passphrase, you can pass it to gpg directly using --passphrase-file and --pinentry-mode=loopback. > So if gpg could finish getting its passphrase from 'readline' before > opening stdout (that less then sees to clear the screen and open its The pipeline is constructed by the shell (cmd.exe) and file descriptors are given to the programs. There is nothing any of the programs can do here. In fact when using a pipeline in this way, the next program in the line should be able to handle the output of the former which means it will expect valid output. > So far: > ( gpg.exe -d somefile.gpg | jq.exe ) | less You are using a Cygwin version of the standard shell here? In this case make sure that jq.exe gets its EPIPE from the failed gpg.exe. You may consider to use gpgme-json as a higher level API to gpg. But of course it does not work the usual way in a pipe. 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 Mar 18 22:59:31 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Mon, 18 Mar 2024 17:59:31 -0400 Subject: How can I 'echo' into fd 3 to be able to use it on a gpg cmd line? Message-ID: <1FE406AD-7781-45E7-A3C6-2E74FC6CF367.1@smtp-inbound1.duck.com> ... (Windows 10) [DOS] cmd ... [*NOT* powershell] ... cygwin gpg ... How can I 'echo' into fd 3 to be able to use it on a gpg cmd line? e.g. 'echo "Secret data" | gpg.exe -c -passphrase-fd 3 3< echo %PASSWORD%' [Ignore the need, or not, for --batch and/or --pinentry-mode loopback, I can wrestle with those separately.] (I am trying to avoid the passphrase from appearing in cleartext within tasklists, etc.) I am working on a BitWarden(-cli) backup script. So the 'echo "Secret data"' above is actually something like: bitwarden-cli --export json | gpg -c ... >...bitwarden_backup.json.pgp - the hangup seems to be how to echo into 3< to be able to use it as input, for ' -passphrase-fd 3'. [Or 7< echo %PASSWORD%, for that matter - it seems powershell uses 3-6 for stdwarn|verbose|debug|info, and probably best to avoid potential future conflicts.] From omcujl92 at duck.com Mon Mar 18 23:10:52 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Mon, 18 Mar 2024 18:10:52 -0400 Subject: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? References: <87a5mvlk6f.fsf@jacob.g10code.de> Message-ID: > However if you known the passphrase, you can pass it to gpg directly using --passphrase-file and --pinentry-mode=loopback. I figured, but am trying to avoid having the passphrase land on disk at all. > Due to the way a pipe works there is not much you can do here. Except (I would hope?) if gpg were to make sure nothing is written to stdout until after passphrase was completely acquired, before decrypting and writing the decrypt to sdtout, I don't expect less will have cleared the screen to that point. [Less waits to clear screen, etc., until after it receives something / anything at stdin, IIRC.] > You are using a Cygwin version of the standard shell here? No, standard DOS prompt (Win 10). Just that cygwin is along the path. (It's win jq, in this case, however.) [cygwin less.exe being quieter and more functional than dos' more.exe.] > make sure that jq.exe gets its EPIPE from the failed gpg.exe. (1) EPIPE? As in '2|' - that's a thing (in 'Win 10' dos)? (2) gpg has not failed here. I guess the issue is also gpg displaying prompt, also confusing less. I will have to try 'gpg.exe -d somefile.gpg < con: 2> nul: | jq.exe | less', or something like. Curious that '( gpg.exe -d somefile.gpg | jq.exe ) | less' displays sufficiently well - I'm guessing I'm just getting lucky with (sub-shell?) delays, giving things time to display. On Mon, Mar 18, 2024 at 9:58?AM Werner Koch via Gnupg-users wrote: > > On Sat, 16 Mar 2024 21:26, B.S. said: > > ... (Windows 10) [DOS] cmd ... [*NOT* powershell] > > ... cygwin gpg ... > > [Do not use a Cygwin build of gpg - this is not supported. Use a > standard build for WIndows.] > > > How can I have gpg pause to receive its passphrase, before it starts > > outputing decrypt to stdout? > > Due to the way a pipe works there is not much you can do here. Except > for having some kind buffering tool in between. Howeverm if you known > the passphrase, you can pass it to gpg directly using --passphrase-file > and --pinentry-mode=loopback. > > > So if gpg could finish getting its passphrase from 'readline' before > > opening stdout (that less then sees to clear the screen and open its > > The pipeline is constructed by the shell (cmd.exe) and file descriptors > are given to the programs. There is nothing any of the programs can do > here. In fact when using a pipeline in this way, the next program in > the line should be able to handle the output of the former which means > it will expect valid output. > > > So far: > > ( gpg.exe -d somefile.gpg | jq.exe ) | less > > You are using a Cygwin version of the standard shell here? In this case > make sure that jq.exe gets its EPIPE from the failed gpg.exe. > > You may consider to use gpgme-json as a higher level API to gpg. But of > course it does not work the usual way in a pipe. From omcujl92 at duck.com Tue Mar 19 00:01:53 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Mon, 18 Mar 2024 19:01:53 -0400 Subject: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? References: <87a5mvlk6f.fsf@jacob.g10code.de> Message-ID: <3A07A601-E9BC-46DE-81CA-543F0920321E.1@smtp-inbound1.duck.com> > However if you known the passphrase, you can pass it to gpg directly using --passphrase-file and --pinentry-mode=loopback. I figured, but am trying to avoid having the passphrase land on disk at all. > Due to the way a pipe works there is not much you can do here. Except (I would hope?) if gpg were to make sure nothing is written to stdout until after passphrase was completely acquired, before decrypting and writing the decrypt to sdtout, I don't expect less will have cleared the screen to that point. [Less waits to clear screen, etc., until after it receives something / anything at stdin. (?)] > You are using a Cygwin version of the standard shell here? No, standard DOS prompt (Win 10). Just that cygwin is along the path. (It's win jq, in this case, however.) [cygwin less.exe being quieter and more functional than dos' more.exe.] > make sure that jq.exe gets its EPIPE from the failed gpg.exe. (1) EPIPE? As in '2|' - that's a thing (in 'Win 10' dos)? (2) gpg has not failed here. I guess the issue is also gpg displaying prompt, also confusing less. I will have to try 'gpg.exe -d somefile.gpg < con: 2> nul: | jq.exe | less', or something like. Curious that '( gpg.exe -d somefile.gpg | jq.exe ) | less' displays sufficiently well - I'm guessing I'm just getting lucky with (sub-shell?) delays, giving things time to display. On Mon, Mar 18, 2024 at 9:55?AM Werner Koch wrote: > > On Sat, 16 Mar 2024 21:26, B.S. said: > > ... (Windows 10) [DOS] cmd ... [*NOT* powershell] > > ... cygwin gpg ... > > [Do not use a Cygwin build of gpg - this is not supported. Use a > standard build for WIndows.] > > > How can I have gpg pause to receive its passphrase, before it starts > > outputing decrypt to stdout? > > Due to the way a pipe works there is not much you can do here. Except > for having some kind buffering tool in between. Howeverm if you known > the passphrase, you can pass it to gpg directly using --passphrase-file > and --pinentry-mode=loopback. > > > So if gpg could finish getting its passphrase from 'readline' before > > opening stdout (that less then sees to clear the screen and open its > > The pipeline is constructed by the shell (cmd.exe) and file descriptors > are given to the programs. There is nothing any of the programs can do > here. In fact when using a pipeline in this way, the next program in > the line should be able to handle the output of the former which means > it will expect valid output. > > > So far: > > ( gpg.exe -d somefile.gpg | jq.exe ) | less > > You are using a Cygwin version of the standard shell here? In this case > make sure that jq.exe gets its EPIPE from the failed gpg.exe. > > You may consider to use gpgme-json as a higher level API to gpg. But of > course it does not work the usual way in a pipe. From jcb62281 at gmail.com Tue Mar 19 01:23:20 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Mon, 18 Mar 2024 19:23:20 -0500 Subject: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? In-Reply-To: <3A07A601-E9BC-46DE-81CA-543F0920321E.1@smtp-inbound1.duck.com> References: <87a5mvlk6f.fsf@jacob.g10code.de> <3A07A601-E9BC-46DE-81CA-543F0920321E.1@smtp-inbound1.duck.com> Message-ID: <65F8DAF8.1070006@gmail.com> Bee via Gnupg-users wrote: >> However if you known the passphrase, you can pass it to gpg directly using --passphrase-file and --pinentry-mode=loopback. >> > I figured, but am trying to avoid having the passphrase land on disk at all. > Could you set up a RAM disk for this? (I think Windows still has those, but it has been a few years since I have used Windows any significant amount.) -- Jacob From jb-gnumlists at wisemo.com Thu Mar 21 08:45:17 2024 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Thu, 21 Mar 2024 08:45:17 +0100 Subject: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? In-Reply-To: <3A07A601-E9BC-46DE-81CA-543F0920321E.1@smtp-inbound1.duck.com> References: <87a5mvlk6f.fsf@jacob.g10code.de> <3A07A601-E9BC-46DE-81CA-543F0920321E.1@smtp-inbound1.duck.com> Message-ID: <88686e12-f927-8341-c9ee-2d1da6c6e6c2@wisemo.com> On 2024-03-19 00:01, Bee via Gnupg-users wrote: >> However if you known the passphrase, you can pass it to gpg directly using --passphrase-file and --pinentry-mode=loopback. > I figured, but am trying to avoid having the passphrase land on disk at all. > >> Due to the way a pipe works there is not much you can do here. > Except (I would hope?) if gpg were to make sure nothing is written to > stdout until after passphrase was completely acquired, before > decrypting and writing the decrypt to sdtout, I don't expect less will > have cleared the screen to that point. [Less waits to clear screen, > etc., until after it receives something / anything at stdin. (?)] > >> You are using a Cygwin version of the standard shell here? > No, standard DOS prompt (Win 10). Just that cygwin is along the path. > (It's win jq, in this case, however.) [cygwin less.exe being quieter > and more functional than dos' more.exe.] > >> make sure that jq.exe gets its EPIPE from the failed gpg.exe. > (1) EPIPE? As in '2|' - that's a thing (in 'Win 10' dos)? EPIPE is the C/POSIX error code a program receives when the pipe it reads from ends.? In this case the ordinary stdout pipe. However the Microsoft CMD.EXE supports a surprisingly large subset of Unixshell options, but sometimes with slightly different syntax. Some but not all ofthis is documented in the builtin help output such as cmd /? and set /? etc. However in this case the problem is that the shell, whichever you use, will start the redirection to jq immediately, because the shell knows nothing about gpg.exe or what part of its user interface to treat specially.? Using a "pinentry-program" helper that prompts via the Win32/X11 GUI is the official solution for such cases. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From alexis at catgirl.land Thu Mar 21 08:22:48 2024 From: alexis at catgirl.land (Alexis) Date: Thu, 21 Mar 2024 03:22:48 -0400 Subject: Fails signing key with Yubikey Message-ID: <18e5fe41b34.e7832ff5857390.5705683869006826944@catgirl.land> Dear GnuPG, ???? I'm trying to sign a secondary key with my yubikey, however it fails saying the private key is not found. I'm able to sign files with `--sign`, but am not able to use `--sign-key`. This issue was posted about by someone else at https://dev.gnupg.org/T6411 ``` gpg --version ???????????????????????????????????????????????? gpg (GnuPG) 2.4.5 libgcrypt 1.10.3-unknown Copyright (C) 2024 g10 Code GmbH License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/alexis/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, ???????CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ``` ``` gpg -K --with-colon 20E0635864445A177F8F7C0C6141FD27892AE9B4 sec:u:255:22:6141FD27892AE9B4:1700197485:::u:::cESCA:::#::ed25519:::0: fpr:::::::::20E0635864445A177F8F7C0C6141FD27892AE9B4: grp:::::::::1486B645AD4F1642BEDDA35BE0A03E24176B8736: uid:u::::1700197485::27E90DFEEB5D485431C85BC651668AB9FEC8A169::Alexis ::::::::::0: ssb:u:255:22:D0753D43F3C7A942:1700197520:1731733520:::::s:::D2760001240103040006250173860000::ed25519:: fpr:::::::::13511F6F0880AABD07AA1035D0753D43F3C7A942: grp:::::::::A8919684010395C76A981BB322E13011DEA9E1CC: ssb:u:255:18:90A11AD910FBE44E:1700197567:1731733567:::::e:::D2760001240103040006250173860000::cv25519:: fpr:::::::::B5B4442C9A5104824B0F0DA390A11AD910FBE44E: grp:::::::::583172CF6C0231FD03CDFC174A081F13EA565480: ssb:u:255:22:3A7E3018D78FC26A:1700197579:1731733579:::::a:::D2760001240103040006250173860000::ed25519:: fpr:::::::::1B10245AA781FC2BDADB4BB93A7E3018D78FC26A: grp:::::::::C3F9CAF98B582FC5BD82862F27E008C713F8536F: ``` Thanks, Alexis -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Thu Mar 21 13:24:24 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 21 Mar 2024 13:24:24 +0100 Subject: Fails signing key with Yubikey In-Reply-To: <18e5fe41b34.e7832ff5857390.5705683869006826944@catgirl.land> References: <18e5fe41b34.e7832ff5857390.5705683869006826944@catgirl.land> Message-ID: <6032211.lOV4Wx5bFT@daneel> On Donnerstag, 21. M?rz 2024 08:22:48 CET Alexis via Gnupg-users wrote: > I'm trying to sign a secondary key with my yubikey, however it fails > saying the private key is not found. I'm able to sign files with `--sign`, > but am not able to use `--sign-key`. Your Yubikey holds three keys: * a signing key (corresponding to a sign-only subkey of your OpenPGP key) > ssb:u:255:22:D0753D43F3C7A942:1700197520:1731733520:::::s:::D27600012401030 > 40006250173860000::ed25519:: * an encryption key > ssb:u:255:18:90A11AD910FBE44E:1700197567:1731733567:::::e:::D276000124010304 > 0006250173860000::cv25519:: * an authentication key > ssb:u:255:22:3A7E3018D78FC26A:1700197579:1731733579:::::a:::D276000124010304 > 0006250173860000::ed25519:: None of those keys are suitable for certifying other keys because for this you need a certification key. Only the primary key of your OpenPGP key can be used for certifying. > sec:u:255:22:6141FD27892AE9B4:1700197485:::u:::cESCA:::#::ed25519:::0: 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 Thu Mar 21 13:32:30 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Mar 2024 13:32:30 +0100 Subject: Fails signing key with Yubikey In-Reply-To: <18e5fe41b34.e7832ff5857390.5705683869006826944@catgirl.land> (Alexis via Gnupg-users's message of "Thu, 21 Mar 2024 03:22:48 -0400") References: <18e5fe41b34.e7832ff5857390.5705683869006826944@catgirl.land> Message-ID: <87r0g3ix41.fsf@jacob.g10code.de> Hi! > gpg -K --with-colon 20E0635864445A177F8F7C0C6141FD27892AE9B4 > sec:u:255:22:6141FD27892AE9B4:1700197485:::u:::cESCA:::#::ed25519:::0: This is your primary key and it has been taken offline ..^.. marked by the pound sign. Only the primary key can be used to sign other keys. > ssb:u:255:22:D0753D43F3C7A942:1700197520:1731733520:::::s:::D2760001240103040006250173860000::ed25519:: This is a signing subkey on a card with s/n *17386. > ssb:u:255:18:90A11AD910FBE44E:1700197567:1731733567:::::e:::D2760001240103040006250173860000::cv25519:: This is an encryption subkey on a card with s/n *17386. > ssb:u:255:22:3A7E3018D78FC26A:1700197579:1731733579:::::a:::D2760001240103040006250173860000::ed25519:: This is a authentication subkey on a card with s/n *17386. You need to go the the machine where you have stored the private part of the primary key. Or get that key using its keygrip (see the "grp" line) and put it into the ~/.gnupg/private-keys-v1.d/ directory. But you probably took the key offline for improved security and thus you better don't re-import it and indeed use the other box for key signing. 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 Fri Mar 22 00:45:58 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Thu, 21 Mar 2024 19:45:58 -0400 Subject: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'? Message-ID: <566C7C4D-48D7-475E-8E5A-A7204E1BEC40.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." 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 code.soma.kurisu at gmail.com Fri Mar 22 20:14:04 2024 From: code.soma.kurisu at gmail.com (Christian Sommer) Date: Fri, 22 Mar 2024 20:14:04 +0100 Subject: Fwd: speedo.mk errors out In-Reply-To: References: Message-ID: hi. building GnuPG by speedo.mk on current master branch fails. The log attached for building the dependencies looks fine. But when the configure tasks starts for building GnuPG itself some requiered libraries (build artifacts?) couldn't be found. Find the matching config.log attached as well. This happened on a plane ubuntu 22.04 VM prepared according the vagrant setup in Build-aux. I tried invoking the build system first with the native target which lead to the attached logs. Since i haven't yet scrutined all the relevant code blocks in the build system i just tried invoking the git-native target as well. But this also faild. Can anyone point me into the right direction, please? These are the preparation steps as documented in the vagrant setup script, just a little modified: sudo apt-get update -q -q sudo apt-get install --yes rsync build-essential git gpg automake autoconf gettext libtool sudo apt-get install --yes libz-dev libbz2-dev libldap2-dev libsqlite3-dev libgnutls28-dev libcurl4-gnutls-dev libreadline-dev librsvg2-bin libusb-1.0-0-dev sudo apt-get install --yes texinfo transfig fig2dev imagemagick file ghostscript swig doxygen graphviz sudo apt-get install --yes pkg-config autopoint python-all-dev python3-all-dev qtbase5-dev autoreconf -f -i cd build-aux make -f speedo.mk native INSTALL_PREFIX=/opt/gpg SELFCHECK=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-speedo-build.log Type: application/octet-stream Size: 64236 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-speedo-config.log Type: application/octet-stream Size: 252613 bytes Desc: not available URL: From ametzler at bebt.de Sat Mar 23 07:27:44 2024 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 23 Mar 2024 07:27:44 +0100 Subject: Fwd: speedo.mk errors out In-Reply-To: References: Message-ID: On 2024-03-22 Christian Sommer via Gnupg-users wrote: > hi. > building GnuPG by speedo.mk on current master branch fails. The log > attached for building the dependencies looks fine. [...] Good morning, Does not look "fine" to me: configure:9456: Use gpgrt-config as libassuan-config configure:9519: checking for LIBASSUAN - version >= 3.0.0 configure:9566: result: no [...] *** You need libassuan to build this program. *** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libassuan/ *** (at least version 3.0.0 (API 3) is required). AFAIUI gnupg master requires libassuan 3 which has not yet been released. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From omcujl92 at duck.com Sun Mar 24 02:17:45 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Sat, 23 Mar 2024 21:17:45 -0400 Subject: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't. Message-ID: <7400E657-2D52-445B-8C58-B0637EB93F45.1@smtp-inbound1.duck.com> >From https://gnupg.org/download/index.html: Windows ... download sig Simple installer for the current GnuPG <-- https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.5_20240307.exe ----- C:\Program Files (x86)\GnuPG\bin>ver Microsoft Windows [Version 10.0.19045.4123] C:\Program Files (x86)\GnuPG\bin>.\gpg.exe --version gpg (GnuPG) 2.4.5 libgcrypt 1.10.3 Copyright (C) 2024 g10 Code GmbH ... C:\Program Files (x86)\GnuPG\bin>echo Hello World > HelloWorld.txt C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt gpg: failed to translate osfhandle 0x00000003 ----- Is 'gpg: failed to translate osfhandle 0x00000003' known / expected? Is there a workaround? - same result for fd 8 and above. e.g. gpg: failed to translate osfhandle 0x0000000b Curiously: C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 4 -c 4< HelloWorld.txt - brought up a pinentry-qt dialogue. i.e. didn't read from fd 4. - same for fd 5, 6, and 7. Is there a workaround? From omcujl92 at duck.com Sun Mar 24 02:47:01 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Sat, 23 Mar 2024 21:47:01 -0400 Subject: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout? References: <87a5mvlk6f.fsf@jacob.g10code.de> Message-ID: <21C14531-62CF-4B8F-B36D-DF2644C6FA0D.1@smtp-inbound1.duck.com> On Mon, Mar 18, 2024 at 9:58?AM Werner Koch via Gnupg-users wrote: > > On Sat, 16 Mar 2024 21:26, B.S. said: > > ... (Windows 10) [DOS] cmd ... [*NOT* powershell] > > ... cygwin gpg ... > > [Do not use a Cygwin build of gpg - this is not supported. Use a > standard build for WIndows.] Thanks kindly. Found https://dev.gnupg.org/T4059 {Jul 8 2018} from Werner, to explain the point: > Note that Cygwin is not a supported platform. Seems that the exec functions don't work on this 64 bit variant. and > ... it seems that GnuPG can be used on 32 bit Cygwin.... Very Good to know. And ... 32-bit cygwin is no longer maintained / supported, as of version 3.3.6, around 11/11/2022, per https://cygwin.com/pipermail/cygwin-announce/2022-November/010810.html From wk at gnupg.org Mon Mar 25 10:47:04 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Mar 2024 10:47:04 +0100 Subject: Fwd: speedo.mk errors out In-Reply-To: (Christian Sommer via Gnupg-users's message of "Fri, 22 Mar 2024 20:14:04 +0100") References: Message-ID: <877chqiqxz.fsf@jacob.g10code.de> On Fri, 22 Mar 2024 20:14, Christian Sommer said: > building GnuPG by speedo.mk on current master branch fails. The log That is quite possible. I doubt that anyone of us used it yet. Please use the STABLE-BRANCH-2-4 for such things. master is for development and things might or might not work. We don't yet care. 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 wk at gnupg.org Mon Mar 25 10:48:14 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Mar 2024 10:48:14 +0100 Subject: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't. In-Reply-To: <7400E657-2D52-445B-8C58-B0637EB93F45.1@smtp-inbound1.duck.com> (Bee via Gnupg-users's message of "Sat, 23 Mar 2024 21:17:45 -0400") References: <7400E657-2D52-445B-8C58-B0637EB93F45.1@smtp-inbound1.duck.com> Message-ID: <8734seiqw1.fsf@jacob.g10code.de> On Sat, 23 Mar 2024 21:17, Bee said: > Is 'gpg: failed to translate osfhandle 0x00000003' known / expected? Don't mix Cygwin and plain Windows programs. 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 Mar 25 13:33:14 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Mon, 25 Mar 2024 08:33:14 -0400 Subject: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't. References: Message-ID: <3C0214E7-C18E-4327-AF1D-39E517C6CC86.1@smtp-inbound1.duck.com> > Don't mix Cygwin and plain Windows programs. cygwin has nothing to do with this thread - there is no element of cygwin within the quoted code or results. As said, this is pure GnuPG from > From https://gnupg.org/download/index.html: > Windows ... > download sig Simple installer for the current GnuPG <-- https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.5_20240307.exe > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt > gpg: failed to translate osfhandle 0x00000003 > > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 4 -c 4< HelloWorld.txt > - brought up a pinentry-qt dialogue. i.e. didn't read from fd 4. Is there a workaround? Tried '--pinentry-mode loopback', as well, to no joy. Using fd 4, '--pinentry-mode loopback' returned: gpg: error creating passphrase: Invalid passphrase gpg: symmetric encryption of '[stdin]' failed: Invalid passphrase On Mon, Mar 25, 2024 at 5:49?AM Werner Koch wrote: > > On Sat, 23 Mar 2024 21:17, Bee said: > > > Is 'gpg: failed to translate osfhandle 0x00000003' known / expected? > > Don't mix Cygwin and plain Windows programs. On Sat, Mar 23, 2024 at 9:17?PM B.S. wrote: > > From https://gnupg.org/download/index.html: > Windows ... > download sig Simple installer for the current GnuPG <-- > https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.5_20240307.exe > > ----- > > C:\Program Files (x86)\GnuPG\bin>ver > > Microsoft Windows [Version 10.0.19045.4123] > > C:\Program Files (x86)\GnuPG\bin>.\gpg.exe --version > gpg (GnuPG) 2.4.5 > libgcrypt 1.10.3 > Copyright (C) 2024 g10 Code GmbH > ... > > C:\Program Files (x86)\GnuPG\bin>echo Hello World > HelloWorld.txt > > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe > --passphrase-fd 3 -c 3< HelloWorld.txt > > gpg: failed to translate osfhandle 0x00000003 > > ----- > > > Is 'gpg: failed to translate osfhandle 0x00000003' known / expected? > > Is there a workaround? > - same result for fd 8 and above. e.g. gpg: failed to translate > osfhandle 0x0000000b > > > Curiously: > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe > --passphrase-fd 4 -c 4< HelloWorld.txt > > - brought up a pinentry-qt dialogue. i.e. didn't read from fd 4. > - same for fd 5, 6, and 7. > > Is there a workaround? From wk at gnupg.org Mon Mar 25 17:20:28 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Mar 2024 17:20:28 +0100 Subject: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't. In-Reply-To: <3C0214E7-C18E-4327-AF1D-39E517C6CC86.1@smtp-inbound1.duck.com> (Bee via Gnupg-users's message of "Mon, 25 Mar 2024 08:33:14 -0400") References: <3C0214E7-C18E-4327-AF1D-39E517C6CC86.1@smtp-inbound1.duck.com> Message-ID: <87sf0egu5v.fsf@jacob.g10code.de> On Mon, 25 Mar 2024 08:33, Bee said: > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt >> gpg: failed to translate osfhandle 0x00000003 gpg takes system handles and not libc file descriptors. File descriptors 0, 1, and 2 are handled by Windows in a different. All other depend on which ABI you work. cmd.exe seems to expect file descriptors which is good for scripting but gpg is rarely used in such a scripting environment but usuallay directly executed by CreateProcess and thus expects HANDLE values and not file descriptors. See gnupg/common/sysutils.c:translate_sys2libc_fd Actually it would be possible to provide an option to disable this translation and instead use libc file descriptors (with all the fun if different runtimes are used) but in more than 20 years we have not seen such a demand. 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 Tue Mar 26 00:52:47 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Mon, 25 Mar 2024 19:52:47 -0400 Subject: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't. References: <87sf0egu5v.fsf@jacob.g10code.de> <3C0214E7-C18E-4327-AF1D-39E517C6CC86.1@smtp-inbound1.duck.com> Message-ID: Thank you. I don't follow all of that, such as deep diving into gnupg/common/sysutils.c:translate_sys2libc_fd , but I do get the answer is: Unsupported (at least at this time). Could you make whatever notation at dev.gnupg.org is appropriate, please? Summary: --passphrase-fd #, where # >= 3, fails under Windows / DOS %COMSPEC% == unsupported (at this time). So that, with that and this list, web searchers looking to figure out why the described '--passphrase-fd #' isn't working for them, stop chasing their tails? [i.e. it's not user error, it's a Windows (DOS) issue not yet worked around]. ----- It is curious that fd 4 produced the different result of triggering a graphical pinentry. I presume the file open failed and it fell back to that mechanism. And, interesting that under wsl: 'cat HelloWorld.txt | gpg.exe --pinentry-mode loopback --passphrase-fd 4 -c 4< HelloWorld.txt' returned the expected consistent result for fd 3. [with and without --pinentry-mode loopback] > gpg: failed to translate osfhandle 0x00000004 Interesting in that: (1) A call to an .exe file ran 'properly' (under wsl) at all. [Who knew!] (Once I did, seemed worth a try, here.) (2) The surrounding os file redirection services (between cmd.exe and wsl.exe) are inconsistent - wsl.exe side behaviour better operating in the traditional and expected manner, than cmd.exe. > lsb_release -a ; uname -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy Linux host 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux On Mon, Mar 25, 2024 at 12:21?PM Werner Koch wrote: > > On Mon, 25 Mar 2024 08:33, Bee said: > > > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt > >> gpg: failed to translate osfhandle 0x00000003 > > gpg takes system handles and not libc file descriptors. File > descriptors 0, 1, and 2 are handled by Windows in a different. All > other depend on which ABI you work. cmd.exe seems to expect file > descriptors which is good for scripting but gpg is rarely used in such a > scripting environment but usuallay directly executed by CreateProcess > and thus expects HANDLE values and not file descriptors. > > See gnupg/common/sysutils.c:translate_sys2libc_fd > > Actually it would be possible to provide an option to disable this > translation and instead use libc file descriptors (with all the fun if > different runtimes are used) but in more than 20 years we have not seen > such a demand. > > > Salam-Shalom, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein From omcujl92 at duck.com Tue Mar 26 00:55:50 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Mon, 25 Mar 2024 19:55:50 -0400 Subject: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't. References: <87sf0egu5v.fsf@jacob.g10code.de> <3C0214E7-C18E-4327-AF1D-39E517C6CC86.1@smtp-inbound1.duck.com> Message-ID: Thank you. I don't follow all of that, such as deep diving into gnupg/common/sysutils.c:translate_sys2libc_fd , but I do get the answer is: Unsupported (at least at this time). Could you make whatever notation at dev.gnupg.org is appropriate, please? Summary: --passphrase-fd #, where # >= 3, fails under Windows / DOS %COMSPEC% == unsupported (at this time). So that, with that and this list, web searchers looking to figure out why the described '--passphrase-fd #' isn't working for them, stop chasing their tails? [i.e. it's not user error, it's a Windows (DOS) issue not yet worked around]. ----- It is curious that fd 4 produced the different result of triggering a graphical pinentry. I presume the file open failed and it fell back to that mechanism. And, interesting that under wsl: 'cat HelloWorld.txt | gpg.exe --pinentry-mode loopback --passphrase-fd 4 -c 4< HelloWorld.txt' returned the expected consistent result for fd 3. [with and without --pinentry-mode loopback] > gpg: failed to translate osfhandle 0x00000004 Interesting in that: (1) A call to an .exe file ran 'properly' (under wsl) at all. [Who knew!] (Once I did, seemed worth a try, here.) (2) The surrounding os file redirection services (between cmd.exe and wsl.exe) are inconsistent - wsl.exe side behaviour better operating in the traditional and expected manner, than cmd.exe. > lsb_release -a ; uname -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy Linux host 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux On Mon, Mar 25, 2024 at 12:21?PM Werner Koch wrote: > > On Mon, 25 Mar 2024 08:33, Bee said: > > > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt > >> gpg: failed to translate osfhandle 0x00000003 > > gpg takes system handles and not libc file descriptors. File > descriptors 0, 1, and 2 are handled by Windows in a different. All > other depend on which ABI you work. cmd.exe seems to expect file > descriptors which is good for scripting but gpg is rarely used in such a > scripting environment but usuallay directly executed by CreateProcess > and thus expects HANDLE values and not file descriptors. > > See gnupg/common/sysutils.c:translate_sys2libc_fd > > Actually it would be possible to provide an option to disable this > translation and instead use libc file descriptors (with all the fun if > different runtimes are used) but in more than 20 years we have not seen > such a demand. > > > Salam-Shalom, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein From wk at gnupg.org Tue Mar 26 15:48:06 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Mar 2024 15:48:06 +0100 Subject: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't. In-Reply-To: (Bee via Gnupg-users's message of "Mon, 25 Mar 2024 19:55:50 -0400") References: <87sf0egu5v.fsf@jacob.g10code.de> <3C0214E7-C18E-4327-AF1D-39E517C6CC86.1@smtp-inbound1.duck.com> Message-ID: <87frwdgic9.fsf@jacob.g10code.de> On Mon, 25 Mar 2024 19:55, Bee said: > Could you make whatever notation at dev.gnupg.org is appropriate, please? https://dev.gnupg.org/T7060 Already implemented a new option but you need to wait for gnupg 2.6. 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 code.soma.kurisu at gmail.com Thu Mar 28 00:49:44 2024 From: code.soma.kurisu at gmail.com (Christian Sommer) Date: Thu, 28 Mar 2024 00:49:44 +0100 Subject: x488 vs all other : keyid flip Message-ID: hi. i scrutinized the new, announcements, mailinglist history and the ietf drafts but still couldn't find out the reason for following observation. let's say we have an ed25519 key with the 40 hex character fingerprint of 1111 2222 3333 4444 0000 0000 AAAA BBBB CCCC DDDD then its long keyid is AAAA BBBB CCCC DDDD and its short keyid is CCCC DDDD. on the other hand a x488 fingerprint is 50 hex characters long. let's say it's 11111 22222 33333 44444 00000 00000 AAAAA BBBBB CCCCC DDDDD then its long keyid is 11111 22222 33333 4 and its short keyid is 22 33333 4. at least that is what gpg 2.4.4 displays. please shed some light on that observation. liberal regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien at cassou.me Thu Mar 28 08:26:39 2024 From: damien at cassou.me (Damien Cassou) Date: Thu, 28 Mar 2024 08:26:39 +0100 Subject: Get the private portion of subkeys Message-ID: <87y1a2stow.fsf@cassou.me> Hi, I have a usb smart card containing my subkeys and my master key is stored offline on a usb disk. When I list my secret keys while the usb disk is plugged in, I get: sec ed25519/0xF72C652AE7564ECC 2018-07-09 [C] [expires: 2027-12-21] Key fingerprint = 8E64 FBE5 45A3 94F5 D35C D202 F72C 652A E756 4ECC Keygrip = 35A4020C4AFC2279CEE0BC36E2CEE4EFA8C6CFD5 uid [ultimate] Damien Cassou uid [ultimate] Damien Cassou uid [ultimate] Damien Cassou ssb> ed25519/0xB68746238E59B548 2018-07-09 [S] [expires: 2026-01-02] Keygrip = C89E5AABCBF7142DBC26E68FB3121DE12DCBF4FF ssb> cv25519/0x65CD5E0200C56C17 2018-07-09 [E] [expires: 2026-01-02] Keygrip = 867EA9F6ADBEBE18ED98253B884F53CBD53C526B ssb> ed25519/0xF36CF32DF9B09855 2018-07-09 [A] [expires: 2026-01-02] Keygrip = 553D56865642B05AB3C5B62DC68795691702B960 As you can see, there is a '>' character before each subkey but not before the master key. Someone on the web has a similar setup but doesn't have the '>' before his subkeys [1]. Is that a problem? Am I missing something important? It seems this causes me the troubles mentioned at [1]. Recently, I changed my usb smart card and kept the same keys so I believe I have everything needed in some form. My private master key is symlinked in ~/.gnupg/private-keys-v1.d: $ ls -l ~/.gnupg/private-keys-v1.d/ ? 35A4020C4AFC2279CEE0BC36E2CEE4EFA8C6CFD5.key -> /media/mystick/key ? [1] https://github.com/pinpox/pgp2ssh/issues/6 -- Damien Cassou "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill From code.soma.kurisu at gmail.com Thu Mar 28 09:25:55 2024 From: code.soma.kurisu at gmail.com (Christian Sommer) Date: Thu, 28 Mar 2024 09:25:55 +0100 Subject: x488 vs all other : keyid flip In-Reply-To: References: Message-ID: excuse me sirs. when i wrote that question i was already very tired. so in the meantime i realized that there are different code paths for ed/x448 goldilocks. one of them distinguishes the Endiannes on behalf of the algorithm (e.g. sets is_little_endian to true | false in g10/ecdh.c). i haven't found the time to go much deeper yet, but this and the read_16 / 32 in g10/parse-packet.c as well as the convert_le_u16 / 32 functions in scd/ccid-driver.c / tools/ccidmon.c seem to play a role. i guess key-IDs are calculated on demand and not stored separately along fingerprints. based on what i've seen until now i tend to accept that the short keyid 22 33333 4 of above example is in fact right. on the next occasion my search will go on, but if anybody can confirm and tell even more about that observation, i'd be very grateful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Mar 28 10:47:38 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Mar 2024 10:47:38 +0100 Subject: x488 vs all other : keyid flip In-Reply-To: (Christian Sommer via Gnupg-users's message of "Thu, 28 Mar 2024 00:49:44 +0100") References: Message-ID: <87ttkqg01x.fsf@jacob.g10code.de> On Thu, 28 Mar 2024 00:49, Christian Sommer said: > on the other hand a x488 fingerprint is 50 hex characters long. let's say > it's 11111 22222 33333 44444 00000 00000 AAAAA BBBBB CCCCC DDDDD then its > long keyid is 11111 22222 33333 4 and its short keyid is 22 33333 4. x448 keys are created as version 5 keys and version 5 keys come with a 32 byte fingerprint (v4 has 20 bytes). Also the way the keyid is computed has changed: For v5 keys the keyid are the left most 32 or 64 bits. For display purposes an abbreviated hex format is used. It might be that the keyid is then display wrongly - frankly I have not checked because keyids are rarely used. Even the formatted fingerprint ("gpg --fingerprint") is not very useful anymore because the majority of users just copy+paste the fingerprint and thus the straight hex format as displayed by "gpg -k" is more useful. Here is an example: pub ed25519 2016-02-02 [SC] FD8FEC4F8595AB1B6F60D43FC2CED0800E50ACF1 uid [ unknown] chicago sub cv25519 2016-02-02 [E] 532D5C7677B4D806B50B0E0F11E7BF9EE1034B1C sub cv448 2024-03-27 [E] FB6A3BC5EB92C8AA9F3807A9B4C79C38F16E9AA4CF9384B07485923574773DCF where a v5 subkey has been added. Note also that I use the --with-subkey-fongerprint option which will eventually be the default. 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 wk at gnupg.org Thu Mar 28 11:01:15 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Mar 2024 11:01:15 +0100 Subject: Get the private portion of subkeys In-Reply-To: <87y1a2stow.fsf@cassou.me> (Damien Cassou via Gnupg-users's message of "Thu, 28 Mar 2024 08:26:39 +0100") References: <87y1a2stow.fsf@cassou.me> Message-ID: <87plvefzf8.fsf@jacob.g10code.de> 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 -------------- 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 alexander at kulbartsch.de Thu Mar 28 10:57:01 2024 From: alexander at kulbartsch.de (Alexander Kulbartsch) Date: Thu, 28 Mar 2024 10:57:01 +0100 Subject: Get the private portion of subkeys In-Reply-To: <87y1a2stow.fsf@cassou.me> References: <87y1a2stow.fsf@cassou.me> Message-ID: <47ad339c-dac3-48ba-9136-3e8f77a06356@kulbartsch.de> Hi Damien! On 28.03.24 08:26, Damien Cassou via Gnupg-users wrote: > As you can see, there is a '>' character before each subkey but not > before the master key. Someone on the web has a similar setup but > doesn't have the '>' before his subkeys [1]. The ">" indicates that the key is on a smartcard. (The > is the corner of a card ;) (Smartcard is synonym to USB tokens like YubiKeys) > Is that a problem? Am I missing something important? It seems this > causes me the troubles mentioned at [1]. In [2] it is mentioned, that the key marked with an [A] is needed. [A] indicates the "authentication" key. This is what you want. But the private part of your [A] key is only on the smartcard. And the security idea of the smartcard is, that you can not extract it from there. In [1] you described your 'gpg --export-secret-keys'. If you do a `gpg --list-packets ./damien.asc` on your export, you can see that this still references the card. So it won't work this way. But if it is about ssh login into another system you can use the gpg-agent as a the ssh-agent and get the security with your smartcard. You have to add 'enable-ssh-support' to your gpg-agent.conf. See: man gpg-agent > [1] https://github.com/pinpox/pgp2ssh/issues/6 [2] https://github.com/pinpox/pgp2ssh Best regards Alexander -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x213E2CD3CABCF0B9.asc Type: application/pgp-keys Size: 681 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From code.soma.kurisu at gmail.com Thu Mar 28 13:54:58 2024 From: code.soma.kurisu at gmail.com (Christian Sommer) Date: Thu, 28 Mar 2024 13:54:58 +0100 Subject: x488 vs all other : keyid flip In-Reply-To: <87ttkqg01x.fsf@jacob.g10code.de> References: <87ttkqg01x.fsf@jacob.g10code.de> Message-ID: you are absolutely right: 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. Likewise by telling GnuPG you really want the short keyID displayed (gpg --keyid-format short) it takes the LAST 32 bytes of the FIRST 64 bytes of the fingerprint. i prefer getting what i ordered. of course it's a trivial thing for my self counting the first eight hexadecimal characters to fulfill my particular use-case (i'd like to have matching mail-addresses and short key-IDs). although you gave the impression nobody would use those command line options (plainly because of that ?"fingerprint-forgery-attack" occurring on short key-IDs) why then don't ditch it? on the other hand, until it's here i feel inclined on fixing it. so if there are no objectiions i'd like to try myself on both errorneous outputs. as you may have notices it's just a few weeks ago when i discovered GnuPG for myself. so i'm completley new to this community what's the preferred development model? i guess filing an issue, forking the repository, making a pull-request, but there are also those T-numbers linked by releases. From wk at gnupg.org Thu Mar 28 14:42:50 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Mar 2024 14:42:50 +0100 Subject: x488 vs all other : keyid flip In-Reply-To: (Christian Sommer via Gnupg-users's message of "Thu, 28 Mar 2024 13:54:58 +0100") References: <87ttkqg01x.fsf@jacob.g10code.de> Message-ID: <8734safp5x.fsf@jacob.g10code.de> On Thu, 28 Mar 2024 13:54, Christian Sommer said: > Likewise by telling GnuPG you really want the short keyID displayed > (gpg --keyid-format short) it takes the LAST 32 bytes of the FIRST 64 > bytes of the fingerprint. The thing here is that the short keyid is not from the specification but a convenience thing PGP-2 implemented (which actually did not compute the keyid from the fingerprint). Yes, it would indeed be nicer if we could work with the keyid in the same way as git handles a commit id. Unfortunately it will be pretty hard to change how the short keyid is derived from the long keyid or even use arbitrary sized keyids of fingerprints. In GnuPG the keyid is a "u32 kid[2]" and this is used a lot all over the code, for example: fprint ("long keyid: %08lX%08lX\n", (ulong)kid[0], (ulong)kid[1]); fprint ("short keyid: %08lX\n", (ulong)kid[1]); > discovered GnuPG for myself. so i'm completley new to this community > what's the preferred development model? i guess filing an issue, See doc/HACKING for hints. Please also be aware that for any unattended use you need to use the --with-colons and --status-fd interfaces. Some ignore this advice and thus we are nice and try to minimize all changes even to the human readable output format. 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 Fri Mar 29 02:37:36 2024 From: omcujl92 at duck.com (omcujl92 at duck.com) Date: Thu, 28 Mar 2024 21:37:36 -0400 Subject: How can I 'echo' into fd 3 to be able to use it on a gpg cmd line? References: Message-ID: ===== Prologue: -------- Re-reading https://web.archive.org/web/20171225062127id_/http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true , I now notice '<& Reads the input from one handle and writes it to the output of another handle.' (Read from one, write to another.) So 'echo %passphrase% <&3' would seem to input from stdin and output it to fd 3. - I can?t think how to test this (under %COMSPEC%), though, and under everything else it doesn?t matter. [If it doesn?t work there, there are workarounds.] - Under %COMSPEC%, file descriptors being broken ? as below. ===== Answer / Solution: How can I 'echo' into fd 3 to be able to use it on a gpg cmd line? Summary: - [outside of %COMSPEC%], short answer: mkfifo myfifo; echo %passphrase% > myfifo & ; echo data | gpg ... 3< myfifo; unset passphrase ; rm myfifo. - [inside of %COMSPEC%], short answer: you can?t (*). %COMSPEC% file descriptors are broken. See thread ending at https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067020.html - cygwin64 is gnupg unsupported, and cygwin32 is deprecated. See https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067014.html for why. - even GnuWin (https://sourceforge.net/projects/gnuwin32/) [https://getgnuwin32.sourceforge.net/] is of no help, the root cause being %COMPEC%, everything run therein remains broken (in this regard) ? at least in terms of pipelining file descriptors outside of 0, 1, 2 == ?stdin, out, err?. So, for example, 3, 4, 5, 6, and beyond == ?stdwarn, verb, debug, info? [per https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_redirection] - use wsl, instead. [https://learn.microsoft.com/en-us/windows/wsl/install] (*) Afterward: - Werner kindly appended to the https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067020.html thread above, at https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067021.html, indicating that a workaround for this %COMSPEC% issue will be included in gnu2.6 ? with the addition of a ?--disable-fd-translation? optional parameter. (Proof of Concept) Goal (Reminder): - echo secret data | gpg ?pinentry-mode loopback ?passphrase-fd 3 -c 3< $(echo %passphrase%) ; unset passphrase [i.e. without any unencrypted data landing within your filesystems, pipe your sensitive data directly into gpg, towards direct secure storage. e.g. (web) BitWarden backup towards secure (local) storage should BitWarden servers ever become incommunicado (e.g. broken wi-fi or internet provider). BitWarden phones home before unlocking ? if it can?t get there, you?re S.O.L. - Nevermind the duplicate functionality of gpg vs Bitwarden, this is a backup, and Bitwarden offers turnkey cross-machine consistency out of the gate. - - But thank all that is holy for what GnuPG was, is, and will be. You want to have both applications to hand. Proof of Concept example script solutions: ===== gpggetpin-wsl.cmd: ----- @rem #! %COMSPEC% @echo off set "GOTPASSPHRASE=" for /f "delims=" %%p in ('wsl /mnt/c/bin/gpggetpin.bash') do set "GOTPASSPHRASE=%%p" set /p "scratch=%GOTPASSPHRASE%" < nul: set ? GOTPASSPHRASE=? ===== gpggetpin.bash: ----- #! /usr/bin/env bash # gpggetpin.bash: # SHORT VERSION: # GPG_TTY=$(tty) ; printf "GETPIN\n" | pinentry -T "${GPG_TTY}" | sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //" bash -n "${0}" || true shellcheck -W 0 -Calways "${0}" || true # printf "getpin\n" | pinentry -g -T "$(tty)" # - NOT HAPPY! declare -g GPG_TERM ; GPG_TERM="${TERM}" ; export GPG_TERM declare -g GPG_TTY ; GPG_TTY="$(tty)" ; export GPG_TTY declare -g gs_passphrase="-1" declare -gi gi_0=-1 gs_passphrase=\ "$( \ printf "SETDESC My description\nSETPROMPT My prompt\nSETTITLE My window title, iif there is a window\nGETPIN\nBYE\n" \ | pinentry --debug --ttyname "${GPG_TTY}" --ttytype "${GPG_TERM}" --lc-ctype "en_ca.UTF-8" --lc-messages "en_ca.UTF-8" \ | sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //" \ )" gi_0="${?}" # USELESS - too many progs (retcodes) between source and end. if false ; then { (( ! gi_0 )) && { printf "\n:: passphrase retrieval failed (%d), exiting.\n\n" "${gi_0}" ; exit "${gi_0}" ; } } ; fi case "${gs_passphrase}" in ( "-1" );& ( "" );& ( "ERR 83886179 Operation cancelled " ) # printf ":: no valid password retrieved (%d)[%d]. Exiting.\n\n" "${gi_0}" "${#gs_passphrase}" exit "${gi_0}" ;; (*);; esac # printf ":: passphrase retrieved (%d)[%d].\n\n" "${gi_0}" "${#gs_passphrase}" # printf "\n|%s|\n\n" "${gs_passphrase}" printf "%s" "${gs_passphrase}" unset gs_passphrase ===== gpgtest-wsl.cmd: ----- @rem #! %COMSPEC% @echo off wsl /mnt/c/bin/gpgtest.bash ===== gpgtest.bash: ----- #! /usr/bin/env bash printf "\n" set -vx declare -g gs_mysecretpassphrase="KXhtctw4_zFfhRop" # More usually acquired somehow else. declare -g gs_myfifo="$(mktemp -ut fifo.XXX)" mkfifo -m 0600 "${gs_myfifo}" printf "%s" "${gs_mysecretpassphrase}" > "${gs_myfifo}" & ## Proof of concept, herein, being passphrase as passphrase being used upon passphrase as data, encrypted to stdout. ## - $0 Caller redirecting stdout into desired destination filename. printf "%s" "${gs_mysecretpassphrase}" | gpg --pinentry-mode loopback --passphrase-fd 3 -c 3< "${gs_myfifo}" ; printf "\n" rm "${gs_myfifo}" set +xv unset gs_mysecretpassphrase ===== -30- On Mon, Mar 18, 2024 at 5:51?PM B.S. wrote: > > ... (Windows 10) [DOS] cmd ... [*NOT* powershell] > ... cygwin gpg ... > > How can I 'echo' into fd 3 to be able to use it on a gpg cmd line? > e.g. 'echo "Secret data" | gpg.exe -c -passphrase-fd 3 3< echo %PASSWORD%' > > [Ignore the need, or not, for --batch and/or --pinentry-mode loopback, > I can wrestle with those separately.] > (I am trying to avoid the passphrase from appearing in cleartext > within tasklists, etc.) > > > I am working on a BitWarden(-cli) backup script. So the 'echo "Secret > data"' above is actually something like: > bitwarden-cli --export json | gpg -c ... >...bitwarden_backup.json.pgp > - the hangup seems to be how to echo into 3< to be able to use it as > input, for ' -passphrase-fd 3'. > > [Or 7< echo %PASSWORD%, for that matter - it seems powershell uses 3-6 > for stdwarn|verbose|debug|info, and probably best to avoid potential > future conflicts.] From andrewg at andrewg.com Fri Mar 29 14:00:38 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 29 Mar 2024 13:00:38 +0000 Subject: x488 vs all other : keyid flip In-Reply-To: <87ttkqg01x.fsf@jacob.g10code.de> References: <87ttkqg01x.fsf@jacob.g10code.de> Message-ID: On 28 Mar 2024, at 09:47, Werner Koch via Gnupg-users wrote: > > x448 keys are created as version 5 keys and version 5 keys come with a > 32 byte fingerprint (v4 has 20 bytes). ... > Here is an example: > > pub ed25519 2016-02-02 [SC] > FD8FEC4F8595AB1B6F60D43FC2CED0800E50ACF1 > uid [ unknown] chicago > sub cv25519 2016-02-02 [E] > 532D5C7677B4D806B50B0E0F11E7BF9EE1034B1C > sub cv448 2024-03-27 [E] > FB6A3BC5EB92C8AA9F3807A9B4C79C38F16E9AA4CF9384B07485923574773DCF > > where a v5 subkey has been added. V5 subkeys of v4 primary keys would appear to introduce a novel failure mode. It should be noted that in crypto-refresh, adding a non-v4 subkey to a v4 primary key is explicitly forbidden: > Every subkey for a v4 primary key MUST be a v4 subkey. https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-13#section-10.1.3 I notice in the LibrePGP draft that there is no specification of this hybrid v4/v5 construction. The corresponding section of the spec doesn?t even mention v5 TPKs at all, just v3 and v4: https://datatracker.ietf.org/doc/html/draft-koch-librepgp#name-key-structures This appears to be a verbatim copy of the corresponding section from RFC4880 that has not (yet) been updated to take account of v5: https://datatracker.ietf.org/doc/html/rfc4880#section-12.1 So a few questions arise: is this a deliberate design decision, and if so what considerations were taken into account in that design, and 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 damien at cassou.me Sat Mar 30 17:20:58 2024 From: damien at cassou.me (Damien Cassou) Date: Sat, 30 Mar 2024 17:20:58 +0100 Subject: Get the private portion of subkeys In-Reply-To: <87y1a2stow.fsf@cassou.me> References: <87y1a2stow.fsf@cassou.me> Message-ID: <87sf07wv11.fsf@cassou.me> Thank you both for your answers. I would like to understand why restoring the backup doesn't restore my subkeys. On a fresh ~/.gnupg, I did: $ gpg --list-packets /media/mystick/key gpg: keybox '/home/cassou/.gnupg/pubring.kbx' created # off=0 ctb=94 tag=5 hlen=2 plen=134 :secret key packet: ? # off=136 ctb=b4 tag=13 hlen=2 plen=32 :user ID packet: "Damien Cassou " ? # off=974 ctb=9c tag=7 hlen=2 plen=134 :secret sub key packet: version 4, algo 22, created 1531155780, expires 0 pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1) pkey[1]: [263 bits] ? keyid: F36CF32DF9B09855 ? The last key printed here is the one I would like to import back. Unfortunately, importing this file doesn't import subkeys: $ gpg --import-options restore --import /media/mystick/key gpg: key F72C652AE7564ECC: secret key imported gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg -K gpg: /home/cassou/.gnupg/trustdb.gpg: trustdb created /home/cassou/.gnupg/pubring.kbx ------------------------------- sec ed25519 2018-07-09 [C] [expired: 2023-07-08] 8E64FBE545A394F5D35CD202F72C652AE7564ECC uid [ expired] Damien Cassou Can someone explain why I don't get my subkeys back please? Thank you -- Damien Cassou "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill From alexander at kulbartsch.de Sat Mar 30 20:23:57 2024 From: alexander at kulbartsch.de (Alexander Kulbartsch) Date: Sat, 30 Mar 2024 20:23:57 +0100 Subject: Get the private portion of subkeys In-Reply-To: <87sf07wv11.fsf@cassou.me> References: <87y1a2stow.fsf@cassou.me> <87sf07wv11.fsf@cassou.me> Message-ID: Hi Damien! Upfront some information you might probably already know. When you "normally" create a new public/private key pair technically *two* key pairs are created. Cross check with "gpg -K". One secret key (sec) for signing and certify marked [SC] and another one, a secret sub key (ssb) for encryption. You can see this when you look into the .gnupg/private-keys-v1.d folder. There are two new keys. From your "gpg -K" output I see, that you separated the your certify and signing key (and also created an authorization key [A]). Your [S], [E] and [A] private keys are only on the card. Your mounted/linked USB drive does *only* seem to hold the [C] key. Otherwise it would not need the card and indicate this with the cards corner ">". When you now export your key as you did with gpg --export-secret-keys --armor F72C652AE7564ECC > sec.asc you could only export your private [C] key. It is impossible to extract them from the from the smartcard. When you call "gpg --list-packets sec.asc" I assume you see something like "gnu-divert-to-card, ..." under your subkeys, but not under your primary [C] key. (This part you left out with ?.) Correct? I hope this helps. If you have any questions give us some more hints where (the above explanation) diverges from what you expect. Best regards Alexander On 30.03.24 17:20, Damien Cassou wrote: > Thank you both for your answers. I would like to understand why > restoring the backup doesn't restore my subkeys. On a fresh ~/.gnupg, I > did: > > $ gpg --list-packets /media/mystick/key > gpg: keybox '/home/cassou/.gnupg/pubring.kbx' created > # off=0 ctb=94 tag=5 hlen=2 plen=134 > :secret key packet: > ? > # off=136 ctb=b4 tag=13 hlen=2 plen=32 > :user ID packet: "Damien Cassou " > ? > # off=974 ctb=9c tag=7 hlen=2 plen=134 > :secret sub key packet: > version 4, algo 22, created 1531155780, expires 0 > pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1) > pkey[1]: [263 bits] > ? > keyid: F36CF32DF9B09855 > ? > > The last key printed here is the one I would like to import > back. Unfortunately, importing this file doesn't import subkeys: > > $ gpg --import-options restore --import /media/mystick/key > gpg: key F72C652AE7564ECC: secret key imported > gpg: Total number processed: 1 > gpg: unchanged: 1 > gpg: secret keys read: 1 > gpg: secret keys imported: 1 > > $ gpg -K > gpg: /home/cassou/.gnupg/trustdb.gpg: trustdb created > /home/cassou/.gnupg/pubring.kbx > ------------------------------- > sec ed25519 2018-07-09 [C] [expired: 2023-07-08] > 8E64FBE545A394F5D35CD202F72C652AE7564ECC > uid [ expired] Damien Cassou > > > Can someone explain why I don't get my subkeys back please? > > Thank you > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x213E2CD3CABCF0B9.asc Type: application/pgp-keys Size: 681 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: