From wk at gnupg.org Mon Jun 3 13:31:33 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Jun 2024 13:31:33 +0200 Subject: WSL2: Gpg4win pinentry not available after PIN cache expires In-Reply-To: (David Tagatac's message of "Thu, 30 May 2024 19:15:00 -0700") References: Message-ID: <87sexuw9d6.fsf@jacob.g10code.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From alexander at kulbartsch.de Tue Jun 4 13:20:34 2024 From: alexander at kulbartsch.de (Alexander Kulbartsch) Date: Tue, 04 Jun 2024 13:20:34 +0200 Subject: init gpg via smartcard In-Reply-To: References: Message-ID: Hi! On Mittwoch, 29. Mai 2024 16:14:52 MESZ Henning Follmann wrote: > Hello I do not know if this is possible or even makes sense. The following makes totally sense. I assume you know how to do the steps you describe, if not please ask. I just add some comments. > So an initial setup including a smartcard is like this: > > - generate key pair > - add sub keys - encrypt, sign, auth > - move the private part of sub keys to smartcard > - publish public key to keyserver - To make it perfect, put the URL to the key on the card. In case of WKD you can get the URL using % gpg-wks-client --print-wkd-url (this returns the most complete version, you probably want to reduce this.) Adding the URL on the card: % gpg --card-edit gpg/card> admin gpg/card> url (enter the url) gpg/card> quit > - take the master key offline > > > I want to use the smartcard to initialize gpg on a different > computer: > - plug in smartcard > - fetch the public keys from keyserver % gpg --card-edit gpg/card> fetch gpg/card> quit > - validate the public keys with the keys on smartcard You see if the card matches the fetched key. > - add the stubs for the smartcard keys to my keychain The stub will be automatically generated. > Is there a tool like this? To do all of the above automatically? Not that I am aware of. You might want to write a script. ;) Alexander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 837 bytes Desc: not available URL: From rg at raghavgururajan.name Wed Jun 5 19:06:54 2024 From: rg at raghavgururajan.name (Raghav Gururajan) Date: Wed, 5 Jun 2024 13:06:54 -0400 Subject: Restructure Keys. Message-ID: <6b0fcaa6-d48f-97b8-edb5-fb679e0f5f44@raghavgururajan.name> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Wed Jun 5 21:43:16 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 05 Jun 2024 21:43:16 +0200 Subject: Restructure Keys. In-Reply-To: <6b0fcaa6-d48f-97b8-edb5-fb679e0f5f44@raghavgururajan.name> References: <6b0fcaa6-d48f-97b8-edb5-fb679e0f5f44@raghavgururajan.name> Message-ID: <10480069.nUPlyArG6x@daneel> On Mittwoch, 5. Juni 2024 19:06:54 CEST Raghav Gururajan via Gnupg-users wrote: > 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. 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. > The major caveat is I'll have to update the fingerprint of signing key > at multiple places. Not really. At least not for gpg because gpg will automatically use the newest signing (sub)key for signing data (unless you specified the signing key with trailing exclamation mark). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jun 6 08:14:01 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Jun 2024 08:14:01 +0200 Subject: Restructure Keys. In-Reply-To: <10480069.nUPlyArG6x@daneel> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22?= =?utf-8?Q?'s?= message of "Wed, 05 Jun 2024 21:43:16 +0200") References: <6b0fcaa6-d48f-97b8-edb5-fb679e0f5f44@raghavgururajan.name> <10480069.nUPlyArG6x@daneel> Message-ID: <87frtqvbrq.fsf@jacob.g10code.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From rg at raghavgururajan.name Thu Jun 6 13:18:26 2024 From: rg at raghavgururajan.name (Raghav Gururajan) Date: Thu, 6 Jun 2024 07:18:26 -0400 Subject: Restructure Keys. In-Reply-To: <87frtqvbrq.fsf@jacob.g10code.de> References: <6b0fcaa6-d48f-97b8-edb5-fb679e0f5f44@raghavgururajan.name> <10480069.nUPlyArG6x@daneel> <87frtqvbrq.fsf@jacob.g10code.de> Message-ID: <698b6385-6e6f-f4b2-cee9-4c7c45c81f89@raghavgururajan.name> >> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From info at gamisol.com.ar Thu Jun 6 19:31:38 2024 From: info at gamisol.com.ar (Central Gamisol) Date: Thu, 6 Jun 2024 14:31:38 -0300 (-03) Subject: =?utf-8?q?Nuevo_GUANTE_MULTI_-_120VEF_-_Para_m=C3=BAltiples_tareas!!!?= Message-ID: <1AA-e4af162e9d-@embluemail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrickfmarques at gmail.com Fri Jun 7 12:25:58 2024 From: patrickfmarques at gmail.com (Patrick F. Marques) Date: Fri, 7 Jun 2024 11:25:58 +0100 Subject: GNU Privacy Handbook typo Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From witwall3 at disroot.org Fri Jun 7 23:16:04 2024 From: witwall3 at disroot.org (ael) Date: Fri, 7 Jun 2024 22:16:04 +0100 Subject: gpg-agent timeout Message-ID: 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 From jcb62281 at gmail.com Sat Jun 8 01:03:22 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 07 Jun 2024 18:03:22 -0500 Subject: GNU Privacy Handbook typo In-Reply-To: References: Message-ID: <666391BA.8090705@gmail.com> 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 From eric.pruitt at gmail.com Sat Jun 8 05:26:05 2024 From: eric.pruitt at gmail.com (Eric Pruitt) Date: Fri, 7 Jun 2024 20:26:05 -0700 Subject: GNU Privacy Handbook typo In-Reply-To: <666391BA.8090705@gmail.com> References: <666391BA.8090705@gmail.com> Message-ID: 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 From jcb62281 at gmail.com Sat Jun 8 06:47:08 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 07 Jun 2024 23:47:08 -0500 Subject: GNU Privacy Handbook typo In-Reply-To: References: <666391BA.8090705@gmail.com> Message-ID: <6663E24C.2020201@gmail.com> 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 From eric.pruitt at gmail.com Sat Jun 8 18:12:09 2024 From: eric.pruitt at gmail.com (Eric Pruitt) Date: Sat, 8 Jun 2024 09:12:09 -0700 Subject: GNU Privacy Handbook typo In-Reply-To: <6663E24C.2020201@gmail.com> References: <666391BA.8090705@gmail.com> <6663E24C.2020201@gmail.com> Message-ID: 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 From jaymanshad at proton.me Sat Jun 8 04:35:27 2024 From: jaymanshad at proton.me (Jace) Date: Sat, 08 Jun 2024 02:35:27 +0000 Subject: request for account on dev.gnupg.org Message-ID: Hello, I would like an account in order to report a bug handle: modernNeo shown name: Jace M. email: jaymanshad at proton.me -JM Sent with [Proton Mail](https://proton.me/) secure email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jun 10 08:54:56 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Jun 2024 08:54:56 +0200 Subject: gpg-agent timeout In-Reply-To: (ael via Gnupg-users's message of "Fri, 7 Jun 2024 22:16:04 +0100") References: Message-ID: <87a5jtthhb.fsf@jacob.g10code.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mwood at iu.edu Mon Jun 10 22:51:04 2024 From: mwood at iu.edu (mwood at iu.edu) Date: Mon, 10 Jun 2024 16:51:04 -0400 Subject: GNU Privacy Handbook typo In-Reply-To: <899b818da7d3425e96ff1288de0f49c4@CH0PR08MB7308.namprd08.prod.outlook.com> References: <666391BA.8090705@gmail.com> <899b818da7d3425e96ff1288de0f49c4@CH0PR08MB7308.namprd08.prod.outlook.com> Message-ID: On Sat, Jun 08, 2024 at 03:26:05AM +0000, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From witwall3 at disroot.org Tue Jun 11 18:18:42 2024 From: witwall3 at disroot.org (ael) Date: Tue, 11 Jun 2024 17:18:42 +0100 Subject: gpg-agent timeout In-Reply-To: <87a5jtthhb.fsf@jacob.g10code.de> References: <87a5jtthhb.fsf@jacob.g10code.de> Message-ID: 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 From mm at dorfdsl.de Wed Jun 12 21:37:11 2024 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 12 Jun 2024 21:37:11 +0200 Subject: S/MIME which certificate format Message-ID: <20240612213711.178b78da@dorfdsl.de> Hello! I got an S/MIME certificate from Sectigo, which I would like to use with gpgsm/Kleopatra. I got a .crt (PEM according to the file command) from them and I used openssl to create a pfx (also tried p12) together with my private key. openssl pkcs12 -export -out zertifikat-smime/zert-alles.pfx -inkey zertifikat-smime/smime-priv.key -in zertifikat-smime/zertifikat-umbruch.crt -certfile zertifikat-smime/sectigo-ca.crt I tried to import it, but it doesn't work. Is that the right way to create the pfx file that can be used with gpgsm/Kleopatra? Parts of the log (full file attached): gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: unknown digest algorithm '?' used certificate gpgsm: certificate has a BAD signature: General error gpgsm: basic certificate checks failed - not imported gpgsm: DBG: _tlv_next: tlv_next skipped gpgsm: DBG: p12_parse:bags/endloop:2753: @5986 lvl=1 gpgsm: DBG: chan_4 -> KEYWRAP_KEY --import gpgsm: DBG: chan_4 <- [ xyz xyz a3 ...(2 byte(s) skipped) ] gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> IMPORT_KEY --timestamp=20240612T192929 gpgsm: DBG: chan_4 <- INQUIRE KEYDATA gpgsm: DBG: chan_4 -> [[Confidential data not shown]] gpgsm: DBG: chan_4 -> [[Confidential data not shown]] gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- ERR 67141667 Die Datei existiert bereits -- kind regards Marco -------------- next part -------------- gpgsm: enabled debug flags: ipc gpgsm: enabled compatibility flags: gpgsm: DBG: chan_4 <- OK Pleased to meet you, process 50840 gpgsm: DBG: connection to agent established gpgsm: DBG: chan_4 -> RESET gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttyname=/dev/pts/4 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttytype=xterm gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION display=:0.0 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION xauthority=/home/m/.Xauthority gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION putenv=XDG_SESSION_TYPE=tty gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-ctype=C gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-messages=C gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> GETINFO version gpgsm: DBG: chan_4 <- D 2.2.43 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION allow-pinentry-notify gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> [[Confidential data not shown]] gpgsm: DBG: chan_4 <- [[Confidential data not shown]] gpgsm: DBG: chan_4 -> [[Confidential data not shown]] gpgsm: DBG: chan_4 <- [[Confidential data not shown]] gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2662: @0000 class=0 tag=16 len=6047 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0004 lvl=1 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2668: @0004 class=0 tag=2 len=1 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2674: @0007 class=0 tag=16 len=5973 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0011 lvl=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2679: @0011 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2686: @0022 class=2 tag=0 len=5958 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0026 lvl=3 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2691: @0026 class=0 tag=4 len=5954 nhdr=4 gpgsm: DBG: p12_parse:_tlv_push:549: @0030 lvl=4 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2706: @0030 class=0 tag=16 len=5950 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0034 lvl=5 gpgsm: DBG: p12_parse:bags/beginloop:2712: @0034 lvl=5 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2713: @0034 class=0 tag=16 len=3370 nhdr=4 cons gpgsm: DBG: p12_parse:bag-sequence:2716: @0038 lvl=5 gpgsm: DBG: p12_parse:_tlv_push:549: @0038 lvl=6 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2720: @0038 class=0 tag=6 len=9 nhdr=2 gpgsm: processing bag.encryptedData gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1421: @0049 class=2 tag=0 len=3355 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0053 lvl=7 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1426: @0053 class=0 tag=16 len=3351 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0057 lvl=8 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1432: @0057 class=0 tag=2 len=1 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1442: @0060 class=0 tag=16 len=3344 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0064 lvl=9 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1448: @0064 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1456: @0075 class=0 tag=16 len=95 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0077 lvl=10 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1461: @0077 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1488: @0088 class=0 tag=16 len=82 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0090 lvl=11 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1493: @0090 class=0 tag=16 len=49 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0092 lvl=12 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1498: @0092 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1509: @0103 class=0 tag=16 len=36 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0105 lvl=13 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1515: @0105 class=0 tag=4 len=16 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1529: @0123 class=0 tag=2 len=2 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1543: @0127 class=0 tag=16 len=12 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0129 lvl=14 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1547: @0129 class=0 tag=6 len=8 nhdr=2 gpgsm: DBG: kdf digest algo = 8 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1564: @0139 class=0 tag=5 len=0 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @0141 lvl=13 gpgsm: DBG: p12_parse:_tlv_pop:590: @0141 lvl=12 gpgsm: DBG: p12_parse:_tlv_pop:590: @0141 lvl=11 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:1571: @0141 class=0 tag=16 len=29 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0143 lvl=12 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1576: @0143 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1594: @0154 class=0 tag=4 len=16 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @0172 lvl=11 gpgsm: DBG: p12_parse:_tlv_pop:590: @0172 lvl=10 gpgsm: DBG: p12_parse:_tlv_pop:590: @0172 lvl=9 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:1639: @0172 class=2 tag=0 len=3232 nhdr=4 gpgsm: 3232 bytes of AES256 encrypted text gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1679: @0000 class=0 tag=16 len=3212 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0004 lvl=1 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1693: @0004 class=0 tag=16 len=1607 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0008 lvl=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1704: @0008 class=0 tag=6 len=11 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1730: @0021 class=2 tag=0 len=1551 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0025 lvl=3 gpgsm: processing certBag gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1840: @0025 class=0 tag=16 len=1547 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0029 lvl=4 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1845: @0029 class=0 tag=6 len=10 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1858: @0041 class=2 tag=0 len=1531 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0045 lvl=5 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1868: @0045 class=0 tag=4 len=1527 nhdr=4 gpgsm: unknown digest algorithm '?' used certificate gpgsm: certificate has a BAD signature: General error gpgsm: basic certificate checks failed - not imported gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @1576 lvl=4 gpgsm: DBG: p12_parse:_tlv_pop:590: @1576 lvl=3 gpgsm: DBG: p12_parse:_tlv_pop:590: @1576 lvl=2 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:1882: @1576 class=0 tag=17 len=37 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @1578 lvl=3 gpgsm: skipping bag.attribute_set gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @1615 lvl=2 gpgsm: DBG: p12_parse:_tlv_pop:590: @1615 lvl=1 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:1693: @1615 class=0 tag=16 len=1597 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @1619 lvl=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1704: @1619 class=0 tag=6 len=11 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1730: @1632 class=2 tag=0 len=1580 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @1636 lvl=3 gpgsm: processing certBag gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1840: @1636 class=0 tag=16 len=1576 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @1640 lvl=4 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1845: @1640 class=0 tag=6 len=10 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1858: @1652 class=2 tag=0 len=1560 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @1656 lvl=5 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1868: @1656 class=0 tag=4 len=1556 nhdr=4 gpgsm: certificate is good gpgsm: certificate is good gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @3216 lvl=4 gpgsm: DBG: p12_parse:_tlv_pop:590: @3216 lvl=3 gpgsm: DBG: p12_parse:_tlv_pop:590: @3216 lvl=2 gpgsm: DBG: p12_parse:_tlv_pop:590: @3216 lvl=1 gpgsm: DBG: p12_parse:_tlv_pop:590: @3216 lvl=0 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @3408 lvl=8 gpgsm: DBG: p12_parse:_tlv_pop:590: @3408 lvl=7 gpgsm: DBG: p12_parse:_tlv_pop:590: @3408 lvl=6 gpgsm: DBG: p12_parse:_tlv_pop:590: @3408 lvl=5 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:2713: @3408 class=0 tag=16 len=2572 nhdr=4 cons gpgsm: DBG: p12_parse:bag-sequence:2716: @3412 lvl=5 gpgsm: DBG: p12_parse:_tlv_push:549: @3412 lvl=6 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2720: @3412 class=0 tag=6 len=9 nhdr=2 gpgsm: processing bag data gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2536: @3423 class=2 tag=0 len=2557 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3427 lvl=7 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2541: @3427 class=0 tag=4 len=2553 nhdr=4 gpgsm: DBG: p12_parse:_tlv_push:549: @3431 lvl=8 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2559: @3431 class=0 tag=16 len=2549 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3435 lvl=9 gpgsm: DBG: p12_parse:data.outerseqs/beginloop:2565: @3435 lvl=9 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2566: @3435 class=0 tag=16 len=2545 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3439 lvl=10 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2579: @3439 class=0 tag=6 len=11 nhdr=2 gpgsm: processing shrouded_key_bag gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1982: @3452 class=2 tag=0 len=2489 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3456 lvl=11 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1987: @3456 class=0 tag=16 len=2485 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3460 lvl=12 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1993: @3460 class=0 tag=16 len=95 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3462 lvl=13 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1998: @3462 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2021: @3473 class=0 tag=16 len=82 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3475 lvl=14 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2026: @3475 class=0 tag=16 len=49 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3477 lvl=15 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2031: @3477 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2039: @3488 class=0 tag=16 len=36 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3490 lvl=16 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2045: @3490 class=0 tag=4 len=16 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2059: @3508 class=0 tag=2 len=2 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2073: @3512 class=0 tag=16 len=12 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3514 lvl=17 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2077: @3514 class=0 tag=6 len=8 nhdr=2 gpgsm: DBG: kdf digest algo = 8 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2094: @3524 class=0 tag=5 len=0 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @3526 lvl=16 gpgsm: DBG: p12_parse:_tlv_pop:590: @3526 lvl=15 gpgsm: DBG: p12_parse:_tlv_pop:590: @3526 lvl=14 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:2101: @3526 class=0 tag=16 len=29 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @3528 lvl=15 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2106: @3528 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2123: @3539 class=0 tag=4 len=16 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @3557 lvl=14 gpgsm: DBG: p12_parse:_tlv_pop:590: @3557 lvl=13 gpgsm: DBG: p12_parse:_tlv_pop:590: @3557 lvl=12 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:2165: @3557 class=0 tag=4 len=2384 nhdr=4 gpgsm: 2384 bytes of AES256 encrypted text gpgsm: DBG: new parser context gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2208: @0000 class=0 tag=16 len=2369 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0004 lvl=1 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2219: @0004 class=0 tag=2 len=1 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2236: @0007 class=0 tag=16 len=13 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0009 lvl=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2241: @0009 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: RSA parameters gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2254: @0020 class=0 tag=5 len=0 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @0022 lvl=1 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:2284: @0022 class=0 tag=4 len=2347 nhdr=4 gpgsm: DBG: p12_parse:_tlv_push:549: @0026 lvl=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2289: @0026 class=0 tag=16 len=2343 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0030 lvl=3 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @0030 class=0 tag=2 len=1 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @0033 class=0 tag=2 len=513 nhdr=4 gpgsm: DBG: RSA key parameter 0 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @0550 class=0 tag=2 len=3 nhdr=2 gpgsm: DBG: RSA key parameter 1 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @0555 class=0 tag=2 len=512 nhdr=4 gpgsm: DBG: RSA key parameter 2 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @1071 class=0 tag=2 len=257 nhdr=4 gpgsm: DBG: RSA key parameter 3 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @1332 class=0 tag=2 len=257 nhdr=4 gpgsm: DBG: RSA key parameter 4 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @1593 class=0 tag=2 len=256 nhdr=4 gpgsm: DBG: RSA key parameter 5 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @1853 class=0 tag=2 len=256 nhdr=4 gpgsm: DBG: RSA key parameter 6 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:2343: @2113 class=0 tag=2 len=256 nhdr=4 gpgsm: DBG: RSA key parameter 7 found gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @2373 lvl=2 gpgsm: DBG: p12_parse:_tlv_pop:590: @2373 lvl=1 gpgsm: DBG: p12_parse:_tlv_pop:590: @2373 lvl=0 gpgsm: DBG: restoring parser context gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @5945 lvl=11 gpgsm: DBG: p12_parse:_tlv_pop:590: @5945 lvl=10 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:2386: @5945 class=0 tag=17 len=37 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @5947 lvl=11 gpgsm: skipping shrouded_key_bag.attribute_set gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=10 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=9 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=8 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=7 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=6 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=5 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=4 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=3 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=2 gpgsm: DBG: p12_parse:_tlv_pop:590: @5984 lvl=1 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:2566: @5984 class=0 tag=16 len=65 nhdr=2 cons gpgsm: DBG: p12_parse:data.outerseqs/endloop:2604: @5986 lvl=1 gpgsm: DBG: _tlv_next: tlv_next skipped gpgsm: DBG: p12_parse:bags/endloop:2753: @5986 lvl=1 gpgsm: DBG: chan_4 -> KEYWRAP_KEY --import gpgsm: DBG: chan_4 <- [ 44 20 4e f7 b1 c6 a9 4e 12 bd 99 b5 c7 6c ed a3 ...(2 byte(s) skipped) ] gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> IMPORT_KEY --timestamp=20240612T192929 gpgsm: DBG: chan_4 <- INQUIRE KEYDATA gpgsm: DBG: chan_4 -> [[Confidential data not shown]] gpgsm: DBG: chan_4 -> [[Confidential data not shown]] gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- ERR 67141667 Die Datei existiert bereits gpgsm: total number processed: 3 gpgsm: unchanged: 1 gpgsm: secret keys read: 1 gpgsm: secret keys unchanged: 1 gpgsm: not imported: 1 secmem usage: 0/16384 bytes in 0 blocks From witwall3 at disroot.org Thu Jun 13 12:57:24 2024 From: witwall3 at disroot.org (ael) Date: Thu, 13 Jun 2024 11:57:24 +0100 Subject: Detecting a misremembered passphrase in gpg-agent In-Reply-To: <87a5jtthhb.fsf@jacob.g10code.de> References: <87a5jtthhb.fsf@jacob.g10code.de> Message-ID: 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 From witwall3 at disroot.org Thu Jun 13 13:05:32 2024 From: witwall3 at disroot.org (ael) Date: Thu, 13 Jun 2024 12:05:32 +0100 Subject: Detecting a misremembered passphrase in gpg-agent In-Reply-To: <87a5jtthhb.fsf@jacob.g10code.de> References: <87a5jtthhb.fsf@jacob.g10code.de> Message-ID: 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 From aelnosu at gmail.com Thu Jun 13 00:30:54 2024 From: aelnosu at gmail.com (Eason Lu) Date: Wed, 12 Jun 2024 15:30:54 -0700 Subject: Help With GPG trust model Message-ID: 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 From fa-ml at ariis.it Thu Jun 13 14:41:14 2024 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 13 Jun 2024 14:41:14 +0200 Subject: Help With GPG trust model In-Reply-To: References: Message-ID: Hello Eason, Il 12 giugno 2024 alle 15:30 Eason Lu via Gnupg-users ha scritto: > 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. I trust other people?s keys with `gpg --sign-key `. You don?t need to upload the key to a key server or send it to the recipient if you don?t want to. Does this help? ?F From ostroffjh at users.sourceforge.net Thu Jun 13 20:09:15 2024 From: ostroffjh at users.sourceforge.net (Jack) Date: Thu, 13 Jun 2024 14:09:15 -0400 Subject: Detecting a misremembered passphrase in gpg-agent In-Reply-To: References: <87a5jtthhb.fsf@jacob.g10code.de> Message-ID: 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 From witwall3 at disroot.org Thu Jun 13 23:24:56 2024 From: witwall3 at disroot.org (ael) Date: Thu, 13 Jun 2024 22:24:56 +0100 Subject: Detecting a misremembered passphrase in gpg-agent In-Reply-To: References: <87a5jtthhb.fsf@jacob.g10code.de> Message-ID: 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 From aelnosu at gmail.com Fri Jun 14 03:19:53 2024 From: aelnosu at gmail.com (Eason Lu) Date: Thu, 13 Jun 2024 18:19:53 -0700 Subject: S/MIME which certificate format In-Reply-To: <20240612213711.178b78da@dorfdsl.de> References: <20240612213711.178b78da@dorfdsl.de> Message-ID: 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 From aelnosu at gmail.com Fri Jun 14 03:16:42 2024 From: aelnosu at gmail.com (Eason Lu) Date: Thu, 13 Jun 2024 18:16:42 -0700 Subject: Help With GPG trust model In-Reply-To: References: Message-ID: <345e56f2-4a32-407f-94ee-6dc6326ad29d@gmail.com> Thank you Francesco that does help, I did not realize that by signing the public key, it is also mark as trusted, thanks Eason From mm at dorfdsl.de Fri Jun 14 11:30:06 2024 From: mm at dorfdsl.de (Marco Moock) Date: Fri, 14 Jun 2024 11:30:06 +0200 Subject: S/MIME which certificate format In-Reply-To: References: <20240612213711.178b78da@dorfdsl.de> Message-ID: <20240614113006.51bc2c5b@dorfdsl.de> Am 13.06.2024 um 18:19:53 Uhr schrieb Eason Lu via Gnupg-users: > 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. Kleopatra doesn't accept it either, that is why I tried to use gpgsm directly to see what may be the issue. I need to find out what causes that. How can I diagnose what causes that? gpgsm: unknown digest algorithm '?' used certificate gpgsm: certificate has a BAD signature: General error -- kind regards Marco From kloecker at kde.org Fri Jun 14 11:48:25 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 14 Jun 2024 11:48:25 +0200 Subject: Help With GPG trust model In-Reply-To: <345e56f2-4a32-407f-94ee-6dc6326ad29d@gmail.com> References: <345e56f2-4a32-407f-94ee-6dc6326ad29d@gmail.com> Message-ID: <1798569.VLH7GnMWUR@daneel> On Freitag, 14. Juni 2024 03:16:42 CEST Eason Lu via Gnupg-users wrote: > Thank you Francesco that does help, > I did not realize that by signing the public key, it is also mark as > trusted, thanks "trusted" is an ambiguous word in OpenPGP, i.e. it's use for different things. By signing a public key (or, more precisely, one or more user IDs of the public key) you certify that this public key is controlled by the person(s) referenced in the user ID(s) that you signed. "certified" would be a better alternative for "trusted" in this case. You can create "local" non?exportable certifications for your own use (by using --lsign-key) and exportable certifications for sharing them with others (--sign-key). By setting the owner trust of a public key (let's call it "T") to "full trust" you tell gpg that you trust that the owner of this public key does a good job when they certify other public keys. If you additionally certify the public key "T" then your gpg will consider other public keys that are certified with "T" as "certified". This is (part of) how the web-of-trust works. Owner trust is never exported with a public key, i.e. its only used for yourself. When you generate a new key then its owner trust is automatically set to "ultimate". Public keys with "ultimate" owner trust are considered as "certified" by gpg without further certifications. You should only use "ultimate" owner trust for your own keys. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Fri Jun 14 11:51:07 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 14 Jun 2024 11:51:07 +0200 Subject: S/MIME which certificate format In-Reply-To: <20240614113006.51bc2c5b@dorfdsl.de> References: <20240612213711.178b78da@dorfdsl.de> <20240614113006.51bc2c5b@dorfdsl.de> Message-ID: <3492260.QJadu78ljV@daneel> On Freitag, 14. Juni 2024 11:30:06 CEST Marco Moock wrote: > Am 13.06.2024 um 18:19:53 Uhr schrieb Eason Lu via Gnupg-users: > > 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. > > Kleopatra doesn't accept it either, that is why I tried to use gpgsm > directly to see what may be the issue. > > I need to find out what causes that. How can I diagnose what causes > that? > gpgsm: unknown digest algorithm '?' used certificate > gpgsm: certificate has a BAD signature: General error Start by adding "--verbose" to the command line of gpgsm. You can add "--verbose" multiple times to increase the verbosity. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From mm at dorfdsl.de Fri Jun 14 15:01:59 2024 From: mm at dorfdsl.de (Marco Moock) Date: Fri, 14 Jun 2024 15:01:59 +0200 Subject: S/MIME which certificate format In-Reply-To: <3492260.QJadu78ljV@daneel> References: <20240612213711.178b78da@dorfdsl.de> <20240614113006.51bc2c5b@dorfdsl.de> <3492260.QJadu78ljV@daneel> Message-ID: <20240614150159.36a00003@dorfdsl.de> Am 14.06.2024 um 11:51:07 Uhr schrieb Ingo Kl?cker: > Start by adding "--verbose" to the command line of gpgsm. You can add > "--verbose" multiple times to increase the verbosity. I did that and it shows me some stuff. The question is how can I find out why the digest algorithm isn't recognized? Openssl gives me: Signature Algorithm: sha256WithRSAEncryption gpgsm: DBG: kdf digest algo = 8 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1564: @0139 class=0 tag=5 len=0 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @0141 lvl=13 gpgsm: DBG: p12_parse:_tlv_pop:590: @0141 lvl=12 gpgsm: DBG: p12_parse:_tlv_pop:590: @0141 lvl=11 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:1571: @0141 class=0 tag=16 len=29 nhdr=2 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0143 lvl=12 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1576: @0143 class=0 tag=6 len=9 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1594: @0154 class=0 tag=4 len=16 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_pop:590: @0172 lvl=11 gpgsm: DBG: p12_parse:_tlv_pop:590: @0172 lvl=10 gpgsm: DBG: p12_parse:_tlv_pop:590: @0172 lvl=9 gpgsm: DBG: _tlv_next: container(s) closed due to size gpgsm: DBG: p12_parse:_tlv_next:1639: @0172 class=2 tag=0 len=3232 nhdr=4 gpgsm: 3232 bytes of AES256 encrypted text gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1679: @0000 class=0 tag=16 len=3212 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0004 lvl=1 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1693: @0004 class=0 tag=16 len=1607 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0008 lvl=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1704: @0008 class=0 tag=6 len=11 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1730: @0021 class=2 tag=0 len=1551 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0025 lvl=3 gpgsm: processing certBag gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1840: @0025 class=0 tag=16 len=1547 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0029 lvl=4 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1845: @0029 class=0 tag=6 len=10 nhdr=2 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1858: @0041 class=2 tag=0 len=1531 nhdr=4 cons gpgsm: DBG: p12_parse:_tlv_push:549: @0045 lvl=5 gpgsm: DBG: _tlv_next: tlv_next called gpgsm: DBG: p12_parse:_tlv_next:1868: @0045 class=0 tag=4 len=1527 nhdr=4 gpgsm: unknown digest algorithm '?' used certificate gpgsm: certificate has a BAD signature: General error gpgsm: basic certificate checks failed - not imported -- kind regards Marco From mm at dorfdsl.de Fri Jun 14 17:55:23 2024 From: mm at dorfdsl.de (Marco Moock) Date: Fri, 14 Jun 2024 17:55:23 +0200 Subject: which application enables =?UTF-8?B?YWxsb3figJBvY3Nw?= in dirmngr.conf? Message-ID: <20240614175523.5f7cd9e3@dorfdsl.de> Hello! This refers to Message-ID: <20240614145243.7e5f224a at dorfdsl.de> Message-ID: <1866463.atdPhlSkOF at daneel> https://marc.info/?l=kdepim-users&m=171837895002483&w=2 If I enable check validity of SMIME via OCSP, there won't be added a line allow_ocsp, which is needed according to the post of Ingo. By default in Debian, the check won't work and will result in dirmngr[30845.5]: command 'ISVALID' failed: Nicht unterst?tzt Which application is responsible for changing that? My file looks like that: m at ryz:~$ cat .gnupg/dirmngr.conf ###+++--- GPGConf ---+++### debug-level basic log-file socket:///home/m/.gnupg/log-socket ###+++--- GPGConf ---+++### Fr 14 Jun 2024 14:34:45 CEST # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. m at ryz:~$ -- kind regards Marco From kloecker at kde.org Mon Jun 17 14:37:09 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 17 Jun 2024 14:37:09 +0200 Subject: which application enables =?UTF-8?B?YWxsb3figJBvY3Nw?= in dirmngr.conf? In-Reply-To: <20240614175523.5f7cd9e3@dorfdsl.de> References: <20240614175523.5f7cd9e3@dorfdsl.de> Message-ID: <3305897.44csPzL39Z@daneel> On Freitag, 14. Juni 2024 17:55:23 CEST Marco Moock wrote: > If I enable check validity of SMIME via OCSP, there won't be added a > line allow_ocsp, which is needed according to the post of Ingo. > By default in Debian, the check won't work and will result in > > dirmngr[30845.5]: command 'ISVALID' failed: Nicht unterst?tzt > > Which application is responsible for changing that? Kleopatra. I checked "Validate certificates online (OCSP)" and clicked Apply. I verified that allow-ocsp was added to my dirmngr.conf. I'm using a self-compiled gpg 2.4.6-beta and the lasted development version of Kleopatra. Maybe your version of gpg and/or Kleopatra is too old or there is a bug in your version. Is "Allow sending OCSP requests" listed as option in the Kleopatra settings dialog under GnuPG System/Network? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From mm at dorfdsl.de Mon Jun 17 14:43:45 2024 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 17 Jun 2024 14:43:45 +0200 Subject: which application enables =?UTF-8?B?YWxsb3figJBvY3Nw?= in dirmngr.conf? In-Reply-To: <3305897.44csPzL39Z@daneel> References: <20240614175523.5f7cd9e3@dorfdsl.de> <3305897.44csPzL39Z@daneel> Message-ID: <20240617144345.07f26552@dorfdsl.de> Am 17.06.2024 um 14:37:09 Uhr schrieb Ingo Kl?cker: > Is "Allow sending OCSP requests" listed as option in the > Kleopatra settings dialog under GnuPG System/Network? It wasn't, I enabled it, but the error stays. -- kind regards Marco From wk at gnupg.org Mon Jun 17 15:32:10 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Jun 2024 15:32:10 +0200 Subject: which application enables =?utf-8?Q?allow=E2=80=90ocsp?= in dirmngr.conf? In-Reply-To: <20240617144345.07f26552@dorfdsl.de> (Marco Moock's message of "Mon, 17 Jun 2024 14:43:45 +0200") References: <20240614175523.5f7cd9e3@dorfdsl.de> <3305897.44csPzL39Z@daneel> <20240617144345.07f26552@dorfdsl.de> Message-ID: <87iky7pued.fsf@jacob.g10code.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Mon Jun 17 15:40:00 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Jun 2024 15:40:00 +0200 Subject: How to ask for support (was: S/MIME which certificate format) In-Reply-To: <20240612213711.178b78da@dorfdsl.de> (Marco Moock's message of "Wed, 12 Jun 2024 21:37:11 +0200") References: <20240612213711.178b78da@dorfdsl.de> Message-ID: <87ed8vpu1b.fsf@jacob.g10code.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mm at dorfdsl.de Mon Jun 17 16:22:22 2024 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 17 Jun 2024 16:22:22 +0200 Subject: which application enables =?UTF-8?B?YWxsb3figJBvY3Nw?= in dirmngr.conf? In-Reply-To: <87iky7pued.fsf@jacob.g10code.de> References: <20240614175523.5f7cd9e3@dorfdsl.de> <3305897.44csPzL39Z@daneel> <20240617144345.07f26552@dorfdsl.de> <87iky7pued.fsf@jacob.g10code.de> Message-ID: <20240617162222.322e96e4@dorfdsl.de> Am 17.06.2024 um 15:32:10 Uhr schrieb Werner Koch: > 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 # gpgconf -X invoked 2024-06-17 14:19:46 -*- org -*- * General information ** Versions GnuPG 2.2.43 (0000000) GNU/Linux Libgcrypt 1.10.3 GpgRT 1.49 ** Directories #+begin_example sysconfdir:/etc/gnupg bindir:/usr/bin libexecdir:/usr/lib/gnupg libdir:/usr/lib/x86_64-linux-gnu/gnupg datadir:/usr/share/gnupg localedir:/usr/share/locale socketdir:/run/user/1000/gnupg dirmngr-socket:/run/user/1000/gnupg/S.dirmngr agent-ssh-socket:/run/user/1000/gnupg/S.gpg-agent.ssh agent-extra-socket:/run/user/1000/gnupg/S.gpg-agent.extra agent-browser-socket:/run/user/1000/gnupg/S.gpg-agent.browser agent-socket:/run/user/1000/gnupg/S.gpg-agent homedir:/home/m/.gnupg #+end_example ** Environment #+begin_example PATH=/home/m/.local/bin:~/.local/bin:/usr/dt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/usr/dt/bin:/usr/dt/bin #+end_example * Config files ** local config "/home/m/.gnupg/gpg-agent.conf" #+begin_src ###+++--- GPGConf ---+++### debug-level basic log-file socket:///home/m/.gnupg/log-socket ###+++--- GPGConf ---+++### Fr 14 Jun 2024 14:34:45 CEST # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. #+end_src ** local config "/home/m/.gnupg/scdaemon.conf" #+begin_src ###+++--- GPGConf ---+++### debug-level basic log-file socket:///home/m/.gnupg/log-socket ###+++--- GPGConf ---+++### Fr 14 Jun 2024 14:34:45 CEST # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. #+end_src ** local config "/home/m/.gnupg/dirmngr.conf" #+begin_src ###+++--- GPGConf ---+++### debug-level basic log-file socket:///home/m/.gnupg/log-socket allow-ocsp ###+++--- GPGConf ---+++### Mo 17 Jun 2024 14:42:52 CEST # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. #+end_src ** local config "/home/m/.gnupg/gpg.conf" #+begin_src ###+++--- GPGConf ---+++### utf8-strings debug-level basic log-file socket:///home/m/.gnupg/log-socket ###+++--- GPGConf ---+++### Fr 14 Jun 2024 14:34:45 CEST # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. #+end_src ** local config "/home/m/.gnupg/gpgsm.conf" #+begin_src ###+++--- GPGConf ---+++### debug-level basic log-file socket:///home/m/.gnupg/log-socket enable-ocsp ###+++--- GPGConf ---+++### Fr 14 Jun 2024 14:35:14 CEST # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. #+end_src * Other info # eof # -- Gru? Marco From bernhard at intevation.de Mon Jun 17 17:14:07 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Jun 2024 17:14:07 +0200 Subject: S/MIME which certificate format In-Reply-To: <20240612213711.178b78da@dorfdsl.de> References: <20240612213711.178b78da@dorfdsl.de> Message-ID: <202406171714.15110.bernhard@intevation.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From mm at dorfdsl.de Mon Jun 17 19:27:35 2024 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 17 Jun 2024 19:27:35 +0200 Subject: S/MIME which certificate format In-Reply-To: <202406171714.15110.bernhard@intevation.de> References: <20240612213711.178b78da@dorfdsl.de> <202406171714.15110.bernhard@intevation.de> Message-ID: <20240617192735.111043ec@dorfdsl.de> Am 17.06.2024 um 17:14:07 Uhr schrieb Bernhard Reiter via Gnupg-users: > 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? They offer a CA cert which can be imported properly. https://www.sectigo.com/resource-library/sectigo-root-intermediate-certificate-files > 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. I can send you mine if you would like to test. -- Gru? Marco From mm at dorfdsl.de Mon Jun 17 19:30:19 2024 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 17 Jun 2024 19:30:19 +0200 Subject: How to ask for support (was: S/MIME which certificate format) In-Reply-To: <87ed8vpu1b.fsf@jacob.g10code.de> References: <20240612213711.178b78da@dorfdsl.de> <87ed8vpu1b.fsf@jacob.g10code.de> Message-ID: <20240617193019.7d238edb@dorfdsl.de> Am 17.06.2024 um 15:40:00 Uhr schrieb Werner Koch: > 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. Is included in the attachment. I am running Debian 13, if that is relevant too. -- kind regards Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: system-info Type: application/octet-stream Size: 4289 bytes Desc: not available URL: From bernhard at intevation.de Tue Jun 18 08:44:00 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 18 Jun 2024 08:44:00 +0200 Subject: S/MIME which certificate format In-Reply-To: <20240617192735.111043ec@dorfdsl.de> References: <20240612213711.178b78da@dorfdsl.de> <202406171714.15110.bernhard@intevation.de> <20240617192735.111043ec@dorfdsl.de> Message-ID: <202406180844.08715.bernhard@intevation.de> Am Montag 17 Juni 2024 19:27:35 schrieb Marco Moock: > Am 17.06.2024 um 17:14:07 Uhr schrieb Bernhard Reiter via Gnupg-users: > > does Sectigo offer a public certificate somewhere which could > > possibly be imported for a test? > I can send you mine if you would like to test. At least I can try to import it and see what my version says. BTW: at least once in the last years Debian had some patches that GnuPG upstream did not recommend. So yes, the behaviour can be different in the GnuPG packages from distributions. If the precise package can be given it sometimes helps to reproduce an issue. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From guru at unixarea.de Tue Jun 18 13:30:13 2024 From: guru at unixarea.de (Matthias Apitz) Date: Tue, 18 Jun 2024 13:30:13 +0200 Subject: OpenPGP card or USB dongle uTrust stopped working Message-ID: Hello, I do use since "ages" an OpenPGP card in an USB dongle "uTrust 3512" with GnuPG, mostly for the password-store. Today, from one minute to the other it stopped working. On attach the uTrust shows up fine in /var/log/messages with: Jun 18 13:08:52 c720-1400094 kernel: ugen0.4: at usbus0 but when I access the card, the message is: $ gpg2 --card-status gpg: selecting card failed: Operation not supported by device gpg: OpenPGP card not available: Operation not supported by device and the LEDs on the dongle keep flickering for some seconds (even after the message is already printed). How can I detect if the problem is the SIM-card or the USB dongle? The problem is in both USB ports of my laptop, that's why I would say, the ports are fine. Petra (info at floss-shop.de), do you have in FLOSS-shop tools to test such a card? I could send it over to you. The situation is not very problematic because I have the same passord-store in two mobile cellphones with OpenPGP cards too. Thanks matthias -- Matthias Apitz, ? guru at 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. From hfollmann at itcfollmann.com Tue Jun 18 14:34:36 2024 From: hfollmann at itcfollmann.com (Henning Follmann) Date: Tue, 18 Jun 2024 08:34:36 -0400 Subject: OpenPGP card or USB dongle uTrust stopped working In-Reply-To: References: Message-ID: On Tue, Jun 18, 2024 at 01:30:13PM +0200, Matthias Apitz wrote: > > Hello, > > I do use since "ages" an OpenPGP card in an USB dongle "uTrust 3512" > with GnuPG, mostly for the password-store. Today, from one minute to the > other it stopped working. On attach the uTrust shows up fine in > /var/log/messages with: > > Jun 18 13:08:52 c720-1400094 kernel: ugen0.4: at usbus0 > > but when I access the card, the message is: > > $ gpg2 --card-status > gpg: selecting card failed: Operation not supported by device > gpg: OpenPGP card not available: Operation not supported by device > > and the LEDs on the dongle keep flickering for some seconds (even after > the message is already printed). > > How can I detect if the problem is the SIM-card or the USB dongle? The > problem is in both USB ports of my laptop, that's why I would say, the > ports are fine. > > Petra (info at floss-shop.de), do you have in FLOSS-shop tools to test such > a card? I could send it over to you. > > The situation is not very problematic because I have the same > passord-store in two mobile cellphones with OpenPGP cards too. > > Thanks > > matthias > Hello, if I remember correctly you do have a Librem 5. By any chance the card reader in there is the same size? -H -- Henning Follmann | hfollmann at itcfollmann.com From guru at unixarea.de Tue Jun 18 14:51:36 2024 From: guru at unixarea.de (Matthias Apitz) Date: Tue, 18 Jun 2024 14:51:36 +0200 Subject: OpenPGP card or USB dongle uTrust stopped working In-Reply-To: References: Message-ID: El d?a martes, junio 18, 2024 a las 08:34:36 -0400, Henning Follmann escribi?: > On Tue, Jun 18, 2024 at 01:30:13PM +0200, Matthias Apitz wrote: > > > > ... > > > > How can I detect if the problem is the SIM-card or the USB dongle? The > > problem is in both USB ports of my laptop, that's why I would say, the > > ports are fine. > > > > Petra (info at floss-shop.de), do you have in FLOSS-shop tools to test such > > a card? I could send it over to you. > > > > ... > Hello, > if I remember correctly you do have a Librem 5. > By any chance the card reader in there is the same size? Hello, You remember correctly, but the size in the L5 is smaller (nano, I think). matthias -- Matthias Apitz, ? guru at 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. From mm at dorfdsl.de Tue Jun 18 16:09:28 2024 From: mm at dorfdsl.de (Marco Moock) Date: Tue, 18 Jun 2024 16:09:28 +0200 Subject: S/MIME which certificate format In-Reply-To: <20240612213711.178b78da@dorfdsl.de> References: <20240612213711.178b78da@dorfdsl.de> Message-ID: Am 12.06.24 um 21:37 schrieb Marco Moock: > I tried to import it, but it doesn't work. I've now managed to import it in Thunderbird and can send emails, but Claws Mail (using gpg as backend) can't check the cert. [2024-06-18T16:08:52] Protokollierung begonnen [client at fd 4 connected (local)] 4 - 2024-06-18 16:08:56 gpgsm[39608]: enabled debug flags: ipc 4 - 2024-06-18 16:08:56 gpgsm[39608]: enabled compatibility flags: 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> # Home: /home/m/.gnupg 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> # Config: /home/m/.gnupg/gpgsm.conf 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> # DirmngrInfo: /run/user/1000/gnupg/S.dirmngr 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK GNU Privacy Guard's S/M server 2.2.43 ready 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- OPTION display=:0.0 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- OPTION enable-audit-log=1 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- OPTION lc-ctype=de_DE.UTF-8 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- OPTION lc-messages=de_DE.UTF-8 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- # descriptor 41 is in flight 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- INPUT FD --base64 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- # descriptor 41 is in flight 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- MESSAGE FD 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- VERIFY 4 - 2024-06-18 16:08:56 gpgsm[39608]: detached signature 4 - 2024-06-18 16:08:56 gpgsm[39608]: ksba_cms_parse failed: Ung?ltiges CMS Objekt 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> S ERROR verify.leave 150995088 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> ERR 150995088 Ung?ltiges CMS Objekt 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 <- BYE 4 - 2024-06-18 16:08:56 gpgsm[39608]: DBG: chan_43 -> OK closing connection [client at fd 4 disconnected] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4751 bytes Desc: Kryptografische S/MIME-Signatur URL: From guru at unixarea.de Tue Jun 18 17:00:06 2024 From: guru at unixarea.de (Matthias Apitz) Date: Tue, 18 Jun 2024 17:00:06 +0200 Subject: OpenPGP card or USB dongle uTrust stopped working In-Reply-To: References: Message-ID: El d?a martes, junio 18, 2024 a las 02:51:36 +0200, Matthias Apitz escribi?: > You remember correctly, but the size in the L5 is smaller (nano, I > think). > I used the easy way to check if the culprit is the card or the token: I ordered a new card :-) matthias -- Matthias Apitz, ? guru at 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. From wk at gnupg.org Wed Jun 19 14:14:55 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Jun 2024 14:14:55 +0200 Subject: [Announce] Libgcrypt 1.11.0 released Message-ID: <87le31nn7k.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt version 1.11.0. This release starts a new stable branch of Libgcrypt with full API and ABI compatibility to the 1.10 series. Over the last years Jussi Kivilinna put again a lot of work into speeding up the algorithms for many commonly used CPUs. Niibe-san implemented new APIs and algorithms and also integrated quantum-resistant encryption algorithms. See below for a list of improvements and new features in 1.11. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in Libgcrypt 1.11.0 since 1.10.3 =================================================== * New and extended interfaces: - Add an API for Key Encapsulation Mechanism (KEM). [T6755] - Add Streamlined NTRU Prime sntrup761 algorithm. [rCcf9923e1a5] - Add Kyber algorithm according to FIPS 203 ipd 2023-08-24. [rC18e5c0d268] - Add Classic McEliece algorithm. [rC003367b912] - Add One-Step KDF with hash and MAC. [T5964] - Add KDF algorithm HKDF of RFC-5869. [T5964] - Add KDF algorithm X963KDF for use in CMS. [rC3abac420b3] - Add GMAC-SM4 and Poly1305-SM4. [rCd1ccc409d4] - Add ARIA block cipher algorithm. [rC316c6d7715] - Add explicit FIPS indicators for MD and MAC algorithms. [T6376] - Add support for SHAKE as MGF in RSA. [T6557] - Add gcry_md_read support for SHAKE algorithms. [T6539] - Add gcry_md_hash_buffers_ext function. [T7035] - Add cSHAKE hash algorithm. [rC065b3f4e02] - Support internal generation of IV for AEAD cipher mode. [T4873] * Performance: - Add SM3 ARMv8/AArch64/CE assembly implementation. [rCfe891ff4a3] - Add SM4 ARMv8/AArch64 assembly implementation. [rCd8825601f1] - Add SM4 GFNI/AVX2 and GFI/AVX512 implementation. [rC5095d60af4,rCeaed633c16] - Add SM4 ARMv9 SVE CE assembly implementation. [rC2dc2654006] - Add PowerPC vector implementation of SM4. [rC0b2da804ee] - Optimize ChaCha20 and Poly1305 for PPC P10 LE. [T6006] - Add CTR32LE bulk acceleration for AES on PPC. [rC84f2e2d0b5] - Add generic bulk acceleration for CTR32LE mode (GCM-SIV) for SM4 and Camellia. [rCcf956793af] - Add GFNI/AVX2 implementation of Camellia. [rC4e6896eb9f] - Add AVX2 and AVX512 accelerated implementations for GHASH (GCM) and POLYVAL (GCM-SIV). [rCd857e85cb4, rCe6f3600193] - Add AVX512 implementation for SHA512. [rC089223aa3b] - Add AVX512 implementation for Serpent. [rCce95b6ec35] - Add AVX512 implementation for Poly1305 and ChaCha20 [rCcd3ed49770, rC9a63cfd617] - Add AVX512 accelerated implementation for SHA3 and Blake2 [rCbeaad75f46,rC909daa700e] - Add VAES/AVX2 accelerated i386 implementation for AES. [rC4a42a042bc] - Add bulk processing for XTS mode of Camellia and SM4. [rC32b18cdb87, rCaad3381e93] - Accelerate XTS and ECB modes for Twofish and Serpent. [rCd078a928f5,rC8a1fe5f78f] - Add AArch64 crypto/SHA512 extension implementation for SHA512. [rCe51d3b8330] - Add AArch64 crypto-extension implementation for Camellia. [rC898c857206] - Accelerate OCB authentication on AMD with AVX2. [rC6b47e85d65] * Bug fixes: - For PowerPC check for missing optimization level for vector register usage. [T5785] - Fix EdDSA secret key check. [T6511] - Fix decoding of PKCS#1-v1.5 and OAEP padding. [rC34c2042792] - Allow use of PKCS#1-v1.5 with SHA3 algorithms. [T6976] - Fix AESWRAP padding length check. [T7130] * Other: - Allow empty password for Argon2 KDF. [rCa20700c55f] - Various constant time operation imporvements. - Add "bp256", "bp384", "bp512" aliases for Brainpool curves. - Support for the random server has been removed. [T5811] - The control code GCRYCTL_ENABLE_M_GUARD is deprecated and not supported any more. Please use valgrind or other tools. [T5822] - Logging is now done via the libgpg-error logging functions. [rCab0bdc72c7] * Interface changes relative to the 1.10.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_CIPHER_ARIA128 NEW cipher algo. GCRY_CIPHER_ARIA192 NEW cipher algo. GCRY_CIPHER_ARIA256 NEW cipher algo. gcry_cipher_geniv_methods NEW type. gcry_cipher_setup_geniv NEW function. gcry_cipher_geniv NEW function. GCRY_PK_KEM NEW constant. GCRY_MD_CSHAKE128 NEW hash algo. GCRY_MD_CSHAKE256 NEW hash algo. GCRYCTL_MD_CUSTOMIZE NEW control code. gcry_cshake_customization NEW type. GCRY_MAC_CMAC_ARIA NEW mac algo. GCRY_MAC_GMAC_SM4 NEW mac algo. GCRY_MAC_GMAC_ARIA NEW mac algo. GCRY_MAC_POLY1305_SM4 NEW mac algo. GCRY_MAC_POLY1305_ARIA NEW mac algo. GCRY_KDF_ONESTEP_KDF NEW kdf algo. GCRY_KDF_ONESTEP_KDF_MAC NEW kdf algo. GCRY_KDF_X963_KDF NEW kdf algo. gcry_kem_algos NEW type. gcry_kem_keypair NEW function. gcry_kem_encap NEW function. gcry_kem_decap NEW function. GCRY_KEM_SNTRUP761 NEW kem algo. GCRY_KEM_CM6688128F NEW kem algo. GCRY_KEM_MLKEM512 NEW kem algo. GCRY_KEM_MLKEM768 NEW kem algo. GCRY_KEM_MLKEM1024 NEW kem algo. GCRY_KEM_RAW_X25519 NEW kem algo. GCRY_KEM_RAW_X448 NEW kem algo. GCRY_KEM_RAW_BP256 NEW kem algo. GCRY_KEM_RAW_BP384 NEW kem algo. GCRY_KEM_RAW_BP512 NEW kem algo. GCRY_KEM_RAW_P256R1 NEW kem algo. GCRY_KEM_RAW_P384R1 NEW kem algo. GCRY_KEM_RAW_P521R1 NEW kem algo. GCRY_KEM_DHKEM25519 NEW kem algo. GCRY_KEM_DHKEM448 NEW kem algo. GCRY_KEM_DHKEMP256R1 NEW kem algo. GCRY_KEM_DHKEMP384R1 NEW kem algo. GCRY_KEM_DHKEMP521R1 NEW kem algo. GCRY_KEM_*_SECKEY_LEN NEW constants. GCRY_KEM_*_PUBKEY_LEN NEW constants. GCRY_KEM_*_ENCAPS_LEN NEW constants. GCRY_KEM_*_CIPHER_LEN NEW constants. GCRY_KEM_*_SHARED_LEN NEW constants. gcry_md_hash_buffers_ext NEW function. gcry_pk_input_data_push NEW macro. GCRYCTL_ENABLE_M_GUARD DEPRECATED feature. gcry_handler_log_t DEPRECATED type. gcry_set_log_handler DEPRECATED function. For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T7165 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.0.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.0.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.0.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.0.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.11.0.tar.bz2 you would use this command: gpg --verify libgcrypt-1.11.0.tar.bz2.sig libgcrypt-1.11.0.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. - If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file libgcrypt-1.11.0.tar.bz2, you run the command like this: sha1sum libgcrypt-1.11.0.tar.bz2 and check that the output matches the first line from the this list: dd2c68e0685bb99249efeeb06046fae15b5214ba libgcrypt-1.11.0.tar.bz2 07737e642eedacbda04e7a1f44c04f3cf8e280b8 libgcrypt-1.11.0.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T7165 for updated information. Please also consult the archive of the gcrypt-devel mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html . We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html . Please see https://gnupg.org/documentation/security.html for information on how to report security issues and for our threat model. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have now established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helping with donations. *Thank you all* Your Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Jun 19 16:30:12 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Jun 2024 16:30:12 +0200 Subject: S/MIME which certificate format In-Reply-To: (Marco Moock's message of "Tue, 18 Jun 2024 16:09:28 +0200") References: <20240612213711.178b78da@dorfdsl.de> Message-ID: <87h6dpngy3.fsf@jacob.g10code.de> Hi > 4 - 2024-06-18 16:08:56 gpgsm[39608]: ksba_cms_parse failed: > Ung?ltiges CMS Objekt Please send me such a non-parseable message/data by private mail. No HTML parts or ZIP files, just gzip the message. Which version of GnuPG are you using: gpgsm --version also shows the libksba version. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From bernhard at intevation.de Thu Jun 20 11:07:00 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jun 2024 11:07:00 +0200 Subject: S/MIME which certificate format In-Reply-To: <202406180844.08715.bernhard@intevation.de> References: <20240612213711.178b78da@dorfdsl.de> <20240617192735.111043ec@dorfdsl.de> <202406180844.08715.bernhard@intevation.de> Message-ID: <202406201107.10113.bernhard@intevation.de> Hi Marco, hi Werner, Am Dienstag 18 Juni 2024 08:44:00 schrieb Bernhard Reiter via Gnupg-users: > > I can send you mine if you would like to test. > > At least I can try to import it and see what my version says. did a test with Gpg4win, which print a different error message: gpg (GnuPG) 2.4.5 libgcrypt 1.10.3 gpgsm --debug-all --import zert.crt gpgsm: can't get authorityInfoAccess: No value gpgsm: issuer certificate (#/CN=Sectigo RSA Client Authentication and Secure Email CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB) not found gpgsm: DBG: [no clock] keydb_insert_cert: enter (hd=0x006c3e38) Oops, ksba_cert_get_image failed: imagelen=238 hdr=4 len=1523 off=0 gpgsm: DBG: [no clock] keydb_insert_cert: leave (err=General error) gpgsm: error storing certificate: General error gpgsm: DBG: [no clock] keydb_release: enter (hd=0x006c3e38) gpgsm: DBG: [no clock] keydb_release: leave gpgsm: error storing certificate gpgsm: no issuer found in certificate gpgsm: basic certificate checks failed - not imported gpgsm: total number processed: 2 Marco, it makes sense to mail that certificate to Werner as well, he is fastest to see where the error messages comes from. Thanks 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From mm at dorfdsl.de Thu Jun 20 11:20:14 2024 From: mm at dorfdsl.de (Marco Moock) Date: Thu, 20 Jun 2024 11:20:14 +0200 Subject: S/MIME which certificate format In-Reply-To: <202406201107.10113.bernhard@intevation.de> References: <20240612213711.178b78da@dorfdsl.de> <20240617192735.111043ec@dorfdsl.de> <202406180844.08715.bernhard@intevation.de> <202406201107.10113.bernhard@intevation.de> Message-ID: <20240620112014.4cdd46c4@dorfdsl.de> Hello! Am 20.06.2024 um 11:07:00 Uhr schrieb Bernhard Reiter via Gnupg-users: > gpgsm --debug-all --import zert.crt > > gpgsm: can't get authorityInfoAccess: No value > gpgsm: issuer certificate (#/CN=Sectigo RSA Client Authentication and > Secure Email CA,O=Sectigo Limited,L=Salford,ST=Greater > Manchester,C=GB) not found IIRC the file I sent was only my cert, not the intermediate from the CA. My cert itself creates the problem, the separate CA intermediate cert can be imported properly. I just separated that to track down the issue, which seems to be related to the end user certificate itself. > gpgsm: DBG: [no clock] keydb_insert_cert: enter (hd=0x006c3e38) > Oops, ksba_cert_get_image failed: imagelen=238 hdr=4 len=1523 off=0 > > gpgsm: DBG: [no clock] keydb_insert_cert: leave (err=General error) > gpgsm: error storing certificate: General error > gpgsm: DBG: [no clock] keydb_release: enter (hd=0x006c3e38) > gpgsm: DBG: [no clock] keydb_release: leave > gpgsm: error storing certificate > > gpgsm: no issuer found in certificate > > gpgsm: basic certificate checks failed - not imported > gpgsm: total number processed: 2 > > Marco, it makes sense to mail that certificate to Werner as well, > he is fastest to see where the error messages comes from. I've done that. If anybody else would like to have it for testing purposes, please let me know. -- Gru? Marco From bernhard at intevation.de Thu Jun 20 12:29:17 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jun 2024 12:29:17 +0200 Subject: S/MIME which certificate format In-Reply-To: <20240620112014.4cdd46c4@dorfdsl.de> References: <20240612213711.178b78da@dorfdsl.de> <202406201107.10113.bernhard@intevation.de> <20240620112014.4cdd46c4@dorfdsl.de> Message-ID: <202406201229.17576.bernhard@intevation.de> Am Donnerstag 20 Juni 2024 11:20:14 schrieb Marco Moock: > My cert itself creates the problem, the separate CA intermediate > cert can be imported properly. I've figured and included the lines for additional context only. :) -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Jun 20 12:45:53 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jun 2024 12:45:53 +0200 Subject: GNU Privacy Handbook typo In-Reply-To: References: Message-ID: <202406201246.02946.bernhard@intevation.de> Hi Patrick, Am Freitag 07 Juni 2024 12:25:58 schrieb Patrick F. Marques via Gnupg-users: > I believe there is a ?tiny? typo in this page > https://www.gnupg.org/gph/en/manual/x334.html > I believe it should be ?their key? instead of ?they key? thanks for reporting! > 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. Yes, this is an outdated hint and I guess there will be much more outdated as well regarding the GPH. I've checked https://www.gnupg.org/documentation/guides.html to find the source code repository, but I cannot easily find it on https://git.gnupg.org/cgi-bin/gitweb.cgi so I do not even know where the source code for it is today. We probably should label it outdated or old or so, to warn more users that some information could be outdated. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jun 20 15:15:38 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Jun 2024 15:15:38 +0200 Subject: S/MIME which certificate format In-Reply-To: (Marco Moock's message of "Tue, 18 Jun 2024 16:09:28 +0200") References: <20240612213711.178b78da@dorfdsl.de> Message-ID: <87msnfn4at.fsf@jacob.g10code.de> Hi! your certificate is the first I have seen with empty Subject but a an altSubjectName. This is valid but not yet supported. Tracked at https://dev.gnupg.org/T7171 Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mm at dorfdsl.de Thu Jun 20 15:50:43 2024 From: mm at dorfdsl.de (Marco Moock) Date: Thu, 20 Jun 2024 15:50:43 +0200 Subject: S/MIME which certificate format In-Reply-To: <87msnfn4at.fsf@jacob.g10code.de> References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> Message-ID: <20240620155043.026ba71e@dorfdsl.de> Hello Werner! Am 20.06.2024 um 15:15:38 Uhr schrieb Werner Koch: > your certificate is the first I have seen with empty Subject but a an > altSubjectName. This is valid but not yet supported. > > Tracked at https://dev.gnupg.org/T7171 Thanks for finding that out. Is that triggered by the csr I used or by Sectigo? I've attached it and openssl lists a Subject: line for the csr there that sounds reasonable for me. -- Gru? Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: sectigo.csr Type: application/pkcs10 Size: 1785 bytes Desc: not available URL: From buo.ren.lin at gmail.com Thu Jun 20 14:57:26 2024 From: buo.ren.lin at gmail.com (=?UTF-8?B?5p6X5Y2a5LuBQnVvLXJlbiwgTGlu?=) Date: Thu, 20 Jun 2024 20:57:26 +0800 Subject: GnuPG Development Hub account request Message-ID: Hello, I would like to request a new account for filing a document issue. Here are the account details: "brlin", "???(Buo-ren, Lin)", "buo.ren.lin at gmail.com" Thanks, ???(Buo-ren, Lin) buo.ren.lin at gmail.com From wk at gnupg.org Thu Jun 20 19:13:21 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Jun 2024 19:13:21 +0200 Subject: GnuPG Development Hub account request In-Reply-To: (=?utf-8?B?Iuael+WNmuS7gUJ1by1yZW4s?= Lin via Gnupg-users"'s message of "Thu, 20 Jun 2024 20:57:26 +0800") References: Message-ID: <878qyzmtam.fsf@jacob.g10code.de> On Thu, 20 Jun 2024 20:57, ???Buo-ren, Lin said: > Hello, I would like to request a new account for filing a document > issue. Here are the account details: Created - you need to confirm the mail address, though. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From guru at unixarea.de Fri Jun 21 14:56:13 2024 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 21 Jun 2024 14:56:13 +0200 Subject: OpenPGP card or USB dongle uTrust stopped working In-Reply-To: References: Message-ID: El d?a martes, junio 18, 2024 a las 05:00:06p. m. +0200, Matthias Apitz escribi?: > El d?a martes, junio 18, 2024 a las 02:51:36 +0200, Matthias Apitz escribi?: > > > You remember correctly, but the size in the L5 is smaller (nano, I > > think). > > > > I used the easy way to check if the culprit is the card or the token: I > ordered a new card :-) The new card arrived and first did not worked either with gpg2 --card-status Then I realized that the token is a bit open where the card is sitting, i.e. the two parts of the token are not attached firmly and perhaps the card has not enough contact. When I press the two parts together, it works and I can uncrypt passwords. I will order a new uTrust token. Thread closed matthias -- Matthias Apitz, ? guru at 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. From Brian.Inglis at SystematicSW.ab.ca Sat Jun 22 19:01:40 2024 From: Brian.Inglis at SystematicSW.ab.ca (Brian Inglis) Date: Sat, 22 Jun 2024 11:01:40 -0600 Subject: Americas Mirror {ftp.,www.,}gnupg.ca Down In-Reply-To: References: Message-ID: <90e4311e-1138-4212-9589-73d2160a25f2@SystematicSW.ab.ca> Hi folks, I noticed the Gnu/PG libgcrypt release announcement. So I went to gnupg.org to remind myself of the mirrors and onto gnupg.ca to check download availability. I found I could not access any GnuPG.ca host using any protocol with any browser or tool, including curl, wget&/2, lynx: DNS resolution appears to be working, but I get no response even to just header requests from any URI. Using geoiplookup reports gnupg.ca hosted via AS5645 TEKSAVVY and whois reports teksavvy.com in Chatham, ON, CA which appears to be up. I also checked on 3rd party site checkers and they have no access either. I initially sent a message to ftpmaster, but saw no response or change. I hope this is just some server or network glitch, but I find this concerning as gnupg.ca is the only mirror in the Americas, and with the recent outage of FSF.org, I am concerned whether some bad actors may be trying to block access to FOSS security updates. That may be a paranoid view but to be concerned about security requires it! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien ? ajouter not when there is no more to add mais lorsqu'il n'y a plus rien ? retirer but when there is no more to cut -- Antoine de Saint-Exup?ry From collin.funk1 at gmail.com Sun Jun 23 01:43:47 2024 From: collin.funk1 at gmail.com (Collin Funk) Date: Sat, 22 Jun 2024 16:43:47 -0700 Subject: dev.gnupg.org account request Message-ID: <901248c0-47f2-4ec9-abf8-46c73b077e12@gmail.com> Hi, Can someone please approve my account? Handle: collinfunk Shown name: Collin Funk Mail address: collin.funk1 at gmail.com Thanks, Collin From deceroadiez at gmx.es Sun Jun 23 11:26:53 2024 From: deceroadiez at gmx.es (Nombre y Apellidos) Date: Sun, 23 Jun 2024 11:26:53 +0200 Subject: Restructure Keys. In-Reply-To: <10480069.nUPlyArG6x@daneel> References: <6b0fcaa6-d48f-97b8-edb5-fb679e0f5f44@raghavgururajan.name> <10480069.nUPlyArG6x@daneel> Message-ID: <69fd9cb1bd4f9d016f26fc53e8eaad7d2791b90b.camel@gmx.es> El mi?, 05-06-2024 a las 21:43 +0200, Ingo Kl?cker escribi?: > > 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. > > > The major caveat is I'll have to update the fingerprint of signing > > key > > at multiple places. > > Not really. At least not for gpg because gpg will automatically use > the newest > signing (sub)key for signing data (unless you specified the signing > key with > trailing exclamation mark). I suppose that in any case is needed to "redistribute" the public part of the new settings, in order to be verified by the receiver, isn't it? Regards > > Regards, > Ingo -- OpenPGP fingerprint ------------------- CBA7 480A 5FBC DB67 857F 54D3 434C 945C 1278 2FD7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From deceroadiez at gmx.es Sun Jun 23 11:30:46 2024 From: deceroadiez at gmx.es (Nombre y Apellidos) Date: Sun, 23 Jun 2024 11:30:46 +0200 Subject: Restructure Keys. In-Reply-To: <87frtqvbrq.fsf@jacob.g10code.de> References: <6b0fcaa6-d48f-97b8-edb5-fb679e0f5f44@raghavgururajan.name> <10480069.nUPlyArG6x@daneel> <87frtqvbrq.fsf@jacob.g10code.de> Message-ID: <394d240daab65911fb3ec58cc7278a9a135081e8.camel@gmx.es> El jue, 06-06-2024 a las 08:14 +0200, Werner Koch via Gnupg-users escribi?: > 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. Very interesting. Why is hidden? will be in the future removed or consolidated as "normal" option? Regards > > > Salam-Shalom, > > ?? Werner > -- OpenPGP fingerprint ------------------- CBA7 480A 5FBC DB67 857F 54D3 434C 945C 1278 2FD7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From cole.mickens at gmail.com Fri Jun 28 02:48:58 2024 From: cole.mickens at gmail.com (Cole Mickens) Date: Thu, 27 Jun 2024 18:48:58 -0600 Subject: Revisiting Windows ARM Support Message-ID: Hi, has anyone testing GnuPG on the new Snapdragon X Elite laptops? As far as I know, gnupg on Linux has no issues compiling for ARM, but I know there is an open issue for arm64 builds of gnupg for windows (https://dev.gnupg.org/T5342). I don't know whether the x86 emulation would work, given that scdaemon presumably has some hardware/driver component and I know those don't play nice with the emulator. Plus, it would be great to simply have a native build for such a critical daily software. Of course, I hope this is moot soon, when devicetrees are stabilized for these devices, but in the meantime, the increased portability means I'm considering using Windows as a stop-gap. Thanks for your efforts and attention.