Re: S/MIME which certificate format
Hello, Am Mittwoch 12 Juni 2024 21:37:11 schrieb Marco Moock: > I got an S/MIME certificate from Sectigo, which I would like to use > with gpgsm/Kleopatra. does Sectigo offer a public certificate somewhere which could possibly be imported for a test? The message gpgsm: unknown digest algorithm '?' used certificate from 2.2.43 let me assume that the algorithm is unknown to GnuPG. However this could be wrong. Regards Bernhard -- https://intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
How to ask for support (was: S/MIME which certificate format)
Hi! If you send bug reports or asking for support please always tell us the version of GnuPG you are using as well as the operating system and its version. The latter part is needed because Linux distributions often apply a lot of custom changes to software which are not reflected by the version number. gpgconf -V gives a verbatim description of the version and the used libraries. gpgconf -X lists all configuration files along wity some other info. Take care to redact lines which you consider sensitive. In case you are running a very old version of GnUPG, use "gpg --version" instead. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: which application enables allow‐ocsp in dirmngr.conf?
On Mon, 17 Jun 2024 14:43, Marco Moock said: > It wasn't, I enabled it, but the error stays. I doubt that it is due to the gnupg version but we are anyway interested to see that. The output of gpgconf -X might also be useful becuase it also lists any global configuration. (Please redact private configuration stuff) Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: S/MIME which certificate format
Hi If you have access to the Kleopatra gui, you can just open the .cert with Kleopatra. And than it will ask you for the password with the cert and let you set a new one. Once Kleopatra accepted the cert, gpg will sync it. Eason ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Help With GPG trust model
Thank you Francesco that does help, I did not realize that by signing the public key, it is also mark as trusted, thanks Eason ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Detecting a misremembered passphrase in gpg-agent
On Thu, Jun 13, 2024 at 02:09:15PM -0400, Jack via Gnupg-users wrote: > On 2024.06.13 06:57, ael via Gnupg-users wrote: > > Further thoughts on detecting a mistaken passphrase entry when > > encrypting. I have looked at both > > man gpg-agent and info [...snip..] > I'm no expert in this area, but something struck me - is the passprase you > are entering protecting the key you are using for encryption, or is the > passphrase itself being used for encryption? I am using symmetric encryption, so the usual public/private keys are not relevant in this situation. > Does this help at all, or have I missed something? Unless I too have missed something, then I don't think this applies to the symmetric case. But thanks for the suggestion. In passing, for further background, all of this is happening on an mounted encrypted volume. I am guarding against malware that might be able to read the temporarily decrypted file. At least the other files on the mounted volume are protected by the second level of gpg symmetric encryption. Rather like a password manager that handles more general files with the manager database only on the (temporarily mounted) encrypted volume. ael _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Detecting a misremembered passphrase in gpg-agent
On 2024.06.13 06:57, ael via Gnupg-users wrote: Further thoughts on detecting a mistaken passphrase entry when encrypting. I have looked at both man gpg-agent and info and I could not immediately see anything to help, but I quickly became lost in the overwhelming volume of the entries :-) So perhaps there is something there that I have missed. The user case is not the "usual" use of gpg for communicating with 2nd parties. Rather I am using symmetric encryption on local files and usually using a common (long) passphrase on a common set of those files. The plain text file is deleted after encryption for security. So if I make a mistake in entering the passphrase I have lost access. pinentry asks me to repeat the passphrase and that is obviously the main defence against getting things wrong. However, I am quite capable of misremembering a component of a passphrase that I have not used for a long time, or even using the wrong passphrase in an absent-minded moment. Having to repeat a long passphrase is quite laborious, and the suggestion below would solve that. My simple suggestion is that there be an option, perhaps even a tick-box on the entry window, that displays a checksum/fingerprint/hash of the entered passphrase. That hash can then be checked perhaps manually, perhaps directly against the known hash of the passphrase. If it is checked manually, it needs to be quite short. If the hash matches, there is no need to re-enter the passphrase. It also guards against re-entering a misremembered phrase. Something like this would be a huge improvement for my use case. Probably useful more generally. Of course, you would still need double entry when initially setting up a passphrase which does not yet have a hash. ael I'm no expert in this area, but something struck me - is the passprase you are entering protecting the key you are using for encryption, or is the passphrase itself being used for encryption? From your description, it seems like the latter. If you had created a key for the encryption, and then protected that key with the passphrase, then mistyping the passphrase would just get you a failure and not a successful encryption with the wrong key. Does this help at all, or have I missed something? Jack ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Help With GPG trust model
Hi, I am writing this email to ask for help with how to GPG trust model works. I have a PGP public key, key A. In GPG if I do gpg --edit-key A trust then set full trust (4), it is still shown as unknown, rather than full, is there any way to solve this rather than marking it as 5. Thanks Eason ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Detecting a misremembered passphrase in gpg-agent
I wrote just now: "Further thoughts on detecting a mistaken passphrase entry when encrypting. I have looked at both man gpg-agent and info and I could not immediately see anything to help, but I quickly became lost in the overwhelming volume of the entries :-) So perhaps there is something there that I have missed." It may be that a should be using the ssh-support mode and perhaps avoiding the problem via SSH keys. ael ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Detecting a misremembered passphrase in gpg-agent
Further thoughts on detecting a mistaken passphrase entry when encrypting. I have looked at both man gpg-agent and info and I could not immediately see anything to help, but I quickly became lost in the overwhelming volume of the entries :-) So perhaps there is something there that I have missed. The user case is not the "usual" use of gpg for communicating with 2nd parties. Rather I am using symmetric encryption on local files and usually using a common (long) passphrase on a common set of those files. The plain text file is deleted after encryption for security. So if I make a mistake in entering the passphrase I have lost access. pinentry asks me to repeat the passphrase and that is obviously the main defence against getting things wrong. However, I am quite capable of misremembering a component of a passphrase that I have not used for a long time, or even using the wrong passphrase in an absent-minded moment. Having to repeat a long passphrase is quite laborious, and the suggestion below would solve that. My simple suggestion is that there be an option, perhaps even a tick-box on the entry window, that displays a checksum/fingerprint/hash of the entered passphrase. That hash can then be checked perhaps manually, perhaps directly against the known hash of the passphrase. If it is checked manually, it needs to be quite short. If the hash matches, there is no need to re-enter the passphrase. It also guards against re-entering a misremembered phrase. Something like this would be a huge improvement for my use case. Probably useful more generally. Of course, you would still need double entry when initially setting up a passphrase which does not yet have a hash. ael ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent timeout
On Mon, Jun 10, 2024 at 08:54:56AM +0200, Werner Koch wrote: > Hi > > which pinnetry are you you using? If you run gpg with -v it should dhow > the pinentry used. gpg: pinentry launched (8131 gnome3 1.2.1 /dev/pts/3 xterm-256color :0.0 20620/500/5 500/500 -) While you are here, I am just trying to find a good stategy to detect typing errors in the passphrase when encoding. I know that you/pinentry require the pasphrase to be entered twice, but maybe CAPS lock was on and I had not noticed. Or I just am having a bad day I miss one of the words in a long passphrase. Maybe a bit paranoid. >From my initial experiments, pinentry does not remember an encryption passphrase for the next decryption, and I can see why. For now, I have set up a test file with an encrypted version. So after I have encrypted a real file, I can then also encrypt the test file and check that it matches the encypted test. This depends on pinentry remembering the possibly incorrect passphrase long enough to make the check. I have not tried the --enhanced switch which perhaps is going in this direction, although I need to find out how to set that when starting gpg2. Maybe it is on the man page, but it is so lon that it is hard to find things there. I will copy to the list since others may have similar concerns. Thanks for all the work, ael ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GNU Privacy Handbook typo
On Sat, Jun 08, 2024 at 03:26:05AM +, Eric Pruitt via Gnupg-users wrote: > On Fri, Jun 07, 2024 at 06:03:22PM -0500, Jacob Bachmeyer via Gnupg-users > wrote: > > Strictly, "their" is plural in English > > No, it is not. "They" and "their" have been used as gender-neutral, > singular pronouns for centuries. Even if that wasn't the case, it's > widely accepted in modern colloquial usage. We can't just ossify the > language because some people don't like that a word can have multiple, > context-sensitive meanings. "They/their" isn't even unique in that > manner when it comes to pronouns; "we" has been used as a singular > pronoun for royalty for centuries, and "you" can be both singular and > plural depending on the context -- at least in some American dialects. Thou hast raised some interesting points, but the overriding point here should be that a pronoun, any pronoun, doesn't fit there; the sentence wants an article. -- Mark H. Wood Lead Technology Analyst University Library Indiana University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 library.indianapolis.iu.edu signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent timeout
Hi which pinnetry are you you using? If you run gpg with -v it should dhow the pinentry used. You will then see a line like: gpg: pinentry launched (22013 gtk2 1.2.1 /dev/pts/11 xterm localhost:10.0 20620/1000/5 1000/1000 -) Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
request for account on dev.gnupg.org
Hello, I would like an account in order to report a bug handle: modernNeo shown name: Jace M. email: jaymans...@proton.me -JM Sent with [Proton Mail](https://proton.me/) secure email.___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GNU Privacy Handbook typo
On Fri, Jun 07, 2024 at 11:47:08PM -0500, Jacob Bachmeyer via Gnupg-users wrote: > Few English-as-a-foreign-language courses should be expected to > mention singular "they", so its use is inappropriate in documentation. There are lots of things that aren't taught in classrooms that still apply to the real world regardless of the subject. I don't expect people to know everything about English, but I do expect that people be open to learning new things, and anyone capable of learning English well enough to understand technical documentation should also be able to understand that "they" can be singular. I don't think it's all that different from understanding that "he" and its equivalents in many languages can be masculine and feminine depending on the context, a trait that's common to a lot of non-native English speakers' native languages. Eric ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GNU Privacy Handbook typo
Eric Pruitt wrote:
On Fri, Jun 07, 2024 at 06:03:22PM -0500, Jacob Bachmeyer via Gnupg-users wrote:
Strictly, "their" is plural in English
No, it is not. "They" and "their" have been used as gender-neutral,
singular pronouns for centuries. Even if that wasn't the case, it's
widely accepted in modern colloquial usage.
Colloquial usage is /highly/ inappropriate in a reference that needs to
be understood by people for whom English is a second language and who
may have limited English proficiency. Few English-as-a-foreign-language
courses should be expected to mention singular "they", so its use is
inappropriate in documentation.
We can't just ossify the
language because some people don't like that a word can have multiple,
context-sensitive meanings.
Clarity is important here; if we can avoid requiring the reader to
understand context-sensitive meanings, we should.
"They/their" isn't even unique in that
manner when it comes to pronouns; [...]
While it can have that meaning, it is still wrong in this context: we
have "...you can be sure that the key really does belong to him..." just
before the typo, therefore, the correct correction is to say "the key"
or "his key", but the former is more specific that we are talking about
the same key in both places, while the latter could describe one key
that you are certain belongs to someone and /another/ key (possibly also
belonging to the same person) that you have signed.
(It might also be interesting that I made (and fixed) the exact same
typo ("they" instead of "the") while typing <<"the key">> in the above
paragraph.)
The broader context is:
[...] a correspondent's key is validated by personally checking his
key's fingerprint and then signing his public key with your private
key. By personally checking the fingerprint you can be sure that the
key really does belong to him, and since you have signed they key, you
can be sure to detect any tampering with it in the future.
This suggests a better correction: "...since you have signed *that* key..."
-- Jacob
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GNU Privacy Handbook typo
On Fri, Jun 07, 2024 at 06:03:22PM -0500, Jacob Bachmeyer via Gnupg-users wrote: > Strictly, "their" is plural in English No, it is not. "They" and "their" have been used as gender-neutral, singular pronouns for centuries. Even if that wasn't the case, it's widely accepted in modern colloquial usage. We can't just ossify the language because some people don't like that a word can have multiple, context-sensitive meanings. "They/their" isn't even unique in that manner when it comes to pronouns; "we" has been used as a singular pronoun for royalty for centuries, and "you" can be both singular and plural depending on the context -- at least in some American dialects. Eric ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GNU Privacy Handbook typo
Patrick F. Marques via Gnupg-users wrote: Hi, I was reading the gnupg documentation and although I’m not an English native, I believe there is a “tiny” typo in this page https://www.gnupg.org/gph/en/manual/x334.html In the first paragraph: (…) By personally checking the fingerprint you can be sure that the key really does belong to him, and since you have signed they key, (..) I believe it should be “their key” instead of “they key” Strictly, "their" is plural in English and the antecedent here would be singular, since the text has already referred to the key's owner as "him". A better way to fix the typo would be to change "they key" to "the key" instead. -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg-agent timeout
I wanted to use a long passphrase for some local symmetric encryption but gpg-agent kept timing out before I could fully enter the fullphrase. I looked at the man page and it was not clear to me whether --pinentry-timeout was relevant. And "A Pinentry may or may not honor this request." was not promising. In the event I used a shorter passphrase, but I would like higher security. My use case was to encrypt a fair number of files with the same passphrase, but --multifile did not work with --symmetric. In the event, afer taking the machine off line, I copied the passphrase to the clipboard and pasted it into gpg-agent (which also has a rather small window). Perhaps I could have written a short script somehow. But I felt that gpg-agent was working against at every turn, and forcing me into insecure practices. Although I have been using gpg for a long time, although rarely and only for the usual email case, I am still a novice. What am I missing? ael ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
GNU Privacy Handbook typo
Hi, I was reading the gnupg documentation and although I’m not an English native, I believe there is a “tiny” typo in this page https://www.gnupg.org/gph/en/manual/x334.html In the first paragraph: (…) By personally checking the fingerprint you can be sure that the key really does belong to him, and since you have signed they key, (..) I believe it should be “their key” instead of “they key” Also, according to https://www.gnupg.org/gph/en/manual/book1.html bug reports concerning the GNU Privacy Handbook should be sent to Mike Ashley (), however e-mails sent to that given address bounce, which is why I'm reporting here. Best, Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Nuevo GUANTE MULTI - 120VEF - Para múltiples tareas!!!
Su Cliente de Mail NO soporta mensajes en formato HTML. Para ver correctamente el contenido del correo COPIE y PEGUE la siguiente URL en su Navegador Web (Chrome / Internet Explorer / FireFox / Safari) https://app.embluemail.com/OnlineV2/VON.aspx?data=4zjYArD3VqIxTGY%2Bq7hHPDezSzFKpV3R8UJReadlU502S0z2zrnbQg4lxNhifBRUvEpz0yH4%2BwByMD%2Bn3LQ1%2BtP1nMSlLv7U68jman61Fkxg20dEOq%2BWlt9DBW2WxjnQ!-!D1BKUkDs11oYwYWfr/DHf6NNeVCes0eGwQS85frnS0r3Dya0aZYIEpksscUFoLgl___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Restructure Keys.
Just create a new S-only subkey. There's no need to remove the S capability from the primary key because the signing key is only used by yourself and you know that you want to use the subkey for signing. Right. In case someone wants to do this anyway there is a hidden command "changeusage" in the --edit-key menu. Take care, this creates as usual a new self-signature. Okay. So, if the places where my key is referred using fingerprint of the primarykey, it doesn't matter whether I add/del subkeys as their OpenPGP implementation can still search using the same fingerprint and choose the right key (new subkey-S) for signature-verification, correct? Regards, RG. OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Restructure Keys.
On Wed, 5 Jun 2024 21:43, Ingo Klöcker said: > Just create a new S-only subkey. There's no need to remove the S capability > from the primary key because the signing key is only used by yourself and you > know that you want to use the subkey for signing. Right. In case someone wants to do this anyway there is a hidden command "changeusage" in the --edit-key menu. Take care, this creates as usual a new self-signature. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Restructure Keys.
Hello Folks! How do I restructure my keys from current/old setup to new setup? Current/Old Setup: PrimaryKey - CS SubKey - E New Setup: PrimaryKey - C SubKey1 - E Subkey2 - S I think of two options. Option 1: Create new SubKey with E-only and change usage of PrimaryKey to C-only. The major caveat is I'll have to update the fingerprint of signing key at multiple places. Option 2: Create new PrimaryKey with C-only and add the OldPrimaryKey+OldSubKey as SubKeys. I came across this option in this post, https://security.stackexchange.com/questions/32935/migrating-gpg-master-keys-as-subkeys-to-new-master-key This way, I don't have to update my signing key fingerprint at multiple places and continue using same signing key for consistency. Is Option 2 safe to do so? I tried something else (Option 3?) that is close to Option 2. I created new PrimaryKey with C-only. Then by editing new PrimaryKey, I did 'addkey' with the option 'Existing key' and used the keygrip of old PrimaryKey. The new PrimaryKey now has the old PrimaryKey as its SubKey. While the migrated key has same keygrip at both places, the fingerprint differs, which is a bummer (caveat of Option 1). Thoughts? Regards, Raghav "RG" Gururajan. OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WSL2: Gpg4win pinentry not available after PIN cache expires
Hi! >- Sign git commits in WSL2(Debian) >- gpg-agent uses Gpg4win's pinentry GUI to allow PIN entry So you are mixing Unix software with Windows software. I wonder that this works at all. The properties of the IPC between Windows and Unix are different. That IPC is not designed to work cross-platform. The Windows gpg-agent expects a Windows pinentry and vice versa. Using the native Windows gpg from the WSL git should work because there is a well defined interface between them. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding new uid to causes bad signature
Hey there! There's been a bit of an interesting development which I think explains the issues I've been having, I'm just not sure if there's a way to recover this. I found out that gpg has a way to run the --full-gen-key option using an existing key from card. $ gpg --expert --full-gen-key Your selection? 14 (Existing key from card) Available keys: (1) 4DCD2F5D0F303B60FAFDB469BA33F314281B2D1B OPENPGP.1 ed25519 (cert,sign*) (2) 993197BDCB9A09A16C4918DED4310EEF4B6582E2 OPENPGP.2 cv25519 (encr*) (3) EB59A450FF4E1B233C523B860E458EF6D043DFE8 OPENPGP.3 ed25519 (sign,auth*) So far, so good, however if I then continue with option 1, I get a key with key ID 6AA6FC5597E89BDC19ADD6AFCF2FEC503A89BCFF, and this allows me to add more UIDs as I deem fit. Now... that's weird. My key so far had key id 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 I delete the keys from my keyring again (leaving yubikey intact), and run the same for option 3. Now I do get key id 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3. But I can't create UIDs. However, GPG grants this the capabilities SCA Where did that C come from? Probably because that's now the primary key? My best bet is that when I originally made this key, I uploaded the keys into the wrong slots on the yubikey, which I believe have a fixed capability-set? Either way, it feels like that at this point... I'm screwed. Unless there's a way to rectify this? Thank you all for your time so far. Yours, Rens Rikkerink ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: setup of OpenPGP card not asking for keysize
On Sun, 12 May 2024 15:22, Matthias Apitz said: > I did a factory reset and changed the keylength with the subcommand > 'key-attr' to 4096. All fine and one must be patient as the key > 'generate' takes significantly longer. That's why I always suggest to use ECC instead of RSA on smartcards. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 2.2.43 and vsd-allow-ocb
On Mon, 6 May 2024 18:26, Andreas Metzler said: > So in my test (without --compliance=de-vs) 2.2.43 /should/ have > automatically used OCB when encrypting for a key which has 'AEAD: OCB' > set? Yes.Check with --debug=lookup which and why keys are selected. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 2.2.43 and vsd-allow-ocb
Hi! On Sat, 4 May 2024 18:45, Andreas Metzler said: > rG0a355b2fe7d8 gpg: Add compatibility flag "vsd-allow-ocb" > rGa545e14e8a74 gpg: Support OCB encryption. > Which understand to mean that 2.2.43 would by default both generate keys > with 'AEAD: OCB' and use OCB when encrypting to keys with that flag set. > And this behavior could have been disabled with '--compatibility-flags No misunderstood this. OCB encryption is indeed supported regardless of the compatibiliy flag. What the compatibility flag does is to allow OCB also in --compliance=de-vs mode. This was required because at the time of the release we had not yet an approval to use this for VS-NfD/Restricted communication. Thus in the GnuPG VS-Desktop configuraion this option is only set after we received the approval. For key generation the flag is indded not set by default: /* For now we require a compat flag to set OCB into the preferences. */ if (!(opt.compat_flags & COMPAT_VSD_ALLOW_OCB)) ocb = 0; Becuase we don't want to create key so that sites required to use de-vs compliance mode won't end up with keys which claim to support a non-approved encryption scheme. Thanks for this reminder, that compatibility flag can now be removed. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding new uid to causes bad signature
Hey there Werner! And thank you too for your reply. > Please run > > gpg-card > > to get infos on the card and used keys. No problem at all: $ gpg-card Reader ...: Yubico YubiKey OTP FIDO CCID 0 Card type : yubikey Card firmware : 5.4.3 Serial number : D27600012401000622314520 Application type .: OpenPGP Version ..: 3.4 Displayed s/n : 22 314 520 Manufacturer .: Yubico (6) Name of cardholder: Rens Rikkerink Language prefs ...: en Salutation ...: Mr. URL of public key : https://github.com/ikkerens.gpg Login data ...: [not set] Signature PIN : not forced Max. PIN lengths .: 127 127 127 PIN retry counter : 3 0 3 Signature counter : 1192 Capabilities .: key-import algo-change button priv-data KDF setting ..: on UIF setting ..: Sign=off Decrypt=off Auth=off Signature key : 4DCD2F5D0F303B60FAFDB469BA33F314281B2D1B keyref .: OPENPGP.1 (sign,cert) algorithm ..: ed25519 stored fpr .: 6AA6FC5597E89BDC19ADD6AFCF2FEC503A89BCFF created : 2022-10-26 18:20:54 used for ...: OpenPGP main key .: fpr ..: 6AA6FC5597E89BDC19ADD6AFCF2FEC503A89BCFF created ..: 2022-10-26 18:20:54 user id ..: Rens Rikkerink user id ..: Rens Rikkerink Encryption key: 993197BDCB9A09A16C4918DED4310EEF4B6582E2 keyref .: OPENPGP.2 (encr) algorithm ..: cv25519 stored fpr .: FA57A5CBF68A422B1A54AC49A17864EE2C2102F8 created : 2022-10-26 18:21:17 used for ...: OpenPGP main key .: fpr ..: FA57A5CBF68A422B1A54AC49A17864EE2C2102F8 created ..: 2022-10-26 18:21:17 user id ..: Rens Rikkerink user id ..: Rens Rikkerink Authentication key: EB59A450FF4E1B233C523B860E458EF6D043DFE8 keyref .: OPENPGP.3 (sign,auth) algorithm ..: ed25519 stored fpr .: 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 created : 2022-10-26 18:20:28 used for ...: OpenPGP main key .: fpr ..: 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 created ..: 2022-10-26 18:20:28 user id ..: Rens Rikkerink user id ..: Rens Rikkerink > Given that you have an uncommon primary key Out of sheer curiosity, would you mind enlightening me on what part of my primary key is "uncommon"? Yours, Rens Rikkerink ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding new uid to causes bad signature
Hi! Given that you have an uncommon primary key I would like to see some information of the card. Please run gpg-card to get infos on the card and used keys. In case you don't want to share this with the list, feel free to send it to Eva or me directly (w...@gnupg.org - no html parts). Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding new uid to causes bad signature
Hey there Eva! And thank you for your reply. > For my key and using gpg 2.4.5 on a standard Windows 10 system "check" didn't > give an error and signing a document worked without any issues. I should perhaps clarify that signing anything else (documents, git commits) seems to work just fine. I can sign things, and then verify the signature, and it matches. My issue seems to solely relate to signing an extra uid. > Importing your second pubkey did not change anything noticeable, gpg reported > no changes on the key and there is no new UID to be seen. That is not the behaviour I am seeing on my end: $ gpg --import before.asc gpg: key 29AD46D6F58287A3: public key "Rens Rikkerink " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found $ gpg --import after.asc gpg: key 29AD46D6F58287A3: 1 bad signature gpg: key 29AD46D6F58287A3: "Rens Rikkerink " not changed gpg: Total number processed: 1 gpg: unchanged: 1 As you can see here, the second public key does trigger a slightly different response for me (1 bad signature), so it ignores it and marks the public key as otherwise unchanged. > To avoid any confusion does > > gpg -k 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 > > show the new UID for you? Yes, it does: $ gpg -k 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 gpg: checking the trustdb gpg: no ultimately trusted keys found pub ed25519 2022-10-26 [CA] 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 uid [ unknown] Rens Rikkerink uid [ unknown] Rens Rikkerink sub ed25519 2022-10-26 [S] sub cv25519 2022-10-26 [E] > Is there additional info if you add "--list-options show-unusable-uids" > before the "-k"? No further information as far as I can tell: $ gpg --list-options show-unusable-uids -k 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 pub ed25519 2022-10-26 [CA] 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 uid [ unknown] Rens Rikkerink uid [ unknown] Rens Rikkerink sub ed25519 2022-10-26 [S] sub cv25519 2022-10-26 [E] Thank you for your time so far. Yours, Rens Rikkerink ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding new uid to causes bad signature
Hi, I have tried to replicate your issue using a Yubikey 5 NFC, doing what you did. > In general, I don't think my procedure for adding a new uid is abnormal: > $ gpg --edit-key 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 > gpg> adduid > gpg> save For my key and using gpg 2.4.5 on a standard Windows 10 system "check" didn't give an error and signing a document worked without any issues. I used a simple brainpool standard testkey with only one subkey, though. > General info: > OS: Windows 11 (AtlasOS) & MacOS 14.1.1 (tried on both) > GPG: GPG 2.4.4.-unknown (bundled with git-scm windows installer), GPG > 2.4.5 (homebrew) > > My public keys: > Before trying to add a new uid: > After trying to add a new uid: Importing your second pubkey did not change anything noticeable, gpg reported no changes on the key and there is no new UID to be seen. So it seems it was not exported. To avoid any confusion does gpg -k 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 show the new UID for you? Is there additional info if you add "--list-options show-unusable-uids" before the "-k"? Regards Eva -- g10 Code GmbH GnuPG.com AmtsGer. Wuppertal HRB 14459 Bergstr. 3a Geschäftsführung Werner Koch D-40699 Erkrath https://gnupg.com USt-Id DE215605608 ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Sirs.
Clearsign not working on new debian install. NisT-P21. encryption/ decryption works. Hej. Yours sincerely Richardh Bostrom___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using a GnuPG crypted RSA key for SSH
On Thu, 2 May 2024 15:31, Matthias Apitz said: > which locks the card again. Any ideas? If you really want to reset the card after an operation _and_ you are using pcscd you can use gpg-connect-agent 'scd disconnect' /bye But killing scdaemon is probably the easier and more reliable way: gpgconf -K scdaemon does this by sending the kill command gpg-connect-agent 'scd killscd' /bye Some card applications require a VERIFY command (i.e. asking for the PIN) for each operation. An OpenPGP card does this only for the signing key and only if that feature has been enabled (force command of --card-edit). Remember that there is no PIN cache[1] but the card application tales the descision when and how often a PIN is required after power up (of the card). If you only want to be asked whether the ssh-key shall be used, you can put a line Confirm: yes into the private-keys-v1.d/.key file of the AUTH (shadow-)key: *** Confirm If given and the value is "yes", a user will be asked confirmation by a dialog window when the key is about to be used for PKSIGN/PKAUTH/PKDECRYPT operation. If the value is "restricted", it is only asked for the access through extra/browser socket. Shalom-Salam, Werner [1] Actually there is a PIN cache to allow a Yubikey to switch between the OpenPGP and PIV appications back anf forth without requiring a PIN after each switch. A sample use-case is sending PGP signed mails and also using a browser or IMAP server with user certificate based authentication. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using a GnuPG crypted RSA key for SSH
On Thu, 2 May 2024 16:58, Matěj Cepl said: > rather dubious: systemd can certainly manage a dependence on > shared resource, and concurrent running of two processes at Right. However, systemd does not use the same locking scheme as gnupg uses to avoid duplicate daemon startup. The gnupg internal startup of required daemons has been there before systemd was invented and it needs to work on all platforms - not just on Linux. Having different schemes here is major problem but the former Debian maintainer (dkg) promised to take care of all problems due to his patches which added that systemd startup (--supervised) feature. Given that history I consider it unlikely that Debian will ever provide an enhanced ssh version which can be configured to start its ssh-agent on connection failure. Thus we need to keep on using the updatestartuptty thing when using a curses pinentry or a remote X session. The updatestartup thing does actually two things: Make sure that gpg-agent is launched (most other commands will do this also) and, more important, to tell gpg-agent something about the current environment (GPG_TTY, DISPLAY, etc). I have a patch somewhere to extend the ssh-agent-protocol to convey envvars but more or less forgot about it. it would be a useful things also for other ssh-agent's > I still haven’t investigated this piece of Werner’s advice: > >> Using no-autostart in the common.conf might be useful. We use it always >> when running a remote gpg. That is easy: On a remote box you don't want to run gpg-agent because this shall instead be handled by ssh socket forwarding. Without such an option running gpg might start gpg-agent on the remote box and thus take over the forwarded socket. Instead of adding "no-autostart" to all config files of gnupg, adding this to common.conf will be sufficient. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using a GnuPG crypted RSA key for SSH
On Thu May 2, 2024 at 3:55 PM CEST, Ming Kuang via Gnupg-users wrote: > https://lists.gnupg.org/pipermail/gnupg-users/2024-March/066957.html > https://lists.gnupg.org/pipermail/gnupg-users/2024-March/066960.html Just for the record, I find the explanation in the later email rather dubious: systemd can certainly manage a dependence on shared resource, and concurrent running of two processes at once. My deep suspicion is that we have here just a little case of the NIH syndrome (plus, a lack of understanding of containerized systems like my MicroOS). I still haven’t investigated this piece of Werner’s advice: > Using no-autostart in the common.conf might be useful. We use it always > when running a remote gpg. Best, Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 In political activity men sail a boundless and bottomless sea; there is neither harbor for shelter nor floor for anchorage, neither starting point nor appointed destination. -- Michael Oakeshott: Rationalism in Politics E09FEF25D96484AC.asc Description: application/pgp-keys signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using a GnuPG crypted RSA key for SSH
On Wed, 1 May 2024 11:50, Henning Follmann said: > Well, if you have a authentication subkey on your card you could use that > for ssh authentication directly. > Your gpg-agent would then act as ssh-agent. I would even claim that this is the best way to work with ssh - I do this now for nearly 20 years: Noteworthy changes in version 1.9.16 (2005-04-21) - * gpg-agent does now support the ssh-agent protocol and thus allows to use the pinentry as well as the OpenPGP smartcard with ssh. This even works on Windows as a preplcement of pageant and more recently ofbthe native OpenSSH Windows client. On Linux take care to add "enable-ssh-support" to gpg-agent.conf because on some distros the X config greps for this to decide whether to start the ssh-agent or leave this to gpg-agent. Technically the ssh support is always enabled and thus the option is not really required. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using a GnuPG crypted RSA key for SSH
Smart cards like yubikeys, and termux okcagent integrations? _ _ Med vennlig hilsen/Kind regards, Christian C. Phone/Tlf: +47 922 22 603 (Sent from my smartphone device) On Wed, 1 May 2024, 17:19 Matthias Apitz, wrote: > > Hello, > > I've on my Linux cellphone L5 my RSA key for SSH crypted with GnuPG (to > be exactly with an OpenPGP card in the phone). I can do fine: > > $ gpg -d id_rsa.asc > id_rsa # which asks for the PIN of the OpenPGP card > $ ssh www.unixarea.de > Enter passphrase for key '/home/guru/.ssh/id_rsa': > ... > $ rm id_rsa # so it can't get lost of teft of the L5 > > Is there some other solution for GnuPG+SSH without writing the private > key id_rsa to a file? Or even better as well without the need of > entering the passphrase for the RSA key? > > Thanks > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > > I am not at war with Russia. > Я не воюю с Россией. > Ich bin nicht im Krieg mit Russland. > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding new uid to causes bad signature
Hey Andrew, Yes, this happens consistently, I have not been able to add a uid at all, using both my main yubikey and backup yubikey (which have the same private key on them) Yours, Rens ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding new uid to causes bad signature
On 1 May 2024, at 10:08, Rens Rikkerink via Gnupg-users wrote: > > Lately I've been trying to add a new uid to my public key, I have > however so far been unsuccessful in doing so. Every time I try to do > so, I then immediately get "1 bad signature" which wasn't present > beforehand. It's probably worth noting that my private key is stored > on a Yubikey 5 NFC (smartcard). FYI it’s not just gnupg that complains about the bad signature, so does hockeypuck. So I’d assume that the card didn’t create the signature properly. Does this happen consistently? A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Adding new uid to causes bad signature
Greetings! Lately I've been trying to add a new uid to my public key, I have however so far been unsuccessful in doing so. Every time I try to do so, I then immediately get "1 bad signature" which wasn't present beforehand. It's probably worth noting that my private key is stored on a Yubikey 5 NFC (smartcard). In general, I don't think my procedure for adding a new uid is abnormal: $ gpg --edit-key 408FB2EBC3DF3DBBE0143D9A29AD46D6F58287A3 gpg> adduid gpg> save When then attempting to use this new uid, or even checking it, I get a bad signature error: gpg> check key 29AD46D6F58287A3: 1 bad signature Running this check before adding the new uid returns no results (assuming positive). I've been pretty stumped so far, not knowing how to debug this further. Your expert insights (or dare I say solutions) would be very much appreciated. If more information is required I would be more than happy to provide it. Yours sincerely, Rens Rikkerink General info: OS: Windows 11 (AtlasOS) & MacOS 14.1.1 (tried on both) GPG: GPG 2.4.4.-unknown (bundled with git-scm windows installer), GPG 2.4.5 (homebrew) My public keys: Before trying to add a new uid: -BEGIN PGP PUBLIC KEY BLOCK- mDMEY1l6bBYJKwYBBAHaRw8BAQdAMN32War5Dy1d7V41g7p0xc8ZHuGMcuN9CRxL 2HdH8be0JVJlbnMgUmlra2VyaW5rIDxjb250YWN0QGlra2VyZW5zLmNvbT6IlAQT FgoAPBYhBECPsuvD3z274BQ9mimtRtb1goejBQJjWXpsAhshBQsJCAcCAyICAQYV CgkICwIEFgIDAQIeBwIXgAAKCRAprUbW9YKHo/PPAQCurWgz0NRqxmUXwID3dJqy n+/yEADiLXzIPZj+5FbfYAD/ZsCO17JMr132BJbkuhQqiOxLDx2XbJtleykpSzZl VQW4MwRjWXqGFgkrBgEEAdpHDwEBB0A/USFFrzWgy6A74nb29Tz1I9tfhE2AI9OJ /xV9qWw244jvBBgWCgAgFiEEQI+y68PfPbvgFD2aKa1G1vWCh6MFAmNZeoYCGwIA gQkQKa1G1vWCh6N2IAQZFgoAHRYhBGqm/FWX6JvcGa3Wr88v7FA6ibz/BQJjWXqG AAoJEM8v7FA6ibz//7gA+wR1zLmvFLMbiGFopa6XeYk8oxYIUaJcncx9iv6SnYjv AQCN8VvgBy6nZpfSWtdVIjIC5qD1+4MUduNZuopACnJrBOdhAP9iNbSNUkgiG6qz skoonppyLNYKA7XXc8T+lyvt4JKlQAD/clQ6Afc3/XiOTqB/CoukgDLMbuT9mzEL jcrBA5ADDwq4OARjWXqdEgorBgEEAZdVAQUBAQdAQpvHc87RQKTYUZUWkh9UF10Q cI7JfXd7PBy5vl9lGS4DAQgHiHgEGBYKACAWIQRAj7Lrw989u+AUPZoprUbW9YKH owUCY1l6nQIbDAAKCRAprUbW9YKHo0dkAQDAlqB9zKRRDAmRbHT/lYiGiikzp5zm vZfxK32lqcge3gEAgw0Mqav2ZsmbXBsvzqrRVWDjSIE+X7EPZ7umkMSgMA4= =8Gph -END PGP PUBLIC KEY BLOCK- After trying to add a new uid: -BEGIN PGP PUBLIC KEY BLOCK- mDMEY1l6bBYJKwYBBAHaRw8BAQdAMN32War5Dy1d7V41g7p0xc8ZHuGMcuN9CRxL 2HdH8be0JVJlbnMgUmlra2VyaW5rIDxjb250YWN0QGlra2VyZW5zLmNvbT6IlAQT FgoAPBYhBECPsuvD3z274BQ9mimtRtb1goejBQJjWXpsAhshBQsJCAcCAyICAQYV CgkICwIEFgIDAQIeBwIXgAAKCRAprUbW9YKHo/PPAQCurWgz0NRqxmUXwID3dJqy n+/yEADiLXzIPZj+5FbfYAD/ZsCO17JMr132BJbkuhQqiOxLDx2XbJtleykpSzZl VQW0KlJlbnMgUmlra2VyaW5rIDxyZW5zLnJpa2tlcmlua0BsdW1pbmlzLmV1PoiT BBMWCgA7FiEEQI+y68PfPbvgFD2aKa1G1vWCh6MFAmYyBBsCGyEFCwkIBwICIgIG FQoJCAsCBBYCAwECHgcCF4AACgkQKa1G1vWCh6M3MQD/cMwMjCaM6z+2mjRbbOtn /37nwUEAeTY5ghZmmaOlBwEA/jM7DoadjZDLEw5E7utDeHUBvZt6CQFZVkM4hNUd OQYKuDMEY1l6hhYJKwYBBAHaRw8BAQdAP1EhRa81oMugO+J29vU89SPbX4RNgCPT if8VfalsNuOI7wQYFgoAIBYhBECPsuvD3z274BQ9mimtRtb1goejBQJjWXqGAhsC AIEJECmtRtb1goejdiAEGRYKAB0WIQRqpvxVl+ib3Bmt1q/PL+xQOom8/wUCY1l6 hgAKCRDPL+xQOom8//+4APsEdcy5rxSzG4hhaKWul3mJPKMWCFGiXJ3MfYr+kp2I 7wEAjfFb4Acup2aX0lrXVSIyAuag9fuDFHbjWbqKQApyawTnYQD/YjW0jVJIIhuq s7JKKJ6acizWCgO113PE/pcr7eCSpUAA/3JUOgH3N/14jk6gfwqLpIAyzG7k/Zsx C43KwQOQAw8KuDgEY1l6nRIKKwYBBAGXVQEFAQEHQEKbx3PO0UCk2FGVFpIfVBdd EHCOyX13ezwcub5fZRkuAwEIB4h4BBgWCgAgFiEEQI+y68PfPbvgFD2aKa1G1vWC h6MFAmNZep0CGwwACgkQKa1G1vWCh6NHZAEAwJagfcykUQwJkWx0/5WIhoopM6ec 5r2X8St9panIHt4BAIMNDKmr9mbJm1wbL86q0VVg40iBPl+xD2e7ppDEoDAO =YxeB -END PGP PUBLIC KEY BLOCK- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> Yes, this is a fundamental limitation of public-key cryptography: to decrypt a message or generate a signature, the private key must be available in cleartext. Some would say that that is the point. But NOT necessarily saved in clear text to a storage medium. Which is what > Some would say that that is the point. [And if not in clear text, then some mechanism such as 'gpg -d -passphrase...' must be employed ... and we're circular back to the point of this thread.] > If you are trying to have some semblance of security with an unattended application, have you considered using a smartcard or HSM to store the key? [Again, unattended has not been an element herein. (Which doesn't mean it is contraindicated.)] If trying to avoid cleartext storage, and the infrastructure overhead of key storage, inherently there is no tolerance for the overhead of a smartcard or usb stewardship. And there is certainly no tolerance, and probably no capacity, for the creation or maintenance of a customized PINENTRY_USER_DATA (to receive the parameter) as T4154 suggests. Elements such as 'gpg -c ...' exist, for reasonable reasons, or the effort to code and document things such as passphrases would not have been made in the first place. I can understand, coming from the premise of 'public-key cryptography', that the assumption and requirement of one's own public-key storage infrastructure be in place. But the presence of 'passphrase' and 'gpg -c' notes that 'gpg' doesn't exist -only- -within- a public-key storage infrastructure. And thank all for having so. [This all matters because of the well deserved trust attached to 'gpg', its coding, its auditing, and every other good thing making it the world's 'go to' for this stuff - including passphrase use. It's a well known and trusted hammer, and everything herein IS a nail. Inherently, one wants to stay within the facilities it provides (like passphrases), rather than customize surroundings to be maintained that break those predicates.] Within the subject of this thread: "Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?" I simply provided one solution for later readers and web searchers. [Avoiding everyone easily visible command line and scripted storage of passphrase, and minimal time of visibility to sensitive data within a processes superuser-only visible environment variable storage. tmpfs being a memdisk and duration so short as to be unlikely to be swapped to physical medium.] If it is not entirely satisfactory, most certainly alternative passphrase examples would be most appreciated. And noted that appending an alternative workaround to the given patch provided therein at https://dev.gnupg.org/T4154 would be useful to web searchers. On Mon, Apr 29, 2024 at 8:14 PM Jacob Bachmeyer wrote: > > Bee via Gnupg-users wrote: > >> Its is called "USER DATA" for a reason - you have to decide what to do > >> with it. > >> > > > > But a novel pinentry must be created to receive the data. Again, this > > is circular. > > > > > >> If your really really want a passphrase, what about passing > >> the filename of a file holding the passphrase. > >> > > > > AGAIN, this requires clear text storage trying to be avoided in the > > first place, or ... decrypting the encrypted file on the fly ... which > > requires a passphrase to be passed ... and we're circular again. > > > > Yes, this is a fundamental limitation of public-key cryptography: to > decrypt a message or generate a signature, the private key must be > available in cleartext. Some would say that that is the point. > > If you are trying to have some semblance of security with an unattended > application, have you considered using a smartcard or HSM to store the key? > > > -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
Bee via Gnupg-users wrote: Its is called "USER DATA" for a reason - you have to decide what to do with it. But a novel pinentry must be created to receive the data. Again, this is circular. If your really really want a passphrase, what about passing the filename of a file holding the passphrase. AGAIN, this requires clear text storage trying to be avoided in the first place, or ... decrypting the encrypted file on the fly ... which requires a passphrase to be passed ... and we're circular again. Yes, this is a fundamental limitation of public-key cryptography: to decrypt a message or generate a signature, the private key must be available in cleartext. Some would say that that is the point. If you are trying to have some semblance of security with an unattended application, have you considered using a smartcard or HSM to store the key? -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> Its is called "USER DATA" for a reason - you have to decide what to do > with it. But a novel pinentry must be created to receive the data. Again, this is circular. > If your really really want a passphrase, what about passing > the filename of a file holding the passphrase. AGAIN, this requires clear text storage trying to be avoided in the first place, or ... decrypting the encrypted file on the fly ... which requires a passphrase to be passed ... and we're circular again. > Or a socket or some > another secure IPC mechanism locator. Or ... 3 lines of script in the example you seem to be ignoring? mkfifo myfifo secret="passphrase" echo $secret > myfifo & unset secret echo "secret stuff" | gpg -c ... -fd 3 3< myfifo > For unattended use Unattended has not been mentioned. > For unattended use the only reason for a passphrase - which protects the > private key There is no private key in any scenario listed here. The point has been to avoid key infrastructure overhead entirely. [Yes, the passphrase is the key, but that is irrelevant semantics for purposes here.] Again ... 'echo "secret stuff" | gpg -c ...' Again, posting an actual workaround to the bottom of https://dev.gnupg.org/T4154 would be very welcome, and websearch visible to those so looking. - and the providing of such an example was the only purpose in writing the message you responded to, first, today. Saying the expressly desired use (e.g. dev.gnupg) is inappropriate is specious and counter-productive. Clearly the use is intended, given the presence of the word 'passphrase', even within 'man gpg'. On Mon, Apr 29, 2024 at 7:44 AM Werner Koch wrote: > > On Mon, 29 Apr 2024 07:03, Bee said: > > > But that environment is not passed and used by pinentry - it has no > > knowledge of them. PINENTRY_USER_DATA may exist, but it has no > > knowledge as to how to interpret it. Ergo, some other mechanism must > > Its is called "USER DATA" for a reason - you have to decide what to do > with it. If your really really want a passphrase, what about passing > the filename of a file holding the passphrase. Or a socket or some > another secure IPC mechanism locator. > > For unattended use the only reason for a passphrase - which protects the > private key against local users - are stupid policy requirements you > have to follow. In all other cases, first come up with an attack tree > to show that a passphrase is of any use for your application. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
On Mon, 29 Apr 2024 07:03, Bee said: > But that environment is not passed and used by pinentry - it has no > knowledge of them. PINENTRY_USER_DATA may exist, but it has no > knowledge as to how to interpret it. Ergo, some other mechanism must Its is called "USER DATA" for a reason - you have to decide what to do with it. If your really really want a passphrase, what about passing the filename of a file holding the passphrase. Or a socket or some another secure IPC mechanism locator. For unattended use the only reason for a passphrase - which protects the private key against local users - are stupid policy requirements you have to follow. In all other cases, first come up with an attack tree to show that a passphrase is of any use for your application. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
Again, specious.
> Simply don't use a passphrase if you need to resort to such a thing. On
> many systems you - and other users - can easily look at the
> environment.
But that environment is not passed and used by pinentry - it has no
knowledge of them. PINENTRY_USER_DATA may exist, but it has no
knowledge as to how to interpret it. Ergo, some other mechanism must
be used. Such as an environment variable. So that the passphrase is
not visible within the script or a command line listing of the process
table. And preferably not even stored anywhere, in plain text.
A script (containing a hardwired passphrase) may well remain in
existence for some time, even, as a service, forever. The passphrase
remaining visible - both script, and/or command line, for the
duration. The solution given, for example, leaves no passphrase
visible in script or command line - in plain text only for the minimal
number of script lines - assuming a nefarious user is even present for
those microseconds,
never mind a casual one, -AND- that they have superuser privileges to
even be able to examine foreign (to the userid) process variables.
While even casual users can view scripts and process tables [but not
foreign process' environment variables].
It is quite evident that passphrase use is intended by gpg design.
Search 'passphrase' within 'man gpg' and one cannot escape such a
conclusion. Particularly '-c'.
e.g. echo "Secret data to be encrypted" | gpg -c ...
Examples of on the fly script use without key overhead have been
requested [here (thread(s) earlier) and elsewhere], that do not involve keys or
hardwiring a passphrase - without answer. If you have such, please
post. If I missed it, apologies, please advise of links.
If passphrase use was not to be used, then all code and documentation
containing the word 'passphrase' would have been stripped from the
content long ago. That it hasn't been can only be taken to mean that
it is intended and desired functionality.
A working alternative algorithm posted to the end of
https://dev.gnupg.org/T4154 would be welcome, and websearch visible to
those so looking. As it stands, things are circular - the suggested
solution is a custom PINENTRY_USER_DATA, and ergo a customized gpg
environment crafted to receive it, but if that were in place or desired, the
requested and delivered enhancement wouldn't be needed. This is
circular.
A working alternative (key-free and clear text free) algorithm posted
to the end of
https://dev.gnupg.org/T4154 would be welcome, and websearch visible to
those so looking.
On Sun, Apr 28, 2024 at 12:53 PM B.S. wrote:
>
>
> > At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
> environment variable', there is a comment of "I don't see why we
> should add yet more clumsy passphrase workarounds to gpg. We already
> have PINENTRY_USER_DATA which can fulfill the same task."
>
> Of course, the reference here to PINENTRY_USER_DATA is specious. To
> incorporate the processing of such a customized PINENTRY_USER_DATA requires
> the coding of a corresponding pinentry executable to receive it.
>
> And if one has the capacity to code one's own unique pinentry executable ...
> they could code around the stated problem outside of using PINENTRY_USER_DATA
> in the first place.
>
> And the T4154 request would never have been made, in the first place.
>
>
> So, given the above, a solution towards:
>
> >+ (https://dev.gnupg.org/T4154)
> >+
> >+ So this patch adds a new form of passphrase-passing, using an environment
> >+ variable. In POSIX shell, this looks like (for example):
> >+
> >+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \
> >+ --passphrase-env=mypass --decrypt < message.txt
> >+
>
> can be effected without resorting to PINENTRY_USER_DATA - so no need to code,
> customize, maintain, update per gpg upgrades, or apply patches to in-house
> self-solutions.
>
>
> > Can anyone give an example of doing so?
>
> > I am looking to effect the equivalent of ...
>
> > Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA
> > which can fulfill the same task' of gpg picking up its passphrase from an
> > environment variable?
>
>
> Examine https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067030.html
> ('How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?') for a
> more detailed example script solution, but in brief for this thread:
>
>
> gs_myfifo="$(mktemp -ut fifo.XXX)"
> mkfifo -m 0600 "${gs_myfifo}"
>
> gs_mysecretpassphrase="KXhtctw4_zFfhRop"
>
> echo -e "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
> unset gs_mysecretpassphrase
>
> echo -e "Stuff to be encrypted."
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
On Sun, 28 Apr 2024 13:02, Bee said: >>+ (https://dev.gnupg.org/T4154) [...] >>+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \ >>+ --passphrase-env=mypass --decrypt < message.txt >>+ > > can be effected without resorting to PINENTRY_USER_DATA - so no need to > code, customize, maintain, update per gpg upgrades, or apply patches to > in-house self-solutions. Simply don't use a passphrase if you need to resort to such a thing. On many systems you - and other users - can easily look at the environment. It is also part of all kind of bug reports. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
environment variable', there is a comment of "I don't see why we
should add yet more clumsy passphrase workarounds to gpg. We already
have PINENTRY_USER_DATA which can fulfill the same task."
Of course, the reference here to PINENTRY_USER_DATA is specious. To
incorporate the processing of such a customized PINENTRY_USER_DATA requires
the coding of a corresponding pinentry executable to receive it.
And if one has the capacity to code one's own unique pinentry executable
... they could code around the stated problem outside of using
PINENTRY_USER_DATA in the first place.
And the T4154 request would never have been made, in the first place.
So, given the above, a solution towards:
>+ (https://dev.gnupg.org/T4154)
>+
>+ So this patch adds a new form of passphrase-passing, using an environment
>+ variable. In POSIX shell, this looks like (for example):
>+
>+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \
>+ --passphrase-env=mypass --decrypt < message.txt
>+
can be effected without resorting to PINENTRY_USER_DATA - so no need to
code, customize, maintain, update per gpg upgrades, or apply patches to
in-house self-solutions.
> Can anyone give an example of doing so?
> I am looking to effect the equivalent of ...
> Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA
which can fulfill the same task' of gpg picking up its passphrase from an
environment variable?
Examine https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067030.html
('How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?') for
a more detailed example script solution, but in brief for this thread:
gs_myfifo="$(mktemp -ut fifo.XXX)"
mkfifo -m 0600 "${gs_myfifo}"
gs_mysecretpassphrase="KXhtctw4_zFfhRop"
echo -e "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
unset gs_mysecretpassphrase
echo -e "Stuff to be encrypted." \
| gpg --pinentry-mode loopback --passphrase-fd 3 -c 3< "${gs_myfifo}"
rm "${gs_myfifo}"
Of course, 'gs_mysecretpassphrase="KXhtctw4_zFfhRop"' would be replaced
with some other mechanism of acquiring the passphrase. Perhaps via
something such as:
export GPG_TERM="${TERM}"
echo -e "GETPIN\nBYE\n" \
| pinentry --ttyname "${GPG_TTY}" \
| sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //"
On Thu, Mar 21, 2024 at 7:45 PM B.S. wrote:
> At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
> environment variable', there is a comment of "I don't see why we
> should add yet more clumsy passphrase workarounds to gpg. We already
> have PINENTRY_USER_DATA which can fulfill the same task."
>
> Can anyone give an example of doing so?
>
> I am looking to effect the equivalent of:
> '@rem Get passhrase into (env.) var. programmatically (in your
> favourite manner)'
> 'set /p myenvpassphrase="Enter symmetric keyphrase to use:"
> 'echo "Secret data" | gpg.exe -c --envpassphrase myenvpassphrase >
> secretdata.gpg'
> - thereby avoiding storing any passphrase (even temporarily) on a
> storage medium, nor have it visible as the command line (via tasklist
> or ps).
> - in this case, the 'secret data' is actually confidential
> information, piped from elsewhere, on the fly.
>
> Of course, the '-envpassphrase' option doesn't exist in gpg currently,
> but the comment at the above link indicates that there is another way
> to effect the same intent.
>
> Can anyone give an example of so doing?
>
> A current means of effecting the same is, of course, '--passphase-fd
> 3", for something like:
> 'echo "Secret data" | gpg.exe -c --passphrase-fd 3 3< echo %PASSWORD%
> > secretdata.gpg'
> - except I have no idea [in (Win 10) DOS, not powershell, cmd] how to
> get anything into file descriptor 3.
> = let alone get an echo into fd 3 (without actually landing on a
> filesystem, even temporarily).
>
> Of course:
> 'echo "Secret data" | gpg.exe -c --passphrase > secretdata.gpg'
> - doesn't work, as stdin can't be 'in two places at once', both
> passphrase input, and data input.
> = Remember, "Secret data" isn't on disk, either - it's being piped in, too.
>
> Has anyone got a link to a working example of '3<' or
> 'PINENTRY_USER_DATA which can fulfill the same task' of gpg picking up
> its passphrase from an environment variable?
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Lost GPG private key passphrase
On Sun, Apr 14, 2024 at 4:55 PM Daniele Nicolodi via Gnupg-users < gnupg-users@gnupg.org> wrote: > I have an oldish GPG key for which I have lost the passphrase. I have a > very good idea of what the passphrase is constructed but there are some > characters substitution that I must have used back then really escape my > memory now. I think that a tool like John the Ripper could make easy > work in retrieving it. > Does anyone know how to run john on a private key stored in the format > used by the new keystore used by gpg2? > dunno much about new format or so? can this still work in this old blog post? maybe use an older gpg release on the private key file to export? > < https://blog.atucom.net/2015/08/cracking-gpg-key-passwords-using-john.html> ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is there built-in a way validate a signature against a specific key?
On Wed, Apr 24, 2024 at 11:14:06AM +0200, Werner Koch via Gnupg-users wrote: > On Tue, 23 Apr 2024 21:39, Eric Pruitt said: > > I have multiple public keys in my GPG keyring. When validating > > signatures, I sometimes want to validate them against a specific key so > > The classcc tool for this is gpgv with its --keyring option. This is > what for example Debian uses to validate signatures. I think this is what I'm already doing and what I meant when I wrote "I do this by creating a keyring that consists of only one key and using that [...]" or have I misunderstood what you suggested? > A newer way is the --assert-signer option we introduced with version > 2.4.1: Thanks, this does what I want. Eric ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is there built-in a way validate a signature against a specific key?
On Tue, 23 Apr 2024 21:39, Eric Pruitt said: > I have multiple public keys in my GPG keyring. When validating > signatures, I sometimes want to validate them against a specific key so The classcc tool for this is gpgv with its --keyring option. This is what for example Debian uses to validate signatures. A newer way is the --assert-signer option we introduced with version 2.4.1: --assert-signer fpr_or_file This option checks whether at least one valid signature on a file has been made with the specified key. The key is either specified as a fingerprint or a file listing fingerprints. The fingerprint must be given or listed in compact format (no colons or spaces in between). This option can be given multiple times and each fingerprint is checked against the signing key as well as the corresponding primary key. If fpr_or_file specifies a file, empty lines are ignored as well as all lines starting with a hash sign. With this option gpg is guaranteed to return with an exit code of 0 if and only if a signature has been encountered, is valid, and the key matches one of the fingerprints given by this option. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Is there built-in a way validate a signature against a specific key?
I have multiple public keys in my GPG keyring. When validating signatures, I sometimes want to validate them against a specific key so if the file is signed by someone other than the individual or organization I expect, it will fail. Currently, I do this by creating a keyring that consists of only one key and using that, and some cursory searching didn't uncover any alternatives. If there still isn't a GPG option for validating a signature against a specific key, is there a particular reason it doesn't exist? Eric ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Thu, 18 Apr 2024 10:26, Bruce Walzer said: > Perhaps things that accept key fingerprints should ignore anything > other than hex digits? Double clicking a word makes things really easy. I also doubt that anyone will compare a 64 hex digit fingerprint visually. Thus better paste it and let some software do the comare. Which reminds me that the gpg --edit-key -> sign dialog should also accept a fingerprint on the "Really sign? (y/N)" prompt. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Wed, 17 Apr 2024 16:43, Christian Sommer said: > I indeed choose to preset the "with-fingerprint" option in my > gpg.conf. By removing it, listing my keys give back the full 64 > character long fingerprint of my X448 key. We once agreed that it is better to show a shortened fingerprint for human consumption. However, the mahine interface (--woth-colons) always provides the full fingerprint. Further it seems that most users appreciate the non-formatted fingerprint because that makes it easier to copy+paste. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 17 Apr 2024, at 15:43, Christian Sommer wrote: > > You are right Andrew! > > I indeed choose to preset the "with-fingerprint" option in my > gpg.conf. By removing it, listing my keys give back the full 64 > character long fingerprint of my X448 key. Good to hear! I think the best solution is for gnupg to ignore the `with-fingerprint` configuration option. Modern versions display primary key fingerprints by default anyway, so the alternative display format is both redundant and potentially confusing. I would be particularly concerned that people with different settings in their gpg.conf would see a mismatch between the 50-character fingerprint on one machine and the 64-character fingerprint on another, and incorrectly infer that something shady was going on. Differences in whitespace formatting are broadly expected (ref: credit card numbers) but truncation is not. And to pick up on an earlier point, short key IDs should never be displayed or processed under any circumstances. Evil32 was a whole decade ago. A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
You are right Andrew! I indeed choose to preset the "with-fingerprint" option in my gpg.conf. By removing it, listing my keys give back the full 64 character long fingerprint of my X448 key. Very nice to come back on this, thx. Kris. On Wed, Apr 17, 2024 at 1:00 PM Andrew Gallagher wrote: > > On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users > wrote: > > > when explicitly telling GnuPG to display x448 fingerprints (gpg > --fingerprint) it just spits out the "abbreviated hex format" by takes > the first 50 bytes and sweeping the rest under the rug! Not very nice. > > > Hi, Christian. > > This seems to depend on whether you have “with-fingerprint” enabled in your > gpg.conf file. I commented out this line from my own gpg.conf, and I was able > to reproduce Werner’s full 64-character v5 fingerprint output. With this > configuration line enabled I could only see your 50-character fingerprint > output. > > Hope this helps, > Andrew. > ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users wrote: > > when explicitly telling GnuPG to display x448 fingerprints (gpg > --fingerprint) it just spits out the "abbreviated hex format" by takes > the first 50 bytes and sweeping the rest under the rug! Not very nice. Hi, Christian. This seems to depend on whether you have “with-fingerprint” enabled in your gpg.conf file. I commented out this line from my own gpg.conf, and I was able to reproduce Werner’s full 64-character v5 fingerprint output. With this configuration line enabled I could only see your 50-character fingerprint output. Hope this helps, Andrew. signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Lost GPG private key passphrase
Hello, I have an oldish GPG key for which I have lost the passphrase. I have a very good idea of what the passphrase is constructed but there are some characters substitution that I must have used back then really escape my memory now. I think that a tool like John the Ripper could make easy work in retrieving it. Does anyone know how to run john on a private key stored in the format used by the new keystore used by gpg2? Thank you. Cheers, Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
On Thu, 11 Apr 2024 12:24, Moses said: > tried to import again, and the same error still occurred. The same > error happened when I tried to directly execute the > D:\software\GNU\GnuPG\bin\gpg --import command. Well, I have no more idea on how to debug this by mail :-(. On Linux you would now use strace and on Windows we have the sysinternals tools to trace the system calls. And there is printf debugging - I would here start with libassuan (src/assuan-socket.c). Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I checked my D:\software\GNU\GnuWin32\bin. There is no gpg.exe in it, only gpg-error.exe and gpg-error-config. But there is gpg.exe in my git folder. I adjusted the PATH and temporarily removed it. Then I tried to import again, and the same error still occurred. The same error happened when I tried to directly execute the D:\software\GNU\GnuPG\bin\gpg --import command. - -- M. On Wed, Apr 10, 2024 at 3:35 PM Werner Koch wrote: > > Hi, > > I see in your PATH > > D:\software\GNU\GnuWin32\bin > > prior to > > D:\software\GNU\Gpg4win\..\GnuPG\bin > > May it be that you use a gpg version picked up from the GnuWin32? Check > also whether there is a gpg binary in the Git program directory. > > My educated guess is that Gnuwin32 is a Cygwin based collection of > utilities which might also include gpg. Cygwin uses a slightly > different and incompatiple socket emulation which would explain the > error your get. As a workaround you may try to run > > D:\software\GNU\GnuPG\bin\gpg --import foo > > to use the correct gpg. > > > Shalom-Salam, > >Werner > > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEtS81xZ6ggCm51urXjBWeIrrYv8gFAmYX1lQACgkQjBWeIrrY v8hC/xAAkRIsAYlONRBS2Rg30AMB4ghMbU3SKlJ6mNpOcXmdv4U547Ie9iV0F6vl UkPIn1CTThzffMuRvkWkbB+hccZTWC/lzjEUnpub4cQXG/MWZqX/KZY2ujqHwqSz RTwv9Nirxw01bP+t6R/BIct4ReIePoI7nyD06JhAOMR3iuE7FCFOg8vaYC7ooZHG 4CUbAptK7l04hPxpfJ5drfqNCeTy2Bh/mHmVADFu43lq9AW9vhcpOabo+8jcNtQn 4FYITjq/P16c1cnNL5CZdWHqGK/+7T4VyIFowGL6/HYRiQR+Nokr1XRLI6+aJ2HU soRaHc0r2UFVie71jgvPfc+R0dekffW/OCir4Eye3o1KmLrCpHjFKKknYca0pOeA R4IO1U8tSHzRru3w7GTX9A2V4ziAcrdzmFjBrCWjLSaJJc9FLZbKyXLG9F9nAvIQ 6s+mf3/RaR8AURaO9WLE32Cvi3K2i1vhnPkJgMcgWpvH3MZA8rcrEX0+tSSUuMes 3owKpgKVNmpMsKdtgJEd0HV1VRKk2UV5mUf+b1MAv7jxrH5nApBAJdxrrqrK1hXP X7v5S/GSgK0gv1zl0MAeyJfgeqJKgDP4VZMl2O3z98Z8DW3stzWMqZv/PR+vZYPY EExISfJxQxLQtMNVIXm8tkGVEg0kmtCQIkNEnMQJLce+nbnw6mQ= =VoTO -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
On Wed, 10 Apr 2024 12:15, Todd Zullinger said: > This caused me to re-read the document and I'll likely add > an additional Token: line to note the two cards which hold a > new key (which I have yet to start using). That should make That is actually there (TOKEN, see the example) and gpg-agent updates the file if it find another card with the same key. See for example https://dev.gnupg.org/T6135 . However, you are free to edit/add such entries. Talking about keyformat.txt: I think it is time to move that over to doc/ where people would expect it. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
Hi, Werner Koch via Gnupg-users wrote: > On Fri, 5 Apr 2024 13:03, Todd Zullinger said: > >> In such a case, it sounds like it may be reasonable to use >> the normal socket? Until the remote side is updated to > > In fact, I also did this for some time but later came up with > > CommitDate: Wed Oct 12 11:30:35 2022 +0200 > > agent: Introduce attribute "Remote-list" to KEYINFO. > > * agent/command.c (do_one_keyinfo): Add arg list_mode. Check > attribute Remote-list. > (cmd_keyinfo): Change semantics to return nothing in restricted list > mode. > > which is > > *** Remote-list > Allow to list the key with the KEYINFO command from a remote machine > via the extra socket. A boolean value is expected; the default is > "no". Note that KEYINFO will anyway provide information if the > keygrip is specified. > > Not exactly your problem but somehow related. Neat. I have probably read agent/keyformat.txt before, but not in a long time and I never had any reason to consider editing the .key files. This caused me to re-read the document and I'll likely add an additional Token: line to note the two cards which hold a new key (which I have yet to start using). That should make it easier to move between the cards, it sounds like. In the process, I spotted a few minor typos and sent a patch to gnupg-devel. Thanks again, Werner! -- Todd signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
Hi, I see in your PATH D:\software\GNU\GnuWin32\bin prior to D:\software\GNU\Gpg4win\..\GnuPG\bin May it be that you use a gpg version picked up from the GnuWin32? Check also whether there is a gpg binary in the Git program directory. My educated guess is that Gnuwin32 is a Cygwin based collection of utilities which might also include gpg. Cygwin uses a slightly different and incompatiple socket emulation which would explain the error your get. As a workaround you may try to run D:\software\GNU\GnuPG\bin\gpg --import foo to use the correct gpg. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Thank you for your continued follow-up. I executed commands. Here are the results: C:\>gpgconf -V * GnuPG 2.4.5 (cbff323b3) MingW32 Windows 10.0 build 19045 * Libgcrypt 1.10.3 (aa161086) version:1.10.3:10a03:1.48:13000: cc:10:gcc:10-win32 20210110: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3: rnd-mod:w32: cpu-arch:x86: mpi-asm:i386/mpih-add1.S:i386/mpih-sub1.S:i386/mpih-mul1.S:i386/mpih-mul2.S:i386/mpih-mul3.S:i386/mpih-lshift.S:i386/mpih-rshift.S: hwflist:intel-cpu:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc: fips-mode:n::: rng-type:standard:1:303:1: compliance::: * GpgRT 1.48 (77b7c5f) * Libassuan 2.5.7 (cc2f776) * KSBA 1.6.6 (3a43822) * NTBTLS 0.3.2 (2c38007) C:\>gpgconf -X ### Dump of all standard config files ### GnuPG 2.4.5 (cbff323b3) ### MingW32 ### [VERSION file not found] ### Windows 10.0 build 19045 ### Libgcrypt 1.10.3 ### GpgRT 1.48 ### Codepages: 65001 936 936 ### sysconfdir:C%3a\ProgramData\GNU\etc\gnupg bindir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin libexecdir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin libdir:D%3a\software\GNU\Gpg4win\..\GnuPG\lib\gnupg datadir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\gnupg localedir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\locale socketdir:C%3a\Users\███\AppData\Local\gnupg dirmngr-socket:C%3a\Users\███\AppData\Local\gnupg\S.dirmngr keyboxd-socket:C%3a\Users\███\AppData\Local\gnupg\S.keyboxd agent-ssh-socket:C%3a\Users\███\AppData\Local\gnupg\S.gpg-agent.ssh agent-extra-socket:C%3a\Users\███\AppData\Local\gnupg\S.gpg-agent.extra agent-browser-socket:C%3a\Users\███\AppData\Local\gnupg\S.gpg-agent.browser agent-socket:C%3a\Users\███\AppData\Local\gnupg\S.gpg-agent homedir:C%3a\Users\███\AppData\Roaming\gnupg PATH=D:\software\VMware\bin\;C:\Program Files\Common Files\Oracle\Java\javapath;C:\Program Files\Microsoft\jdk-11.0.12.7-hotspot\bin;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;D:\software\GNU\GnuWin32\bin;D:\software\Git\cmd;D:\software\Python\Python39\Scripts;D:\software\Python\Python39\;D:\software\emacs\bin;C:\Program Files\Azure Data Studio\bin;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Users\███\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\███\App;D:\software\Calibre\;C:\Program Files (x86)\Microsoft SQL Server\160\DTS\Binn\;C:\Program Files (x86)\cloudflared\.;D:\software\GNU\Gpg4win\..\GnuPG\bin;C:\Program Files\WireGuard\;C:\Users\███\AppData\Local\Programs\Python\Python310\;C:\Users\███\AppData\Local\Microsoft\WindowsApps;C:\Users\███\.dotnet\tools;C:\Program Files\Azure Data Studio\bin;D:\software\Google\CloudSDK\google-cloud-sdk\bin ### ### global config "C:\ProgramData\GNU\etc\gnupg\common.conf": not installed ### ### ### local config "C:\Users\███\AppData\Roaming\gnupg\common.conf": not installed ### ### ### global config "C:\ProgramData\GNU\etc\gnupg\gpg-agent.conf": not installed ### ### ### local config "C:\Users\███\AppData\Roaming\gnupg\gpg-agent.conf" ### - --8<---cut here---start->8--- ###+++--- GPGConf ---+++### verbose verbose debug-level guru ###log-file C:\Users\███\AppData\Roaming\gnupg\gpg-agent.log ###+++--- GPGConf ---+++### 03/08/24 12:14:59 Coordinated Universal Time # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. - --8<---cut here---end--->8--- ### ### global config "C:\ProgramData\GNU\etc\gnupg\scdaemon.conf": not installed ### ### ### local config "C:\Users\███\AppData\Roaming\gnupg\scdaemon.conf" ### - --8<---cut here---start->8--- ###+++--- GPGConf ---+++### verbose verbose verbose verbose verbose ###+++--- GPGConf ---+++### 03/08/24 10:46:59 Coordinated Universal Time # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. - --8<---cut here---end--->8--- ### ### global config "C:\ProgramData\GNU\etc\gnupg\dirmngr.conf": not installed ### ### ### local config "C:\Users\███\AppData\Roaming\gnupg\dirmngr.conf" ### - --8<---cut here---start->8--- ###
Re: Can not import private key (Not enough space)
Hi! On Tue, 9 Apr 2024 12:21, Moses said: > C:\>gpgconf -L which merely shows that you installed the software on d:\software and kep the user data at the usual C: directories. I see nothing strange. To recap your problem was: c:\> gpg --import private-keys.asc gpg: enabled compatibility flags: [snipped] gpg: key xxx: error sending to agent: Not enough space I don't known why you get that error which might hint at a out of memory (not out of disk space) problem.We could look at the output of gpgconf -V and gpgconf -X but I doubt that this will show anything useful for your case. Can you start kleopatra? If so, what does its selftest tell? What you can do is: gpgconf -K all to stop all background processes (or use the taskmgr or logout and in again). cd %APPDATA% ren gnupg gnupg.save cd %LOCALAPPDATA% ren gnupg gnupg.save and then try agin. If this does work you might have insufficent permissions somewhere below %APPDATA%\gnupg . If kleopatra starts you can also teh DbgViewer tool from Sysinternals to see the diagnostics from Kleopatra. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Returns as follows: (just blacked out the username...) C:\>gpgconf -L sysconfdir:C%3a\ProgramData\GNU\etc\gnupg bindir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin libexecdir:D%3a\software\GNU\Gpg4win\..\GnuPG\bin libdir:D%3a\software\GNU\Gpg4win\..\GnuPG\lib\gnupg datadir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\gnupg localedir:D%3a\software\GNU\Gpg4win\..\GnuPG\share\locale socketdir:C%3a\Users\■\AppData\Local\gnupg dirmngr-socket:C%3a\Users\■\AppData\Local\gnupg\S.dirmngr keyboxd-socket:C%3a\Users\■\AppData\Local\gnupg\S.keyboxd agent-ssh-socket:C%3a\Users\■\AppData\Local\gnupg\S.gpg-agent.ssh agent-extra-socket:C%3a\Users\■\AppData\Local\gnupg\S.gpg-agent.extra agent-browser-socket:C%3a\Users\■\AppData\Local\gnupg\S.gpg-agent.browser agent-socket:C%3a\Users\■\AppData\Local\gnupg\S.gpg-agent homedir:C%3a\Users\■\AppData\Roaming\gnupg On Tue, Apr 9, 2024 at 10:05 AM Werner Koch wrote: > > On Mon, 8 Apr 2024 11:42, Moses said: > > > C:\> gpg-connect-agent -v > >> getinfo version > > D 2.4.5 > > Okay, that works. > > >> gpgconf -L > > ERR 67109139 Unknown IPC command > > Please enter this on the command line not at the gpg-connect-agent > prompt. > > > Salam-Shalom, > >Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEtS81xZ6ggCm51urXjBWeIrrYv8gFAmYVMnsACgkQjBWeIrrY v8hGFRAAq2Y7Rzahrz3nBKoLkO29rzKMpurp0XXhOk0ONPXcJGKCLDq6UvDa1VmH yowbbY87lOSucAKjyekrr1qr0as7p76/rRQPQeorXjQF/GeEFTUEzolRWJk70M3C +Wcxi9WbNV/VmZsnJUjpsG4FKyqgBqhKdildPm1CvTF4mmF+X5cOK1swi3GoWf3I LGF9zJ+Gbm5Shs65htJ9xCSryCYEHciZHev5zMt6yQM1ZBBjKbkOC2OLRoFSBCej CDHcmY4tA6a//De4jUyv3ypoxBv4bPOLOgvDzRVne62hhOwAQqtFF8ZgX+McS4cs Zw+xJycPZVDegFvlQW2qwhtJWYfUXCGpxlrsi/1zoOgHp1uaR8O/8x8gszBuiXKj kuLIojRZWRnt1lYItO3oUO6t/z95HfNUE1aT4hKcGuDx/yK4/1h4i9VFb48W0qAu WoWuiON8Q36SsLA2C6cuPfpjx5gusX31iiuMoNH5IoujN6Ip4al9v0Goo76CSe7l Sqy4iLmAh3DhTt2prw70k93GAMD3oORT/AGk1SyxDoRzRmV99BELdr4ZGFyJnhqW wvBjxtl0ynRg7UOKilug+tZbTRSlAqNMeBAKLn90aSsmy8f/MZuPvyDnhowpoL/a 7jpZaLlTvKvzi++Yd5MHvyX97rOrzIndsVyC1Qr1yN+EuQa1ubI= =3+BK -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP card not available
On Mon, 8 Apr 2024 21:50, Dan Fandrich said: > Running "echo SERIALNO | scd/scdaemon --server" is enough. I've tried both > pcsc-lite 1.9.9 and 2.0.3 without a difference. I'm not sure how to drill By default we are not using PC/SC on Linux but direct access to the reader via USB. Now if pcscd is already running and has access to the reader scdaemon won't be able to access the reader via USB. 2.2 falls back to PC/SC if it can't use the reader via USB. Either shutdown pcscd or add disable-ccid-driver to ~/.gnupg/scdaemon.conf More debug output can be logged by adding debug cardio debug-ccid-reader Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
On Mon, 8 Apr 2024 11:42, Moses said: > C:\> gpg-connect-agent -v >> getinfo version > D 2.4.5 Okay, that works. >> gpgconf -L > ERR 67109139 Unknown IPC command Please enter this on the command line not at the gpg-connect-agent prompt. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I tried the command you gave and the results are as follows: C:\> gpg-connect-agent -v > getinfo version D 2.4.5 OK > gpgconf -L ERR 67109139 Unknown IPC command I downloaded and installed gpg4win from the official website, and the signature/sha-256 of the installer matches. Thanks - -- M. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEtS81xZ6ggCm51urXjBWeIrrYv8gFAmYT14wACgkQjBWeIrrY v8g/DRAAlgbnQ8wLj9vnJXfEpf9yh+uXRs0A6r6DV0/44ni/AzyqcRzCDKhbHXOO dSdsA2RKmv+7QB9p3X1c/d09YmAF1qzgiA7zT2EQXKmPoMCJRLWTfeY3wlCqeldd OCsXIZzE9rQifMn8YjvPe8A//Fc6Y+EomQpYP8qVBWISwpQ7eOdq6uLyLT/nid0O 66CjTdGyRwyni+PKKHNjDjvkJAKm+m5AGK3OEvxSnYWq0qgLNW6xizhZmzShU5lR Jvbsz66H6VZM+I0kLLB63bdqwDJPy6KcfpOeT62K1U+pQ++mcLI3GpYw76mrnHL2 odTrZ5/yADX+zcKyqEiXLVGjZQMm/PrmNvKoZ0hC6svA3lfryOhgqdVmh6TME5x9 mLnDwawqacxy6Y2YJxUHnMbIPyAI+0L2Kd7GGoGHvjjWBqYsU//5DN3dmPw5W9+C OfSyzYWgV3fBW29+rcW/mSZS4uZZuArFsYqbqU/mpTiG9rSeeVkEymcSjSH6PEdy AUQQN4xQDhqQNY7IXLKzD6fh6/felEl5qU2PehKMMIjX5z6AQCldAwhbxVLbGOXj DGnsXIqvoXMLt3LhJIers1aDnaWhs6ebC4dWcx3N+Pfsbo6rQEkTcgHDKHCo4dxd fkBQs3xEahy2JMWNtxi34gcPcdVC2AbUnzO6erpM7hN8f5udSQM= =soqR -END PGP SIGNATURE- _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can not import private key (Not enough space)
Hi!
On Mon, 8 Apr 2024 02:38, Moses said:
> gpg: key xxx: error sending to agent: Not enough space
That is a ENOMEM which is commonly returned for a failed malloc call.
Could happen at a lot of places.
Try:
gpg-connect-agent -v
and tehre a command like "getinfo version" to check whether tehre is a
problem with the IPC connection.
gpgconf -L
also gives important information.
> c:\> gpg --version
> gpg (GnuPG) 2.2.15
That version is pretty old and in terms of IPC ("error sending to
agent") one idfference is that this version uses %APPDATA%\gnupg for the
socket files but modern versions use %LOCALAPPDATA%\gnupg.
Shalom-Salam,
Werner
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
openpgp-digital-signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
On Fri, 5 Apr 2024 13:03, Todd Zullinger said: > In such a case, it sounds like it may be reasonable to use > the normal socket? Until the remote side is updated to In fact, I also did this for some time but later came up with CommitDate: Wed Oct 12 11:30:35 2022 +0200 agent: Introduce attribute "Remote-list" to KEYINFO. * agent/command.c (do_one_keyinfo): Add arg list_mode. Check attribute Remote-list. (cmd_keyinfo): Change semantics to return nothing in restricted list mode. which is *** Remote-list Allow to list the key with the KEYINFO command from a remote machine via the extra socket. A boolean value is expected; the default is "no". Note that KEYINFO will anyway provide information if the keygrip is specified. Not exactly your problem but somehow related. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Can not import private key (Not enough space)
Hi, I've encountered an issue while trying to import a private key into GnuPG, resulting in an unexpected error message. Below are the details including the version of GnuPG and the error messages received: c:\> gpg --version gpg (GnuPG) 2.4.5 libgcrypt 1.10.3 ... c:\> gpg --import private-keys.asc gpg: enabled compatibility flags: [snipped] gpg: key xxx: error sending to agent: Not enough space gpg: error reading 'private-keys.asc': Not enough space gpg: import from 'private-keys.asc' failed: Not enough space gpg: Total number processed: 0 gpg: unchanged: 1 gpg: secret keys read: 1 Interestingly, my disk has ample space available, so this error seems to be misleading. Furthermore, when attempting to import the same file on an older GnuPG installation, the import is successful: c:\> gpg --version gpg (GnuPG) 2.2.15 libgcrypt 1.8.4 ... c:\> gpg --import private-keys.asc [snipped] gpg: Total number processed: 2 gpg: unchanged: 2 gpg: secret keys read: 2 gpg: secret keys unchanged: 2 Could you please provide any advice on this matter? Thank you in advance for your assistance. Best regards, -- M. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
Bee via Gnupg-users wrote:
> In the mean time, you could put something along the lines of:
>
> {CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
> listing: Forbidden - ignored$" or something, to keep that output out
> of your stderr stream.
I think there's a downside to that (but I could always be
wrong). Redirecting stderr to stdout would prevent mutt (or
whatever tool was using being used) from being be able to
display output only from stderr. That is helpful when the
exit status is 0 but there were warnings, as in this case.
> If something else unexpected displays, you'll get more issues, but
> then you probably want to know if / when / should that happen.
>
> If you add --quiet now, even when the change below happens later, your
> script above won't need to change again.
Indeed, if Werner weren't so quick, perhaps I would have
considered some sort of adjustment. Though I try to use the
mutt's contrib/gpg.rc unaltered so I don't have to remember
to merge in fixes they make there.
This does remind me that I should re-evaluate using gpgme
as the backend. I don't recall why I disabled that now. It
may have been for an issue which is long-since resolved. ;)
--
Todd
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
Hi Werner, Werner Koch via Gnupg-users wrote: >> gpg: problem with fast path key listing: Forbidden - ignored > > I'll suppress that message in --quiet mode for the next release. Excellent, thanks! > When doing a secret key listing (which happens with -K but also in > --with-colons mode) gpg walks over all public keys and asks the agent > for each key whether a corresponding secret key exists. With many > secret keys this is quite some overhead and thus gpg first tries to a > get a listing of all secret keys (the keygrips) and later can do a fast > memcmp instead of an IPC call. In theory, would this not occur if I cleaned up the keyring a bit. I've got ~350 public keys. Some are likely expired or no longer useful. This is without any sort of auto-key-locate enabled -- just years or accumulating keys. It doesn't _seem_ like that many keys to have around... > If you use the extra-socket certain operations are forbidden so that a > rogue gpg version on the remote site won't be able to change passwords, > export secret keys, or get a listing of all available secret keys. This > is why you see this diagnostic. I manage the remote system and consider it reasonably secure, to the extent any online system can be call "secure." It's not much less secure than the system from which I am forwarding, other than that I'm not physically beside it. In such a case, it sounds like it may be reasonable to use the normal socket? Until the remote side is updated to silence this via --quiet, at least. I saw you pushed the change already, so I applied it to the build on the remote host and can confirm it does the trick. Thanks for the quick reply, fix, and additional details! Cheers, -- Todd ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
In the mean time, you could put something along the lines of:
{CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
listing: Forbidden - ignored$" or something, to keep that output out
of your stderr stream.
If something else unexpected displays, you'll get more issues, but
then you probably want to know if / when / should that happen.
If you add --quiet now, even when the change below happens later, your
script above won't need to change again.
On Fri, Apr 5, 2024 at 5:01 AM Werner Koch via Gnupg-users
wrote:
>
> Hi!
>
> > gpg: problem with fast path key listing: Forbidden - ignored
>
> I'll suppress that message in --quiet mode for the next release.
>
> ...
On Fri, Apr 5, 2024 at 11:24 AM Mike S wrote:
>
> Hello,
>
> is there a way to (re-)enable password storage and retrieval via secret
> service under KDE?
>
> The allow_external_password_cache option was disabled in this ticket:
> https://dev.gnupg.org/rPefb6de7fb2c15c1e31349b80fa7c8c1d4694c6cf
>
> But for me it would be useful to override this setting, I'm not using KWallet
> as my secret-service (I'm using KeePassXC), and are not affected by the
> possible deadlock.
> I thought about somehow changing the XDG_SESSION_DESKTOP env variable that
> pinentry-gtk-2 sees, but I don't think I can do that (because gpg-agent is
> launching pinentry?)
>
>
> Currently I downgraded the pinentry version.
> My problem is, that I sign my git commits and now I have to write my
> passphrase every time I commit.
> (With version 1.2.1-3 it takes the passphrase out of my KeePass database)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
Hi! > gpg: problem with fast path key listing: Forbidden - ignored I'll suppress that message in --quiet mode for the next release. When doing a secret key listing (which happens with -K but also in --with-colons mode) gpg walks over all public keys and asks the agent for each key whether a corresponding secret key exists. With many secret keys this is quite some overhead and thus gpg first tries to a get a listing of all secret keys (the keygrips) and later can do a fast memcmp instead of an IPC call. If you use the extra-socket certain operations are forbidden so that a rogue gpg version on the remote site won't be able to change passwords, export secret keys, or get a listing of all available secret keys. This is why you see this diagnostic. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Agent forwarding issue
Hi, I have been working on setting up agent forwarding¹. One issue which I have not yet found a solution for is that gpg prints the following to stderr when performing actions involving the agent: gpg: problem with fast path key listing: Forbidden - ignored Both hosts are running gnupg-2.4.5, based on the Fedora packages. With mutt, this causes the signing to pause after entering the password, as stderr is not empty (I think this is the reason, anyway). Can this warning be avoided or silenced (without directing stderr to /dev/null)? I can't find much information about it, but it seems like while this is something useful to note, after seeing it once it is simply needless. I believe this is because I've used the extra socket, which seems like the proper thing to do with agent forwarding, but perhaps isn't worth the hassle? I'm not too eager to forward the regular agent when I can use a more restricted socket. ¹ https://wiki.gnupg.org/AgentForwarding Thanks, -- Todd ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 3 Apr 2024, at 10:32, Werner Koch wrote: > > On Tue, 2 Apr 2024 18:53, Andrew Gallagher said: > >> technical challenge since no modern software supports them, and gnupg1 >> doesn’t implement --list-packets :-) But I have to admit they do > > Sure it has the --list-packets command. This command dates back to the > very first release. Please ignore my above remark; PEBKAC :facepalm: > Given that Ubuntu's Hockeypuck is the default keyserver for GnuPG for > most people (i.e. on Windows) it would be good if it continues to > support at least the default keys. Whether X448 or the forthcominng > Kyber subkeys are relevant for keyservers is a different questions. I don’t see why a new algorithm would be fundamentally different from existing ones from a keyserver point of view. I would hope that they could be supported seamlessly. > FWIW, I have severe doubts on the usefulness of public keyservers given > the DoS problems for users and the wrong - but real - assumption of > users that keys from a keyserver are trustworthy. Sending keys with an > initial mail is a better way; keyserver should be used only to provide > subkey updates and revocations - no search by user id. I agree that keyservers are not ideal for userid search - unfortunately we haven’t collectively settled on an alternative yet. Sending initial keys with every email may not be the best solution for large key material such as Kyber, although one could imagine a two-step process such as looking up the signing key of a signed mail via a keyserver. And trust calculations would still be an issue of course; TOFU protects against a passive eavesdropper but doesn’t do much against an active MITM… there’s a lot of work still to be done to improve the UX of mutual verification. > I don't care about the IETF OpenPGP WG^Committee anymore. Like it or not, we have to find some way to tolerate each other’s existence. And petty name-calling doesn’t help. A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Tue, 2 Apr 2024 18:53, Andrew Gallagher said: > technical challenge since no modern software supports them, and gnupg1 > doesn’t implement --list-packets :-) But I have to admit they do Sure it has the --list-packets command. This command dates back to the very first release. >> But let me remark for the records that GnuPG has been the entity which >> always used the term /OpenPGP/ instead of /PGP/ or - as many Linux >> people did - the term /GPG/ keys. Thus we, and in particular me, >> stressed that this is the OpenPGP standard which GnuPG implements, >> popularized, took care, and pride of. Sure it does no "belong" to us or >> anyone - it is term without having a trademark. > > This is fair, and thank you. Not everyone is so careful. Thanks. > greatest amount of text declaring that OpenPGP no longer has a good > reputation has been written by you. So this is a circular argument. Well, I was obviously not caution enough with my statement. What I mean is that the current way the IETF WG works has a high potential to just this. At least an article in the very popular c't magazin might have such an effect. Maybe I should not overvalue such articles and postings on mailing lists. > Let us be clear here: you appear to be saying that if I want to update > hockeypuck to support both librepgp and crypto-refresh artifacts, I am > helping to destroy a solid standard? Or have I misunderstood your Given that Ubuntu's Hockeypuck is the default keyserver for GnuPG for most people (i.e. on Windows) it would be good if it continues to support at least the default keys. Whether X448 or the forthcominng Kyber subkeys are relevant for keyservers is a different questions. FWIW, I have severe doubts on the usefulness of public keyservers given the DoS problems for users and the wrong - but real - assumption of users that keys from a keyserver are trustworthy. Sending keys with an initial mail is a better way; keyserver should be used only to provide subkey updates and revocations - no search by user id. > I will bring this to the WG, with your comments. I don't care about the IETF OpenPGP WG^Committee anymore. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 2 Apr 2024, at 15:24, Werner Koch wrote: > > On Tue, 2 Apr 2024 12:39, Andrew Gallagher said: > >> Are you saying that this is *not* a novel failure mode? Because we’ve > > No. We had v2, v3 and v4 keyes in all kind of combinations in the past > (even as part of subkeys) and back then the two OpenPGP implementations > had no problems with that. The whole point of packet version numbers is > to be able to ignore such packets. This intrigued me, so I went back through the SKS dataset and found exactly four (4) v4 primary keys with v3 subkeys. This was quite a technical challenge since no modern software supports them, and gnupg1 doesn’t implement --list-packets :-) But I have to admit they do exist… and rfc4880 technically doesn’t forbid them. Still, I’m sure most people would find their existence as surprising as that of v3 sbinds over v4 subkeys (which are several orders of magnitude more common). >> different version number (since v3 did not support subkeys). Have you >> interop-tested this with other implementations? Besides RNP? What were > > If there are new implementaions they should check interop with the > de-facto standards which are PGP, GnuPG and later RNP. There is also > the widely used BouncyCastle library and we have not seen problems with > it except when ppl ignore features of these library. BouncyCastle is quite low level, and AFAICT does not enforce much in the way of packet grammar etc., so may not be the best comparison. And surely the entire point of a written specification is to avoid "de-facto standard” reference implementations? > But let me remark for the records that GnuPG has been the entity which > always used the term /OpenPGP/ instead of /PGP/ or - as many Linux > people did - the term /GPG/ keys. Thus we, and in particular me, > stressed that this is the OpenPGP standard which GnuPG implements, > popularized, took care, and pride of. Sure it does no "belong" to us or > anyone - it is term without having a trademark. This is fair, and thank you. Not everyone is so careful. > OTOH, tehre is a > respoisbility here to keep the repudiation of that standard high - this > is what the /current OpenPGP WG participants/ don't a do anymore since > fall 2021. Reputation is a matter of publicly expressed opinion, and by far the greatest amount of text declaring that OpenPGP no longer has a good reputation has been written by you. So this is a circular argument. >>> how should an implementation behave if it wants to support both the >>> librepgp and crypto-refresh specs? > > That is up to those implementaions who want to destroy a solid standard. > Why should I help them? Let us be clear here: you appear to be saying that if I want to update hockeypuck to support both librepgp and crypto-refresh artifacts, I am helping to destroy a solid standard? Or have I misunderstood your position? > This is a GnuPG mailing list and you are > welcome to discuss technical details of stuff relevant to GnuPG and > OpenPGP (up to fall 2021). Everything else is better addressed to the > crypto-refresh commitee. I will bring this to the WG, with your comments. Thanks, A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Tue, 2 Apr 2024 12:39, Andrew Gallagher said: > Are you saying that this is *not* a novel failure mode? Because we’ve No. We had v2, v3 and v4 keyes in all kind of combinations in the past (even as part of subkeys) and back then the two OpenPGP implementations had no problems with that. The whole point of packet version numbers is to be able to ignore such packets. > different version number (since v3 did not support subkeys). Have you > interop-tested this with other implementations? Besides RNP? What were If there are new implementaions they should check interop with the de-facto standards which are PGP, GnuPG and later RNP. There is also the widely used BouncyCastle library and we have not seen problems with it except when ppl ignore features of these library. > 3. The term “OpenPGP” does not belong to GnuPG. But let me remark for the records that GnuPG has been the entity which always used the term /OpenPGP/ instead of /PGP/ or - as many Linux people did - the term /GPG/ keys. Thus we, and in particular me, stressed that this is the OpenPGP standard which GnuPG implements, popularized, took care, and pride of. Sure it does no "belong" to us or anyone - it is term without having a trademark. OTOH, tehre is a respoisbility here to keep the repudiation of that standard high - this is what the /current OpenPGP WG participants/ don't a do anymore since fall 2021. > And I notice that you have not addressed the most important point in > my last email: > >> how should an implementation behave if it wants to support both the >> librepgp and crypto-refresh specs? That is up to those implementaions who want to destroy a solid standard. Why should I help them? This is a GnuPG mailing list and you are welcome to discuss technical details of stuff relevant to GnuPG and OpenPGP (up to fall 2021). Everything else is better addressed to the crypto-refresh commitee. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
[OFF-TOPIC] gpg-agent, sshd and/or SELinux (was Re: Get the private portion of subkeys)
Hi, Werner, all. Please let me take this opportunity to ask you for trustable documentation, or any other resource, which could help interested users like myself in providing the gpg-agent with ssh client and daemon errands, on both fresh and not-so-fresh OS installs. Please consider SELinux contexts if possible. Regards, Marcio Barbado, Jr. On Thu, 28 Mar 2024 at 07:01 Werner Koch via Gnupg-users < gnupg-users@gnupg.org> wrote: > On Thu, 28 Mar 2024 08:26, Damien Cassou said: > > > Is that a problem? Am I missing something important? It seems this > > causes me the troubles mentioned at [1]. > > Your subkeys are all stored on a smartcard. The primary key is online. > This is as intended. If you remove the the primary private key > (.key) You should see a '#' mark for the primary key. > > > My private master key is symlinked in ~/.gnupg/private-keys-v1.d: > > That is intended to work but has not been thoroughly tested. > > > [1] https://github.com/pinpox/pgp2ssh/issues/6 > > That reminds me that we have a function export_secret_ssh_key but it > will always fail with a not-implemented error ;-). Noone of the core > hackers felt a need for it. For example I have not used anything else > than gpg-agent based ssh access since 2005. > > > Shalom-Salam, > >Werner > > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 2 Apr 2024, at 11:58, Werner Koch wrote: > > On Fri, 29 Mar 2024 13:00, Andrew Gallagher said: > >> V5 subkeys of v4 primary keys would appear to introduce a novel >> failure mode. It should be noted that in crypto-refresh, adding a > > Nope. Are you saying that this is *not* a novel failure mode? Because we’ve never before had a key of one version number with a subkey of a different version number (since v3 did not support subkeys). Have you interop-tested this with other implementations? Besides RNP? What were the results? > A v5 key has nothing to do a v4 signature and having different > algorithm on the primary key and the subkeys is really common and > allowed us once to slowly introduce RSA and ECC without any major > problems. This is why we will do the same for PQC encryption. Yes, but a subkey of a different *algorithm* is anticipated by the spec and should work (in principle). A subkey of a different *version* is a different matter. Or is it specified somewhere that I have overlooked? > All in all a really minor changes and not worth a long debate. It may be a minor change, but if it breaks interop it is still worth debating the consequences. > The crypto-refresh has a lot of things which breaks OpenPGP and that > draft, or soon to be RFC, does not care about backward compatibility. > They should not have used the term OpenPGP for this. You keep repeating these talking points, but they are simply not true. 1. crypto-refresh defines a *different* set of extensions to OpenPGP than GnuPG supports, but these do not “break” OpenPGP. 2. crypto-refresh has bumped all of its packet version numbers specifically to avoid compatibility issues. Just because the WG have a different opinion does not mean that they don’t care. 3. The term “OpenPGP” does not belong to GnuPG. And I notice that you have not addressed the most important point in my last email: > how should an implementation behave if it wants to support both the librepgp > and crypto-refresh specs? A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Fri, 29 Mar 2024 13:00, Andrew Gallagher said: > V5 subkeys of v4 primary keys would appear to introduce a novel > failure mode. It should be noted that in crypto-refresh, adding a Nope. A v5 key has nothing to do a v4 signature and having different algorithm on the primary key and the subkeys is really common and allowed us once to slowly introduce RSA and ECC without any major problems. This is why we will do the same for PQC encryption. To repeat: The *v5 key format* merely adds a four-octet count of the public key material to the v4 format. There are also minor chnages for the (not so import) secret key exchange format. And - more important - it defines that the fingerprint is now done using SHA-256. The latter is the whole point why we once decided to use add a v5 format - to make it clear tha a SHA-256 fingerprint is used. All in all a really minor changes and not worth a long debate. The crypto-refresh has a lot of things which breaks OpenPGP and that draft, or soon to be RFC, does not care about backward compatibility. They should not have used the term OpenPGP for this. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Get the private portion of subkeys
Hi Alexander, thank you for giving me background information. It really helped, this sentenc was particularly helpful: Alexander Kulbartsch writes: > When you call "gpg --list-packets sec.asc" > I assume you see something like "gnu-divert-to-card, ..." under your > subkeys When I export today, I see "gnu-divert-to-card" on my subkeys. But if I check on an old backup, I don't see this. So I conclude that my backup contains the private subkeys (good news!). I just found out that if I don't see the subkeys after importing the backup it's just because they are expired: "show-unusable-subkeys" reveal them and everything is good. Thank you so much. -- Damien Cassou "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Get the private portion of subkeys
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
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 signature.asc Description: Message signed with OpenPGP _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?
=
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" "${
Re: x488 vs all other : keyid flip
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
openpgp-digital-signature.asc
Description: PGP signature
_______
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
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. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Get the private portion of subkeys
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 openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
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 1 2 3 4 0 0 A B C D then its
> long keyid is 1 2 3 4 and its short keyid is 22 3 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
openpgp-digital-signature.asc
Description: PGP signature
_______
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
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 3 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. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Get the private portion of subkeys
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
x488 vs all other : keyid flip
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
then its long keyid is
and its short keyid is .
on the other hand a x488 fingerprint is 50 hex characters long. let's say
it's 1 2 3 4 0 0 A B C D then its
long keyid is 1 2 3 4 and its short keyid is 22 3 4.
at least that is what gpg 2.4.4 displays. please shed some light on that
observation.
liberal regards,
chris
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
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 openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
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 0x0004 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 0x0003 > > 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 _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
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 0x0004 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 0x0003 > > 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 _______ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
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 0x0003 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 openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
