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: <CANHa0z3s45QCwhjyR23wseanHhLh=WwnbkELbn+L=WsDNh9DTw@mail.gmail.com>
 (David Tagatac's message of "Thu, 30 May 2024 19:15:00 -0700")
References: <CANHa0z3s45QCwhjyR23wseanHhLh=WwnbkELbn+L=WsDNh9DTw@mail.gmail.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240603/73d3d994/attachment.sig>

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: <Zlc4XLc2bRIuZidj@oppenheimer.itcfollmann.com>
References: <Zlc4XLc2bRIuZidj@oppenheimer.itcfollmann.com>
Message-ID: <D1R6Y7NQ5XQV.125GOKMMZLWN8@kulbartsch.de>

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 <EMAIL>
  (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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240604/1b7f30b2/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240605/9a06779d/attachment-0001.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240605/9bc8ca70/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240606/4f9e802d/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240606/0901e710/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240606/2243d57c/attachment-0001.html>

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: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>

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 (<jashley at acm.org>), 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240607/3ffdade1/attachment.html>

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: <ZmN4lLmi2YZp3tlB@shelf.conquest>

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: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
References: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
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: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
 <666391BA.8090705@gmail.com>
Message-ID: <ZmPPTWF7q1NrGR6y@sinister.lan.codevat.com>

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: <ZmPPTWF7q1NrGR6y@sinister.lan.codevat.com>
References: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
 <666391BA.8090705@gmail.com> <ZmPPTWF7q1NrGR6y@sinister.lan.codevat.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: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
 <666391BA.8090705@gmail.com>
 <ZmPPTWF7q1NrGR6y@sinister.lan.codevat.com>
 <6663E24C.2020201@gmail.com>
Message-ID: <ZmSC2dgaKPNQ9ncv@sinister.lan.codevat.com>

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: <pEZaqd0B0PQ0-XJw80OUy8ZFOymrWa_KKlxn_jNQpLc4MsKu1niyF9tIyNm96Qi0O2rEwBf_B_rswqoJ9NODCbI8iBjkdKKt7EeSMSaYycw=@proton.me>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240608/3ed1de80/attachment.html>

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: <ZmN4lLmi2YZp3tlB@shelf.conquest> (ael via Gnupg-users's message
 of "Fri, 7 Jun 2024 22:16:04 +0100")
References: <ZmN4lLmi2YZp3tlB@shelf.conquest>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240610/2177fd5a/attachment.sig>

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: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
 <666391BA.8090705@gmail.com>
 <899b818da7d3425e96ff1288de0f49c4@CH0PR08MB7308.namprd08.prod.outlook.com>
Message-ID: <ZmdnOOLjGxDcIit5@iu.edu>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240610/3c2cc340/attachment.sig>

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: <ZmN4lLmi2YZp3tlB@shelf.conquest> <87a5jtthhb.fsf@jacob.g10code.de>
Message-ID: <Zmh44uMrExyXSNXX@shelf.conquest>

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 <GPG
Agent>


-- 
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 <GPG Agent>
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: <ZmN4lLmi2YZp3tlB@shelf.conquest> <87a5jtthhb.fsf@jacob.g10code.de>
Message-ID: <ZmrQlEjGR6Dv-NND@shelf.conquest>

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: <ZmN4lLmi2YZp3tlB@shelf.conquest> <87a5jtthhb.fsf@jacob.g10code.de>
Message-ID: <ZmrSfLoQebeSPlCZ@shelf.conquest>

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: <CAPRjsr-VaOGFSL+ZJX7B33CaqiK=Aw0PWMAcaEx4e4tgopXMwg@mail.gmail.com>

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: <CAPRjsr-VaOGFSL+ZJX7B33CaqiK=Aw0PWMAcaEx4e4tgopXMwg@mail.gmail.com>
References: <CAPRjsr-VaOGFSL+ZJX7B33CaqiK=Aw0PWMAcaEx4e4tgopXMwg@mail.gmail.com>
Message-ID: <Zmro6qNMTNpcCnAK@x270.casa>

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 <key-id>`. 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: <ZmrQlEjGR6Dv-NND@shelf.conquest>
References: <ZmN4lLmi2YZp3tlB@shelf.conquest>
 <87a5jtthhb.fsf@jacob.g10code.de> <ZmrQlEjGR6Dv-NND@shelf.conquest>
Message-ID: <ADVPANXO.FXFNBGQN.ZR4DBGJX@6M4OLQ64.CGPAACNO.JXR2KRLF>

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: <ADVPANXO.FXFNBGQN.ZR4DBGJX@6M4OLQ64.CGPAACNO.JXR2KRLF>
References: <ZmN4lLmi2YZp3tlB@shelf.conquest> <87a5jtthhb.fsf@jacob.g10code.de>
 <ZmrQlEjGR6Dv-NND@shelf.conquest>
 <ADVPANXO.FXFNBGQN.ZR4DBGJX@6M4OLQ64.CGPAACNO.JXR2KRLF>
Message-ID: <ZmtjqHWjNCecZsKC@shelf.conquest>

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: <b7d30dfc-517d-44f9-ac58-33b22f61af43@gmail.com>

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: <Zmro6qNMTNpcCnAK@x270.casa>
References: <Zmro6qNMTNpcCnAK@x270.casa>
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: <b7d30dfc-517d-44f9-ac58-33b22f61af43@gmail.com>
References: <20240612213711.178b78da@dorfdsl.de>
 <b7d30dfc-517d-44f9-ac58-33b22f61af43@gmail.com>
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: <Zmro6qNMTNpcCnAK@x270.casa>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240614/fc0066d1/attachment.sig>

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>
 <b7d30dfc-517d-44f9-ac58-33b22f61af43@gmail.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240614/0a686c7e/attachment.sig>

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>
 <b7d30dfc-517d-44f9-ac58-33b22f61af43@gmail.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240617/079763b0/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240617/b1468480/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240617/c109d6cb/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240617/d4832996/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240617/98ce388d/attachment.obj>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240618/68727645/attachment.sig>

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: <ZnFvxfUP9Z5Rq5_5@c720-1400094>


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: <Identiv uTrust 3512 SAM slot Token> 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: <ZnFvxfUP9Z5Rq5_5@c720-1400094>
References: <ZnFvxfUP9Z5Rq5_5@c720-1400094>
Message-ID: <ZnF-3DwGmYMWXzyq@oppenheimer.itcfollmann.com>

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: <Identiv uTrust 3512 SAM slot Token> 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: <ZnF-3DwGmYMWXzyq@oppenheimer.itcfollmann.com>
References: <ZnFvxfUP9Z5Rq5_5@c720-1400094>
 <ZnF-3DwGmYMWXzyq@oppenheimer.itcfollmann.com>
Message-ID: <ZnGC2PbESmSAcar8@pureos>

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: <f7101932-810c-420d-b5b7-2df412e3ed33@dorfdsl.de>

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 <KSBA>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240618/53340f3d/attachment.bin>

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: <ZnGC2PbESmSAcar8@pureos>
References: <ZnFvxfUP9Z5Rq5_5@c720-1400094>
 <ZnF-3DwGmYMWXzyq@oppenheimer.itcfollmann.com>
 <ZnGC2PbESmSAcar8@pureos>
Message-ID: <ZnGg9qb9AvyUYuYF@pureos>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240619/e1684f1f/attachment-0001.sig>
-------------- 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: <f7101932-810c-420d-b5b7-2df412e3ed33@dorfdsl.de> (Marco Moock's
 message of "Tue, 18 Jun 2024 16:09:28 +0200")
References: <20240612213711.178b78da@dorfdsl.de>
 <f7101932-810c-420d-b5b7-2df412e3ed33@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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240619/af792089/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240620/3231eec0/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240620/86501041/attachment.sig>

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: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
References: <CANigeX3Qtgj=rP8zvMxwJ4oRmBR6UvdeXoCZm=3gKsuMts0Acg@mail.gmail.com>
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 (<jashley at acm.org>), 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240620/f34b3c55/attachment.sig>

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: <f7101932-810c-420d-b5b7-2df412e3ed33@dorfdsl.de> (Marco Moock's
 message of "Tue, 18 Jun 2024 16:09:28 +0200")
References: <20240612213711.178b78da@dorfdsl.de>
 <f7101932-810c-420d-b5b7-2df412e3ed33@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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240620/42a31bb6/attachment.sig>

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>
 <f7101932-810c-420d-b5b7-2df412e3ed33@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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240620/9176b5f3/attachment.bin>

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: <CADyC1h0N7L9C=j9A0Mhjn6PtDGUBQ0uRLv6OWpbG9RUsoRgonQ@mail.gmail.com>

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: <CADyC1h0N7L9C=j9A0Mhjn6PtDGUBQ0uRLv6OWpbG9RUsoRgonQ@mail.gmail.com>
 (=?utf-8?B?Iuael+WNmuS7gUJ1by1yZW4s?= Lin via Gnupg-users"'s message of
 "Thu, 20 Jun 2024 20:57:26 +0800")
References: <CADyC1h0N7L9C=j9A0Mhjn6PtDGUBQ0uRLv6OWpbG9RUsoRgonQ@mail.gmail.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240620/f2bb690c/attachment.sig>

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: <ZnGg9qb9AvyUYuYF@pureos>
References: <ZnFvxfUP9Z5Rq5_5@c720-1400094>
 <ZnF-3DwGmYMWXzyq@oppenheimer.itcfollmann.com>
 <ZnGC2PbESmSAcar8@pureos> <ZnGg9qb9AvyUYuYF@pureos>
Message-ID: <ZnV4bYUr4u1C8Gde@c720-1400094>

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: <cbfed584-72cb-43e7-b1d4-48b333f8271f@SystematicSW.ab.ca>
References: <cbfed584-72cb-43e7-b1d4-48b333f8271f@SystematicSW.ab.ca>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240623/93c49ee5/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240623/dc0607ee/attachment.sig>

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: <CAJ9Gbf0gnWvU1_tu+5zkvPQc7peOPViheP+tcjB8uEt=rX0QvQ@mail.gmail.com>

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.