From 0x66726565 at gmail.com  Tue Nov  2 16:05:30 2021
From: 0x66726565 at gmail.com (Tadeus Prastowo)
Date: Tue, 2 Nov 2021 16:05:30 +0100
Subject: --auto-key-retrieve fails for some keys
Message-ID: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>

Hello,

The signature on a Linux kernel can be verified successfully using
`--auto-key-retrieve', but the signature on an Emacs cannot be
verified in the same manner because gpg is unable to retrieve the
needed public key automatically.

The GPG version is 2.2.19 (libgcrypt 1.8.5, if that matters) as
shipped by Ubuntu 20.04.3.  I manage to locate only one post in the
GnuPG mailing list archive with respect to this `--auto-key-retrieve'
failure.  But, as far as I can see it, the post has no response.

Perhaps one of you can reproduce the problem by the following steps?

1. Test using Linux kernel.
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.tar.xz
https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.tar.sign
unxz < linux-5.11.tar.xz | gpg --keyserver
hkp://keyserver.ubuntu.com:80 --auto-key-retrieve --verify
linux-5.11.tar.sign -

The output of the last command is as follows:
gpg: Signature made Mon 15 Feb 2021 10:11:32 AM CET
gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
gpg: requesting key 38DBBDC86092693E from hkp server keyserver.ubuntu.com
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman
<gregkh at linuxfoundation.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Good signature from "Greg Kroah-Hartman
<gregkh at linuxfoundation.org>" [unknown]
gpg:                 aka "Greg Kroah-Hartman <gregkh at kernel.org>" [unknown]
gpg:                 aka "Greg Kroah-Hartman (Linux kernel stable
release signing key) <greg at kroah.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

2. Test using Emacs.
wget  http://mirror.kumi.systems/gnu/emacs/emacs-27.2.tar.xz.sig
http://mirror.kumi.systems/gnu/emacs/emacs-27.2.tar.xz
cat emacs-27.2.tar.xz  | gpg --keyserver hkp://keyserver.ubuntu.com:80
--auto-key-retrieve --verify emacs-27.2.tar.xz.sig -

The output of the last command is as follows:
gpg: Signature made Thu 25 Mar 2021 12:53:08 PM CET
gpg:                using RSA key 91C1262F01EB8D39
gpg: Can't check signature: No public key

The key 0x91C1262F01EB8D39, however, can be retrieved manually just
fine as shown below:
gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 0x91C1262F01EB8D39
gpg: key 91C1262F01EB8D39: public key "Eli Zaretskii (eliz)
<eliz at gnu.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Any idea why the --auto-key-retrieve feature fails for some keys?

Thank you.

--
Best regards,
Tadeus


From 0x66726565 at gmail.com  Tue Nov  2 17:01:18 2021
From: 0x66726565 at gmail.com (Tadeus Prastowo)
Date: Tue, 2 Nov 2021 17:01:18 +0100
Subject: --auto-key-retrieve fails for some keys
In-Reply-To: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
References: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
Message-ID: <CAA1YtmtDTMM7dK8kFy=DqMQHysLVjne0Qc-3F6mVg7tWz_Z_6w@mail.gmail.com>

On Tue, Nov 2, 2021 at 4:05 PM Tadeus Prastowo <0x66726565 at gmail.com> wrote:
>
> Hello,
>
> The signature on a Linux kernel can be verified successfully using
> `--auto-key-retrieve', but the signature on an Emacs cannot be
> verified in the same manner because gpg is unable to retrieve the
> needed public key automatically.
>
> The GPG version is 2.2.19 (libgcrypt 1.8.5, if that matters) as
> shipped by Ubuntu 20.04.3.  I manage to locate only one post in the
> GnuPG mailing list archive with respect to this `--auto-key-retrieve'
> failure.  But, as far as I can see it, the post has no response.

The post in question is
https://lists.gnupg.org/pipermail/gnupg-users/2019-October/062940.html

> Perhaps one of you can reproduce the problem by the following steps?
>
> 1. Test using Linux kernel.
> wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.tar.xz
> https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.tar.sign
> unxz < linux-5.11.tar.xz | gpg --keyserver
> hkp://keyserver.ubuntu.com:80 --auto-key-retrieve --verify
> linux-5.11.tar.sign -
>
> The output of the last command is as follows:
> gpg: Signature made Mon 15 Feb 2021 10:11:32 AM CET
> gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
> gpg: requesting key 38DBBDC86092693E from hkp server keyserver.ubuntu.com
> gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman
> <gregkh at linuxfoundation.org>" imported
> gpg: Total number processed: 1
> gpg:               imported: 1
> gpg: Good signature from "Greg Kroah-Hartman
> <gregkh at linuxfoundation.org>" [unknown]
> gpg:                 aka "Greg Kroah-Hartman <gregkh at kernel.org>" [unknown]
> gpg:                 aka "Greg Kroah-Hartman (Linux kernel stable
> release signing key) <greg at kroah.com>" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E
>
> 2. Test using Emacs.
> wget  http://mirror.kumi.systems/gnu/emacs/emacs-27.2.tar.xz.sig
> http://mirror.kumi.systems/gnu/emacs/emacs-27.2.tar.xz
> cat emacs-27.2.tar.xz  | gpg --keyserver hkp://keyserver.ubuntu.com:80
> --auto-key-retrieve --verify emacs-27.2.tar.xz.sig -
>
> The output of the last command is as follows:
> gpg: Signature made Thu 25 Mar 2021 12:53:08 PM CET
> gpg:                using RSA key 91C1262F01EB8D39
> gpg: Can't check signature: No public key
>
> The key 0x91C1262F01EB8D39, however, can be retrieved manually just
> fine as shown below:
> gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 0x91C1262F01EB8D39
> gpg: key 91C1262F01EB8D39: public key "Eli Zaretskii (eliz)
> <eliz at gnu.org>" imported
> gpg: Total number processed: 1
> gpg:               imported: 1
>
> Any idea why the --auto-key-retrieve feature fails for some keys?
>
> Thank you.
>
> --
> Best regards,
> Tadeus


From kloecker at kde.org  Tue Nov  2 18:18:43 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Tue, 02 Nov 2021 18:18:43 +0100
Subject: --auto-key-retrieve fails for some keys
In-Reply-To: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
References: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
Message-ID: <5102619.cuLIY8HvmI@daneel>

On Dienstag, 2. November 2021 16:05:30 CET Tadeus Prastowo via Gnupg-users 
wrote:
> The signature on a Linux kernel can be verified successfully using
> `--auto-key-retrieve', but the signature on an Emacs cannot be
> verified in the same manner because gpg is unable to retrieve the
> needed public key automatically.

The important difference is:
> gpg: Signature made Mon 15 Feb 2021 10:11:32 AM CET
> gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
-> fingerprint of signing key
> gpg: requesting key 38DBBDC86092693E from hkp server keyserver.ubuntu.com

> gpg: Signature made Thu 25 Mar 2021 12:53:08 PM CET
> gpg:                using RSA key 91C1262F01EB8D39
-> (long) key id of signing key
> gpg: Can't check signature: No public key

man gpg tells us:
=====
       --auto-key-retrieve
       --no-auto-key-retrieve
              These  options  enable  or disable the automatic retrieving of 
keys from a keyserver when verifying signatures made by
              keys that are not on the local keyring.  The default is --no-
auto-key-retrieve.

              The order of methods tried to lookup the key is:
[...]
              5.  If  any keyserver is configured and the Issuer Fingerprint 
is part of the signature (since GnuPG 2.1.16), the con-
              figured keyservers are tried.
=====

The signature on the Linux kernel contains the Issuer Fingerprint. The 
signature on Emacs doesn't (probably because a very old version of GnuPG is 
used to sign Emacs).

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/20211102/7f484327/attachment.sig>

From wk at gnupg.org  Tue Nov  2 18:34:16 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 02 Nov 2021 18:34:16 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <YX1NnazggvXUBBSb@c720-r368166> (Matthias Apitz's message of
 "Sat, 30 Oct 2021 15:50:21 +0200")
References: <YX1NnazggvXUBBSb@c720-r368166>
Message-ID: <87mtmmqx5z.fsf@wheatstone.g10code.de>

On Sat, 30 Oct 2021 15:50, Matthias Apitz said:

> I just withdraw the USB dongle after the operation. I was thinking that
> the gpg-agent.conf entry 'max-cache-ttl' will also expire the unlocked
> state of the OpenPGP card, which it does not. How could I do this? 

No, it does not because it is the decision of the card how long the
VERIFY command send to the card allows the use of the key.  For most
cards and keys the keys are unlocked by VERIFY until the card is powered
down.  The OpenPGP cards allow to limit the VERIFY command for the first
key to one signing operation ("forcesig" toggles this).

As a workaround use "gpgconf --reload scdaemon" to power down the card.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211102/ff0f9522/attachment-0001.sig>

From gnupg-users at spodhuis.org  Tue Nov  2 18:35:01 2021
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Tue, 2 Nov 2021 13:35:01 -0400
Subject: --auto-key-retrieve fails for some keys
In-Reply-To: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
References: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
Message-ID: <YYF2xays8Yp5lGqV@fullerene.field.pennock-tech.net>

On 2021-11-02 at 16:05 +0100, Tadeus Prastowo via Gnupg-users wrote:
> The signature on a Linux kernel can be verified successfully using
> `--auto-key-retrieve', but the signature on an Emacs cannot be
> verified in the same manner because gpg is unable to retrieve the
> needed public key automatically.

> Any idea why the --auto-key-retrieve feature fails for some keys?

% gpg --list-packets < emacs-27.2.tar.xz.sig
# off=0 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid 91C1262F01EB8D39
	version 4, created 1616673188, md5len 0, sigclass 0x00
	digest algo 2, begin of digest 77 61
	hashed subpkt 2 len 4 (sig created 2021-03-25)
	subpkt 16 len 8 (issuer key ID 91C1262F01EB8D39)
	data: [2048 bits]

% gpg --list-packets < linux-5.11.tar.sign
# off=0 ctb=89 tag=2 hlen=3 plen=563
:signature packet: algo 1, keyid 38DBBDC86092693E
	version 4, created 1613380292, md5len 0, sigclass 0x00
	digest algo 8, begin of digest dc ca
	hashed subpkt 33 len 21 (issuer fpr v4 647F28654894E3BD457199BE38DBBDC86092693E)
	hashed subpkt 2 len 4 (sig created 2021-02-15)
	subpkt 16 len 8 (issuer key ID 38DBBDC86092693E)
	data: [4096 bits]

The shorter keyids are known to be spoofable if someone is willing to
put enough effort into repeatedly generating keys.  So I can well
believe that without the full issuer fingerprint, gpg declines to
automatically retrieve the key.

The only key I can find for 91C1262F01EB8D39 claims to have been made in
2020 and yet is using SHA1 for the self-signature.  That is worrying.

-Phil


From wk at gnupg.org  Tue Nov  2 20:26:07 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 02 Nov 2021 20:26:07 +0100
Subject: What are the file in ~/.gnupg ?
In-Reply-To: <20211029232040.b6v5wqudryinr2nx@dynein.local.incenp.org> (Damien
 Goutte-Gattat via Gnupg-users's message of "Sat,
 30 Oct 2021 00:20:40 +0100")
References: <20211029140411.niqb7apf35gh7y5b@aeredrenLaptop>
 <20211029232040.b6v5wqudryinr2nx@dynein.local.incenp.org>
Message-ID: <87ilxaqrzk.fsf@wheatstone.g10code.de>

On Sat, 30 Oct 2021 00:20, Damien Goutte-Gattat said:

> Private key only. I believe the purely ?mathematical? components of
> the public key can be derived from it (though I may be wrong here),

That is right.  Since some releases we also record the creation date of
the key so that we can easily derive the OpenPGP fingerprint.  Without
that creation time we would need to loop over all seconds since about
1997 to figure out the fingerprint.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211102/786db90e/attachment.sig>

From neal at walfield.org  Tue Nov  2 21:21:13 2021
From: neal at walfield.org (Neal H. Walfield)
Date: Tue, 02 Nov 2021 21:21:13 +0100
Subject: --auto-key-retrieve fails for some keys
In-Reply-To: <YYF2xays8Yp5lGqV@fullerene.field.pennock-tech.net>
References: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
 <YYF2xays8Yp5lGqV@fullerene.field.pennock-tech.net>
Message-ID: <87a6imb96u.wl-neal@walfield.org>

On Tue, 02 Nov 2021 18:35:01 +0100,
Phil Pennock via Gnupg-users wrote:
> On 2021-11-02 at 16:05 +0100, Tadeus Prastowo via Gnupg-users wrote:
> > The signature on a Linux kernel can be verified successfully using
> > `--auto-key-retrieve', but the signature on an Emacs cannot be
> > verified in the same manner because gpg is unable to retrieve the
> > needed public key automatically.
> 
> > Any idea why the --auto-key-retrieve feature fails for some keys?
> 
> % gpg --list-packets < emacs-27.2.tar.xz.sig
> # off=0 ctb=89 tag=2 hlen=3 plen=284
> :signature packet: algo 1, keyid 91C1262F01EB8D39
> 	version 4, created 1616673188, md5len 0, sigclass 0x00
> 	digest algo 2, begin of digest 77 61
> 	hashed subpkt 2 len 4 (sig created 2021-03-25)
> 	subpkt 16 len 8 (issuer key ID 91C1262F01EB8D39)
> 	data: [2048 bits]
> 
> % gpg --list-packets < linux-5.11.tar.sign
> # off=0 ctb=89 tag=2 hlen=3 plen=563
> :signature packet: algo 1, keyid 38DBBDC86092693E
> 	version 4, created 1613380292, md5len 0, sigclass 0x00
> 	digest algo 8, begin of digest dc ca
> 	hashed subpkt 33 len 21 (issuer fpr v4 647F28654894E3BD457199BE38DBBDC86092693E)
> 	hashed subpkt 2 len 4 (sig created 2021-02-15)
> 	subpkt 16 len 8 (issuer key ID 38DBBDC86092693E)
> 	data: [4096 bits]
> 
> The shorter keyids are known to be spoofable if someone is willing to
> put enough effort into repeatedly generating keys.  So I can well
> believe that without the full issuer fingerprint, gpg declines to
> automatically retrieve the key.

This doesn't make sense to me.  Sure, someone could do a second
pre-image attack on a 64-bit key id.  But, when gpg downloads the bad
certificate and checks the signature, it will consider the signature
bad.  At that point, gpg could just throw the downloaded certificate
away.  But if the signature is good, then gpg can be certain that it
has the right certificate for the signature.  (Whether the certificate
is authentic is another matter, of course.)

:) Neal


From 0x66726565 at gmail.com  Wed Nov  3 04:38:54 2021
From: 0x66726565 at gmail.com (Tadeus Prastowo)
Date: Wed, 3 Nov 2021 04:38:54 +0100
Subject: --auto-key-retrieve fails for some keys
In-Reply-To: <5102619.cuLIY8HvmI@daneel>
References: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
 <5102619.cuLIY8HvmI@daneel>
Message-ID: <CAA1Ytmu17HOAHrn+nQ=Je5aNcgWP3g3fVrvkR3Z8Gt5di=wJ+w@mail.gmail.com>

Hi Ingo!

On Tue, Nov 2, 2021 at 6:42 PM Ingo Kl?cker <kloecker at kde.org> wrote:
[...]
> The signature on the Linux kernel contains the Issuer Fingerprint. The
> signature on Emacs doesn't (probably because a very old version of GnuPG is
> used to sign Emacs).

Thank you very much for giving me a throughout explanation on the
matter.  I really appreciate it.

> Regards,
> Ingo

-- 
Best regards,
Tadeus


From 0x66726565 at gmail.com  Wed Nov  3 04:41:51 2021
From: 0x66726565 at gmail.com (Tadeus Prastowo)
Date: Wed, 3 Nov 2021 04:41:51 +0100
Subject: --auto-key-retrieve fails for some keys
In-Reply-To: <YYF2xays8Yp5lGqV@fullerene.field.pennock-tech.net>
References: <CAA1YtmtTQ-eAL+pEPrq6OhQZNzn=XHV7PXUx1Y-xWsg0VZKPPA@mail.gmail.com>
 <YYF2xays8Yp5lGqV@fullerene.field.pennock-tech.net>
Message-ID: <CAA1YtmtzQLe-ZUf18dRob9JCcZ77=fw3zt8kyzJhdrnq3ixf-w@mail.gmail.com>

Hi Phil!

On Tue, Nov 2, 2021 at 7:23 PM Phil Pennock via Gnupg-users
<gnupg-users at gnupg.org> wrote:

[...]

> The only key I can find for 91C1262F01EB8D39 claims to have been made in
> 2020 and yet is using SHA1 for the self-signature.  That is worrying.

Thank you very much for showing me the difference between the
signature files as well as raising the issue.  I will let the Emacs
maintainer know.

> -Phil

-- 
Best regards,
Tadeus


From guru at unixarea.de  Wed Nov  3 18:55:09 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 3 Nov 2021 18:55:09 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <87mtmmqx5z.fsf@wheatstone.g10code.de>
References: <YX1NnazggvXUBBSb@c720-r368166>
 <87mtmmqx5z.fsf@wheatstone.g10code.de>
Message-ID: <YYLM/dIo+gdsD3XO@c720-r368166>

El d?a martes, noviembre 02, 2021 a las 06:34:16p. m. +0100, Werner Koch via Gnupg-users escribi?:

> On Sat, 30 Oct 2021 15:50, Matthias Apitz said:
> 
> > I just withdraw the USB dongle after the operation. I was thinking that
> > the gpg-agent.conf entry 'max-cache-ttl' will also expire the unlocked
> > state of the OpenPGP card, which it does not. How could I do this? 
> 
> No, it does not because it is the decision of the card how long the
> VERIFY command send to the card allows the use of the key.  For most
> cards and keys the keys are unlocked by VERIFY until the card is powered
> down.  The OpenPGP cards allow to limit the VERIFY command for the first
> key to one signing operation ("forcesig" toggles this).
> 
> As a workaround use "gpgconf --reload scdaemon" to power down the card.
> 


Thanks. As I will use the card in the phone mostly (only) with the pass
command, i've added this to the script to get the card locked after any
usage with pass:

purism at pureos:~$ tail -8 /usr/bin/pass

# power down the OpenPGP card
# guru at unixarea.de
#
gpgconf --reload scdaemon
sleep 2

exit 0

I have now my ~330 passwords always with me, encrypted with an OpenPGP
card, and available without any laptop or USB dongel, just in my phone -- a
big progress.  Thanks to Purism to bring this with the L5 to the Linux world!

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...


From wk at gnupg.org  Thu Nov  4 08:31:08 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 04 Nov 2021 08:31:08 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <YYLM/dIo+gdsD3XO@c720-r368166> (Matthias Apitz's message of
 "Wed, 3 Nov 2021 18:55:09 +0100")
References: <YX1NnazggvXUBBSb@c720-r368166>
 <87mtmmqx5z.fsf@wheatstone.g10code.de> <YYLM/dIo+gdsD3XO@c720-r368166>
Message-ID: <87v918ml6r.fsf@wheatstone.g10code.de>

On Wed,  3 Nov 2021 18:55, Matthias Apitz said:

> card, and available without any laptop or USB dongel, just in my phone -- a
> big progress.  Thanks to Purism to bring this with the L5 to the Linux world!

You mean the Librem5 has indeed a second slot for a smartcard?  I
recently received mine but it is more or less unusable to me.  It even
comes w/o a bluetooth device - at least according to the warning notice
I see - for things I can see because the network setting are not fully
accessible.  It is more or less a brick; the OpenMoko used to be better.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211104/66f5bdfc/attachment.sig>

From guru at unixarea.de  Thu Nov  4 09:40:40 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 4 Nov 2021 09:40:40 +0100
Subject: OpenPGP card and gpg-agent TTL
Message-ID: <YYOciD12i0Lx9cs/@c720-r368166>

El d?a jueves, noviembre 04, 2021 a las 08:31:08a. m. +0100, Werner Koch via Gnupg-users escribi?:

> On Wed,  3 Nov 2021 18:55, Matthias Apitz said:
> 
> > card, and available without any laptop or USB dongel, just in my phone -- a
> > big progress.  Thanks to Purism to bring this with the L5 to the Linux world!
> 
> You mean the Librem5 has indeed a second slot for a smartcard?  I
> recently received mine but it is more or less unusable to me.  It even
> comes w/o a bluetooth device - at least according to the warning notice
> I see - for things I can see because the network setting are not fully
> accessible.  It is more or less a brick; the OpenMoko used to be better.

Hello Werner,

I got mine in early October after exactly 4 years waiting. I do not
share your opinions about the L5. I moved my 100++ contacts from the
Ubuntu phone E4.5 to the L5 (which was a matter of seconds, export to
VCF, SCP over and load; both use the same evolution database for storing
them). I bought a SIM, have Internet via G4 on the road, or Wifi. Both
do fine, Wifi with any access point until now. I can attach a Bluetooth
keyboard with an integrated touchpad. Both work fine, see this foto:
http://www.unixarea.de/l5-with-bt-keyboard.jpg

The slot for the mini OpenPGP card in behind the battery, just
pull the battery out and you will see. I bought the OpenPGP card from
Purism for USD 15, I don't know if the small format exist here in
Germany. Here you have a small video showing the card insert etc.:
https://puri.sm/posts/openpgp-in-your-pocket/

And, I hacked together a Spanish OSK for the terminal app, because I
write a lot in Spanish with a command line telegram client.

I have and have had some Linux mobiles, also the OpenMoko. The
Purism L5 is the most usefull until now for me. You see, I really don't
share your opinion. The biggest problem until now is the duration of the
battery of 8-10 hours, because the phone until now dows not suspend to
RAM. They're working on it...

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...


From guru at unixarea.de  Thu Nov  4 10:13:51 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 4 Nov 2021 10:13:51 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <YYOciD12i0Lx9cs/@c720-r368166>
References: <YYOciD12i0Lx9cs/@c720-r368166>
Message-ID: <YYOkTylgJSgGCi30@c720-r368166>

El d?a jueves, noviembre 04, 2021 a las 09:40:40a. m. +0100, Matthias Apitz escribi?:

> ...
> 
> I have and have had some Linux mobiles, also the OpenMoko. The
> Purism L5 is the most usefull until now for me. You see, I really don't
> share your opinion. The biggest problem until now is the duration of the
> battery of 8-10 hours, because the phone until now dows not suspend to
> RAM. They're working on it...
> 

I forgot to add a joke. The L5 has 3 hardware kill switches, real kill
switches, i.e. the power down is not done by software but by cutting the
electrical power line of the respective chips: 1) the modem or
2) Wifi+Bluetooth or 3) cam+micro.

When I did the first test voice calls to my family at home, nobody could
hear me. Guess why :-)

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...


From andrewg at andrewg.com  Thu Nov  4 10:45:57 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 4 Nov 2021 09:45:57 +0000
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <YYOciD12i0Lx9cs/@c720-r368166>
References: <YYOciD12i0Lx9cs/@c720-r368166>
Message-ID: <6599ac74-11e5-1fc3-ae5a-ef15e2be48cf@andrewg.com>

On 04/11/2021 08:40, Matthias Apitz wrote:
> I bought the OpenPGP card from
> Purism for USD 15, I don't know if the small format exist here in
> Germany.

Not Germany, but Cryptoshop in Vienna sells them:

https://en.cryptoshop.com/products/smartcards/open-pgp-smartcard-v2-id-000.html

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211104/e4642fce/attachment.sig>

From guru at unixarea.de  Thu Nov  4 11:08:00 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 4 Nov 2021 11:08:00 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <6599ac74-11e5-1fc3-ae5a-ef15e2be48cf@andrewg.com>
References: <YYOciD12i0Lx9cs/@c720-r368166>
 <6599ac74-11e5-1fc3-ae5a-ef15e2be48cf@andrewg.com>
Message-ID: <YYOxAIZy6QZHZp2R@c720-r368166>

El d?a jueves, noviembre 04, 2021 a las 09:45:57a. m. +0000, Andrew Gallagher via Gnupg-users escribi?:

> On 04/11/2021 08:40, Matthias Apitz wrote:
> > I bought the OpenPGP card from
> > Purism for USD 15, I don't know if the small format exist here in
> > Germany.
> 
> Not Germany, but Cryptoshop in Vienna sells them:
> 
> https://en.cryptoshop.com/products/smartcards/open-pgp-smartcard-v2-id-000.html
> 

I have the above card for some years in an USB dongle. But the one which
fits in the L5 is smaller:

https://shop.puri.sm/shop/purism-openpgp-card/

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...


From wk at gnupg.org  Fri Nov  5 08:32:17 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 05 Nov 2021 08:32:17 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <YYOciD12i0Lx9cs/@c720-r368166> (Matthias Apitz's message of
 "Thu, 4 Nov 2021 09:40:40 +0100")
References: <YYOciD12i0Lx9cs/@c720-r368166>
Message-ID: <87k0hnjbwe.fsf@wheatstone.g10code.de>

Hi Matthias,

On Thu,  4 Nov 2021 09:40, Matthias Apitz said:

> I got mine in early October after exactly 4 years waiting. I do not

Same here.  I actually met with Todd back then and my colleague Gniibe
write the driver for their planned card reader.  Then we had that long
delay.

it is good that things work for you.  And thanks for the hint with the
smartcard.  I was probably blind that I didn't noticed it.  I put an
older card into the slot (cut down with a sharp wire cutter) but I have
not seen the device.

Even after an OS update there is still no Bluetooth device (regardless
of the kill switch position) and the WLAN sometimes needs a reboot.  I
also wonder why there are no easy accessible teardown images - the long
Youtube video is not very helpful because it shows obvious things,

> I have and have had some Linux mobiles, also the OpenMoko. The
> Purism L5 is the most usefull until now for me. You see, I really don't

As long as you do not count the Jollas in.  Purism's decision to write
yet another software stack is highly questionable.  IMHO they should
have used the free stuff from SFOS and replace the proprietary UI using
Qt instead of GTK+.  That would have solved the battery problems
instantly,


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211105/0d8c8fd5/attachment.sig>

From guru at unixarea.de  Fri Nov  5 09:01:21 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 5 Nov 2021 09:01:21 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <87k0hnjbwe.fsf@wheatstone.g10code.de>
References: <YYOciD12i0Lx9cs/@c720-r368166>
 <87k0hnjbwe.fsf@wheatstone.g10code.de>
Message-ID: <YYTk0QEyA9hCX+oI@c720-r368166>

El d?a viernes, noviembre 05, 2021 a las 08:32:17a. m. +0100, Werner Koch via Gnupg-users escribi?:

> it is good that things work for you.  And thanks for the hint with the
> smartcard.  I was probably blind that I didn't noticed it.  I put an
> older card into the slot (cut down with a sharp wire cutter) but I have
> not seen the device.

Hello Werner,

To get the OpenPGP card working, please follow the steps in my
attachment OpenPGP-L5.txt. You must flash some firmware into the device.

> Even after an OS update there is still no Bluetooth device (regardless
> of the kill switch position) and the WLAN sometimes needs a reboot.  I
> also wonder why there are no easy accessible teardown images - the long
> Youtube video is not very helpful because it shows obvious things,

To solve the Bluetooth / WLAN problems, follow the steps here how to
load again some other firmware. Esp. change also after this in the file
/etc/modprobe.d/librem5-devkit.conf the value dev_oper_mode from 5 to 13

https://forums.puri.sm/t/bluetooth-support-for-librem-5/14965/45

Hope it helps

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...
-------------- next part --------------

How to setup the OpenPGP card in the Purism L5 phone
              guru at unixarea.de, October 2021


https://puri.sm/posts/openpgp-in-your-pocket/
(includes video about inserting the card)

https://source.puri.sm/angus.ainslie/ttxs-firmware/-/blob/purism/PURISM.md

install and get the software:

$ cd ~/guru
$ sudo apt install stm32flash git
$ git clone https://source.puri.sm/angus.ainslie/ttxs-firmware

$ cd ttxs-firmware

Upgrade the smart card reader firmware:

$ ./scripts/stm_reflash.sh

...
stm32flash 0.5

http://stm32flash.sourceforge.net/

Using Parser : Raw BINARY
Interface serial_posix: 57600 8E1
Version      : 0x31
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0435 (STM32L43xxx/44xxx)
- RAM        : Up to 48KiB  (12544b reserved by bootloader)
- Flash      : Up to 256KiB (size first sector: 1x2048)

- Option RAM : 16b
- System RAM : 28KiB
Write to memory
Erasing memory
Wrote address 0x08002388 (100.00%) Done.


And set up the smart card:

$ ./scripts/smartcard_setup.sh

There have been issues, see also:

https://forums.puri.sm/t/openpgp-card-waiting-for-the-first-reader/15189
https://source.puri.sm/Librem5/OS-issues/-/issues/119

What helped was:

# stty -F /dev/ttymxc2 raw cstopb -parenb cs8 115200 
# pcscd -f --debug

The startup of pcscd is to be configured here and start is via systemctl:

# vim /lib/systemd/system/pcscd.service
# systemctl status pcscd
# systemctl stop pcscd
# systemctl start pcscd

Setting up the card

$ gpg --card-status
Reader ...........: TTXS serial 00 00
Application ID ...: D27600012401030400050000A6FE0000
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: ZeitControl
Serial number ....: 0000A6FE
Name of cardholder: [not set]
Language prefs ...: de
Salutation .......: 
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 64 64 64
PIN retry counter : 3 0 3
Signature counter : 0
KDF setting ......: off
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]


$ gpg --change-pin  # changed the PIN and Admin PIN

$ gpg --card-edit   # generated the keys

$ export GNUPGHOME=/home/guru/.gnupg

$ pass init 'CCID L5'
Password store initialized for guru at unixarea.de
$ pass insert -m test
...


$ gpg --with-keygrip -K
/home/purism/.gnupg/pubring.kbx
-------------------------------
sec>  rsa2048 2021-10-30 [SC]
      336EB96892FE9FE7F6AD01D6529B7423F3608141
      Keygrip = FCBA9E53DF1AF8D6E8D82B0418A01FA33264F704
      Card serial no. = 0005 0000A6FE
uid           [ultimate] Matthias Apitz (GnuPG CCID L5) <guru at unixarea.de>
ssb>  rsa2048 2021-10-30 [A]
      Keygrip = EE34E2B1F932D1567A6E21023F4D65B71CF953FF
ssb>  rsa2048 2021-10-30 [E]
      Keygrip = C544F16750F7F55DCEF781CF57C232015DDF1F90

the '>' means that these keys are on the card;

export the pub key with:

$ gpg --export --armor > ccid-L5-export-key-guru.pub


lock the card again:

$ gpgconf --reload scdaemon

I added this to the pass cmd:

$ tail -8 /usr/bin/pass

# power down the OpenPGP card
# guru at unixarea.de
#
gpgconf --reload scdaemon
sleep 2

exit 0

so the card gets loecked again after each operation with the pass cmd.

From guru at unixarea.de  Fri Nov  5 17:30:48 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 5 Nov 2021 17:30:48 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <87k0hnjbwe.fsf@wheatstone.g10code.de>
References: <YYOciD12i0Lx9cs/@c720-r368166>
 <87k0hnjbwe.fsf@wheatstone.g10code.de>
Message-ID: <YYVcOEpJcXxEMgxb@c720-r368166>

Werner,

I have an issue with the 'pinentry' in the L5:

/usr/bin/pinentry is as default a symlink to /etc/alternatives/pinentry
and pops up on the L5 as somekind graphical application, also when I use
the OpenPGP card in the L5 when connected via SSH to the L5, which is
not what I wanted have to key in the PIN in the L5 when im using it via
SSH (and the L5 sits in some other room).

That's why I changed the symlink to point to /usr/bin/pinentry-curses
which works fine via SSH, i.e. the PIN is asked in the terminal where I
run the SSH session.

But, it does not work locally on the L5 in its "terminal app", the
"pass" command in the terminal raises an error about no secret provided.
The "pass" command is just a shell script and uses "gpg" to decrypt the
file containing the requested password for some web access, running
so,ething like:

$GPG -d "${GPG_OPTS[@]}" "$passfile"

What could be the reason for this?

I tried /usr/bin/pinentry-curses in the "terminal app" which does work.

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...


From guru at unixarea.de  Sat Nov  6 12:09:59 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Sat, 6 Nov 2021 12:09:59 +0100
Subject: BT -> mutt -> SMTP -> Wifi
Message-ID: <YYZih5BYWjcRuovc@pureos>

Hello Werner, 

This message is typed on a BT keyboard connected to the L5 and sent 
from mutt on the L5 via SMTP and Wifi to the list while sitting
in the sun in a beergarden.

Only a short example of useability of the L5

	matthias



From wk at gnupg.org  Sun Nov  7 14:14:59 2021
From: wk at gnupg.org (Werner Koch)
Date: Sun, 07 Nov 2021 14:14:59 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <YYVcOEpJcXxEMgxb@c720-r368166> (Matthias Apitz's message of
 "Fri, 5 Nov 2021 17:30:48 +0100")
References: <YYOciD12i0Lx9cs/@c720-r368166>
 <87k0hnjbwe.fsf@wheatstone.g10code.de> <YYVcOEpJcXxEMgxb@c720-r368166>
Message-ID: <87ilx4gl9o.fsf@wheatstone.g10code.de>

On Fri,  5 Nov 2021 17:30, Matthias Apitz said:

> But, it does not work locally on the L5 in its "terminal app", the
> "pass" command in the terminal raises an error about no secret provided.

You did the

 gpg-connect-agent updatestartuptty /bye

thing to tell gpg-agent where it shall pop up the pinentry?  Further
you can debug thing with adding "-v" to the gpg invocation or by letting
gpg-agent create a debug file:

--8<---------------cut here---------------start------------->8---
log-file /foo/bar/gpg-agent.log
verbose
debug ipc
debug-pinentry
--8<---------------cut here---------------end--------------->8---

Or use

log-file tcp://1.2.3.4:40711

and run "watchgnupg --tcp 40711" on the host with IP 1.2.3.4.  Not TLS,
so take care.  But it is convenient to see what's going on.

Thanks for your other mail on thenneed to flush the firmware for the BT
device.  I have not yet found the time to do that, though.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211107/dba6f0fb/attachment.sig>

From wk at gnupg.org  Sun Nov  7 14:17:03 2021
From: wk at gnupg.org (Werner Koch)
Date: Sun, 07 Nov 2021 14:17:03 +0100
Subject: BT -> mutt -> SMTP -> Wifi
In-Reply-To: <YYZih5BYWjcRuovc@pureos> (Matthias Apitz's message of "Sat, 6
 Nov 2021 12:09:59 +0100")
References: <YYZih5BYWjcRuovc@pureos>
Message-ID: <87ee7sgl68.fsf@wheatstone.g10code.de>

On Sat,  6 Nov 2021 12:09, Matthias Apitz said:

> This message is typed on a BT keyboard connected to the L5 and sent 
> from mutt on the L5 via SMTP and Wifi to the list while sitting
> in the sun in a beergarden.

Alright. I eventually need to figure out how to turn my Cosmo
Communicator into a dump BT keyboard for the L5 ;-)


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211107/7c4889e7/attachment.sig>

From stuartl at longlandclan.id.au  Mon Nov  8 05:45:53 2021
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Mon, 8 Nov 2021 14:45:53 +1000
Subject: Using gpgsm+scute with p11tool
Message-ID: <20211108144553.20f70b69@longlandclan.id.au>

Hi all,

I'm trying to get 2FA HTTP client authentication working with a YubiKey
5 hardware token at my workplace.

I currently already have the YubiKey working successfully with GnuPG
2.2 in OpenPGP mode for two-factor SSH authentication and git code
signing.  Aside from a few niggles (like not being able to use two
YubiKeys simultaneously, something GnuPG 2.3 should resolve if I can
get it working right), things have been pretty smooth.

I had `curl` working via OpenSC's PKCS#11 support, but this clashes
with GnuPG, one must re-plug the YubiKey after accessing it via OpenSC,
which gets annoying.  It's been suggested I look at `scute` instead.

The HTTP request I need to perform is this one:
https://www.vaultproject.io/docs/auth/cert#via-the-api

I tried using Firefox, it can see the certificate presented by `scute`,
but it seems Vault isn't designed to authenticate clients that way as
best I can tell.

Using OpenSC PKCS#11, I can do something like this:

$ curl -E 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=<snip>;token=<snip>;id=%07;object=<snip>;type=cert' --insecure --data '{"name": "me"}' https://tls.server.example.com:8200/v1/auth/cert/login

I can see what tokens exist with `p11tool`:

$ p11tool --provider=/usr/lib64/pkcs11/opensc-pkcs11.so --list-tokens
Token 0:
        URL: pkcs11:model=<snip>;token=PIV_II
        Label: PIV_II
        Type: Hardware token
        Flags: RNG, Requires login
        Manufacturer: piv_II
        Model: <snip>
        Serial: <snip>
        Module: 

If I try doing the same with `scute`, I get nothing:

$ p11tool --provider=/usr/lib64/pkcs11/scute.so --list-tokens

Consequently, I have no idea what hardware token URI to supply to
`curl` when authenticating.

Is there some trick needed to get `scute` to tell me what tokens are
present or how to find out what the URL of my private key is?

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


From guru at unixarea.de  Mon Nov  8 11:18:37 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 8 Nov 2021 11:18:37 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <87ilx4gl9o.fsf@wheatstone.g10code.de>
References: <YYOciD12i0Lx9cs/@c720-r368166>
 <87k0hnjbwe.fsf@wheatstone.g10code.de>
 <YYVcOEpJcXxEMgxb@c720-r368166>
 <87ilx4gl9o.fsf@wheatstone.g10code.de>
Message-ID: <YYj5fW4mBysiDaNj@c720-r368166>

El d?a domingo, noviembre 07, 2021 a las 02:14:59p. m. +0100, Werner Koch via Gnupg-users escribi?:

> On Fri,  5 Nov 2021 17:30, Matthias Apitz said:
> 
> > But, it does not work locally on the L5 in its "terminal app", the
> > "pass" command in the terminal raises an error about no secret provided.
> 
> You did the
> 
>  gpg-connect-agent updatestartuptty /bye
> 
> thing to tell gpg-agent where it shall pop up the pinentry?  Further
> ...

Thanks for the hints. Magically it works now by its own after adding
this to the ~purism/.bashrc (the terminal app does not source .profile).

In a SSH session a 'pass test' asks now inline for the PIN and in the
terminal app some Gnome window pops up.

See also:

https://forums.puri.sm/t/terminal-app-purism-profile/15325

Maybe you want subscribe to this forum (if not already done). It's a
pity that Purism uses a "forum" and not a standard mailing-list :-(

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...


From christoph-klassen at mail.de  Mon Nov  8 16:54:35 2021
From: christoph-klassen at mail.de (Christoph Klassen)
Date: Mon, 8 Nov 2021 16:54:35 +0100
Subject: make check -> libgcrypt is too old
Message-ID: <9a4bf613-a54a-a16d-1b69-cee4583cb49c@mail.de>

Hello everyone,


I was trying to build GnuPG 2.3.3. For that reason I downloaded and 
built npth 1.6, libgpg-error 1.43, libgcrypt 1.9.4, libksba 1.6.0 and 
libassuan 2.5.5 (in this order). Then I started the build process for 
GnuPG with ./configure and make && make check. One test failed, saying: 
"t-recsel: Fatal: libgcrypt is too old (need 1.9.1, have 1.8.8)".

Can you please help me?


Greetings,

Christoph




From ostroffjh at users.sourceforge.net  Mon Nov  8 17:28:37 2021
From: ostroffjh at users.sourceforge.net (Jack)
Date: Mon, 08 Nov 2021 11:28:37 -0500
Subject: make check -> libgcrypt is too old
In-Reply-To: <9a4bf613-a54a-a16d-1b69-cee4583cb49c@mail.de>
Message-ID: <LXVHNGJI.QTEVT4MP.CUNC73VD@LBX5L4NZ.RR3G4JAU.OG7FL32Y>

On 2021.11.08 10:54, Christoph Klassen via Gnupg-users wrote:
> 
> I was trying to build GnuPG 2.3.3. For that reason I downloaded and  
> built npth 1.6, libgpg-error 1.43, libgcrypt 1.9.4, libksba 1.6.0 and  
> libassuan 2.5.5 (in this order). Then I started the build process for  
> GnuPG with ./configure and make && make check. One test failed,  
> saying: "t-recsel: Fatal: libgcrypt is too old (need 1.9.1, have  
> 1.8.8)".

Did that happen during ./configure or during make check?  In either  
case, I would check for any left-over remnants of an older install of  
libgcrypt, such as a stray pkcgonfig file.


From christoph-klassen at mail.de  Mon Nov  8 20:30:35 2021
From: christoph-klassen at mail.de (Christoph Klassen)
Date: Mon, 8 Nov 2021 20:30:35 +0100
Subject: make check -> libgcrypt is too old
In-Reply-To: <LXVHNGJI.QTEVT4MP.CUNC73VD@LBX5L4NZ.RR3G4JAU.OG7FL32Y>
References: <LXVHNGJI.QTEVT4MP.CUNC73VD@LBX5L4NZ.RR3G4JAU.OG7FL32Y>
Message-ID: <a566790c-21ca-68b3-c64f-a6cf0e9e38bb@mail.de>

On 08.11.21 17:28, Jack via Gnupg-users wrote:
> In either case, I would check for any left-over remnants of an older 
> install of libgcrypt, such as a stray pkcgonfig file.
I didn't think of old installations, but that was the right clue. On my 
system the package libgcrypt20 was installed (from the debian repos). 
The solution was to run first dpkg --purge --force-all libgcrypt20 
(couldn't remove it the normal way because of some dependencies). Then I 
could build GnuPG without errors. But at least one application didn't 
work, so I reinstalled libgcrypt20. Now both, GnuPG and the other 
application work and everything is fine!



From keine-eile at e-mail.de  Tue Nov  9 15:28:27 2021
From: keine-eile at e-mail.de (Keine Eile)
Date: Tue, 9 Nov 2021 15:28:27 +0100
Subject: gpg: Note: secret key [...] expired...
Message-ID: <7a3830aa-da78-4845-5568-993bdfed7fa9@e-mail.de>

Hi list members,

I have a revoked private key in my key ring, which I replaced with new one. I really do not want to discard this old key, for what I think good reasons. Is there a way to let gpg ignore this key or suppress this this? notification?

1)
> gpg: Note: secret key [KeyID] expired at [Some day in September]
> gpg: Note: key has been revoked


From wk at gnupg.org  Tue Nov  9 17:30:43 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Nov 2021 17:30:43 +0100
Subject: Too many open files caused by repeated decryption operations via
 a GPGME API
In-Reply-To: <c9307d9c-8847-e53f-b507-d50b540d2f62@edgematrix.com> (Kazunori
 Kobayashi's message of "Fri, 29 Oct 2021 16:24:57 +0900")
References: <c9307d9c-8847-e53f-b507-d50b540d2f62@edgematrix.com>
Message-ID: <87fss59tqk.fsf@wheatstone.g10code.de>

On Fri, 29 Oct 2021 16:24, Kazunori Kobayashi said:

> On modern Linux, we can change the maximum number of file descriptors
> per process in some ways. This feature is a well-known way for long
> time operation without reboot in cases such as server machines.

That is a known problem we recently raise the priority of the feature
request https://dev.gnupg.org/T2385 to high.  Thus there is a good
chance that this problem will be solved in the not too distant future.

> https://github.com/gpg/gpgme/blob/gpgme-1.10.0/src/posix-io.c#L673

Please don't refer to github for gnupg; their copy is out of date.  Use
our https://dev.gnupg.org instead.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211109/b0438877/attachment.sig>

From kloecker at kde.org  Tue Nov  9 21:18:40 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Tue, 09 Nov 2021 21:18:40 +0100
Subject: gpg: Note: secret key [...] expired...
In-Reply-To: <7a3830aa-da78-4845-5568-993bdfed7fa9@e-mail.de>
References: <7a3830aa-da78-4845-5568-993bdfed7fa9@e-mail.de>
Message-ID: <2242368.CTkG5fTKkS@breq>

On Dienstag, 9. November 2021 15:28:27 CET Keine Eile wrote:
> I have a revoked private key in my key ring, which I replaced with new one.
> I really do not want to discard this old key, for what I think good
> reasons. Is there a way to let gpg ignore this key or suppress this this?
> notification?
> 
> > gpg: Note: secret key [KeyID] expired at [Some day in September]
> > gpg: Note: key has been revoked

As far as I could see in the source code, this is always printed when you 
decrypt something that was encrypted for this key. There is no option to 
suppress this except maybe by suppressing all informational messages. --quiet 
may help.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211109/4a8fd604/attachment.sig>

From dgouttegattat at incenp.org  Tue Nov  9 23:07:26 2021
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 9 Nov 2021 22:07:26 +0000
Subject: Using gpgsm+scute with p11tool
In-Reply-To: <20211108144553.20f70b69@longlandclan.id.au>
References: <20211108144553.20f70b69@longlandclan.id.au>
Message-ID: <20211109220726.5gsdna2p4qpgcbco@dynein.local.incenp.org>

Hi,

On Mon, Nov 08, 2021 at 02:45:53PM +1000, Stuart Longland via Gnupg-users wrote:
>The HTTP request I need to perform is this one:
>https://www.vaultproject.io/docs/auth/cert#via-the-api
>
>I tried using Firefox, it can see the certificate presented by `scute`,
>but it seems Vault isn't designed to authenticate clients that way as
>best I can tell.

As long as the server allows certificate-based client authentication, it 
shouldn?t matter to the server that you are using Scute (or any other 
way to store your certificate) at your end.

However, usage of Scute + Firefox seems broken with TLS 1.3. In my case, 
it works perfectly fine if I force Firefox to use TLS 1.2 
(security.tls.version.max = 3 in about:config), but systematically fails 
when TLS 1.3 is enabled.

I am not sure about the root cause of the failure with TLS 1.3, or even 
if the root cause is in Scute itself or in Firefox.

Could you try temporarily disable TLS 1.3 and try again? If it works 
with TLS 1.2 only, this would suggest you are running into the same 
problem as me.


>If I try doing the same with `scute`, I get nothing:
>
>$ p11tool --provider=/usr/lib64/pkcs11/scute.so --list-tokens
>
>Consequently, I have no idea what hardware token URI to supply to
>`curl` when authenticating.
>
>Is there some trick needed to get `scute` to tell me what tokens are
>present or how to find out what the URL of my private key is?

I would need to look at how is p11tool generating its output, but I 
suspect it may be using some PKCS#11 functions that Scute does not 
currently implement.

- Damien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211109/5a4b1154/attachment.sig>

From wk at gnupg.org  Wed Nov 10 08:13:18 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 10 Nov 2021 08:13:18 +0100
Subject: make check -> libgcrypt is too old
In-Reply-To: <a566790c-21ca-68b3-c64f-a6cf0e9e38bb@mail.de> (Christoph Klassen
 via Gnupg-users's message of "Mon, 8 Nov 2021 20:30:35 +0100")
References: <LXVHNGJI.QTEVT4MP.CUNC73VD@LBX5L4NZ.RR3G4JAU.OG7FL32Y>
 <a566790c-21ca-68b3-c64f-a6cf0e9e38bb@mail.de>
Message-ID: <874k8ka3g1.fsf@wheatstone.g10code.de>

On Mon,  8 Nov 2021 20:30, Christoph Klassen said:

> repos). The solution was to run first dpkg --purge --force-all
> libgcrypt20 (couldn't remove it the normal way because of some

Not a good idea.  That may break things.  It is better to install
libgcrypt and the other libs to /user/local/lib and then set
LD_LIBRARY_PATH accordingly (or fix search order in ld.so.conf).

> one application didn't work, so I reinstalled libgcrypt20. Now both,

Libgcrypt 1.9 is compatible to 1.8 but not vice versa.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211110/b16a5ab7/attachment.sig>

From wk at gnupg.org  Wed Nov 10 08:22:15 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 10 Nov 2021 08:22:15 +0100
Subject: gpg: Note: secret key [...] expired...
In-Reply-To: <7a3830aa-da78-4845-5568-993bdfed7fa9@e-mail.de> (Keine Eile's
 message of "Tue, 9 Nov 2021 15:28:27 +0100")
References: <7a3830aa-da78-4845-5568-993bdfed7fa9@e-mail.de>
Message-ID: <87zgqc8ogo.fsf@wheatstone.g10code.de>

On Tue,  9 Nov 2021 15:28, Keine Eile said:

> I have a revoked private key in my key ring, which I replaced with new
> one. I really do not want to discard this old key, for what I think
> good reasons. Is there a way to let gpg ignore this key or suppress
> this this? notification?

You can delete your old key from the keyring.  However, you would also
lose the ability to decrypt old messages.  Thus in general not a good
idea.

>> gpg: Note: secret key [KeyID] expired at [Some day in September]
>> gpg: Note: key has been revoked

We can't suppress the latter diagnostic because that is an important
information.  The former diagnostic is also of some interest.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211110/4f9da09a/attachment.sig>

From keine-eile at e-mail.de  Wed Nov 10 08:05:48 2021
From: keine-eile at e-mail.de (Keine Eile)
Date: Wed, 10 Nov 2021 08:05:48 +0100
Subject: gpg: Note: secret key [...] expired...
In-Reply-To: <2242368.CTkG5fTKkS@breq>
References: <7a3830aa-da78-4845-5568-993bdfed7fa9@e-mail.de>
 <2242368.CTkG5fTKkS@breq>
Message-ID: <06c9c006-3c63-cdd0-0259-d357f410468d@e-mail.de>

Thanks for pointing that out

> As far as I could see in the source code, this is always printed when you
> decrypt something that was encrypted for this key.[...]
Some times is is so simple, just own stupidity.


From ineiev at gnu.org  Wed Nov 10 18:26:47 2021
From: ineiev at gnu.org (Ineiev)
Date: Wed, 10 Nov 2021 17:26:47 +0000
Subject: make check -> libgcrypt is too old
In-Reply-To: <874k8ka3g1.fsf@wheatstone.g10code.de>
References: <LXVHNGJI.QTEVT4MP.CUNC73VD@LBX5L4NZ.RR3G4JAU.OG7FL32Y>
 <a566790c-21ca-68b3-c64f-a6cf0e9e38bb@mail.de>
 <874k8ka3g1.fsf@wheatstone.g10code.de>
Message-ID: <20211110172647.GA27080@manas>

On Wed, Nov 10, 2021 at 08:13:18AM +0100, Werner Koch via Gnupg-users wrote:
>
> Not a good idea.  That may break things.  It is better to install
> libgcrypt and the other libs to /user/local/lib and then set
> LD_LIBRARY_PATH accordingly (or fix search order in ld.so.conf).

make install usually says,

> Libraries have been installed in:
...
> If you ever happen to want to link against installed libraries
> in a given directory, LIBDIR, you must either use libtool, and
> specify the full pathname of the library, or use the `-LLIBDIR'
> flag during linking and do at least one of the following:
>    - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
>      during execution
>    - add LIBDIR to the `LD_RUN_PATH' environment variable
>      during linking
>    - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
>    - have your system administrator add LIBDIR to `/etc/ld.so.conf'
>
> See any operating system documentation about shared libraries for
> more information, such as the ld(1) and ld.so(8) manual pages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211110/0f346f1f/attachment-0001.sig>

From kkobayashi at edgematrix.com  Thu Nov 11 02:35:34 2021
From: kkobayashi at edgematrix.com (Kazunori Kobayashi)
Date: Thu, 11 Nov 2021 10:35:34 +0900
Subject: Too many open files caused by repeated decryption operations via
 a GPGME API
In-Reply-To: <87fss59tqk.fsf@wheatstone.g10code.de>
References: <c9307d9c-8847-e53f-b507-d50b540d2f62@edgematrix.com>
 <87fss59tqk.fsf@wheatstone.g10code.de>
Message-ID: <ae5cb285-7da9-7479-bcdf-58a7276af269@edgematrix.com>

On 2021/11/10 1:30, Werner Koch wrote:
> On Fri, 29 Oct 2021 16:24, Kazunori Kobayashi said:
>
>> On modern Linux, we can change the maximum number of file descriptors
>> per process in some ways. This feature is a well-known way for long
>> time operation without reboot in cases such as server machines.
> That is a known problem we recently raise the priority of the feature
> request https://dev.gnupg.org/T2385 to high.  Thus there is a good
> chance that this problem will be solved in the not too distant future.
>
>> https://github.com/gpg/gpgme/blob/gpgme-1.10.0/src/posix-io.c#L673
> Please don't refer to github for gnupg; their copy is out of date.  Use
> our https://dev.gnupg.org instead.
>
>
> Salam-Shalom,
>
>     Werner
>
I appreciate your reply and I'll watch the issue tracker you told me.
I hope that this issue will be improved soon.

Kazunori

-- 
Kazunori Kobayashi
EDGEMATRIX Inc.
https://edgematrix.com



From guru at unixarea.de  Fri Nov 12 11:15:07 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 12 Nov 2021 11:15:07 +0100
Subject: OpenPGP card and gpg-agent TTL
In-Reply-To: <YYj5fW4mBysiDaNj@c720-r368166>
References: <YYOciD12i0Lx9cs/@c720-r368166>
 <87k0hnjbwe.fsf@wheatstone.g10code.de>
 <YYVcOEpJcXxEMgxb@c720-r368166>
 <87ilx4gl9o.fsf@wheatstone.g10code.de>
 <YYj5fW4mBysiDaNj@c720-r368166>
Message-ID: <YY4+q7XN4DehclgC@c720-r368166>

El d?a lunes, noviembre 08, 2021 a las 11:18:37a. m. +0100, Matthias Apitz escribi?:

> > You did the
> > 
> >  gpg-connect-agent updatestartuptty /bye
> > 
> > thing to tell gpg-agent where it shall pop up the pinentry?  Further
> > ...
> 
> Thanks for the hints. Magically it works now by its own after adding
> this to the ~purism/.bashrc (the terminal app does not source .profile).
> 
> In a SSH session a 'pass test' asks now inline for the PIN and in the
> terminal app some Gnome window pops up.

Re/ pinentry there is even more inteligent "magic": The available
pinentry pgms are:

purism at pureos:~$ which pinentry
/usr/bin/pinentry
purism at pureos:~$ ls -l /usr/bin/pinentry
lrwxrwxrwx 1 root root 26 Nov  5 18:05 /usr/bin/pinentry -> /etc/alternatives/pinentry
purism at pureos:~$ ls -l /etc/alternatives/pinentry
lrwxrwxrwx 1 root root 24 Sep 11 08:25 /etc/alternatives/pinentry -> /usr/bin/pinentry-gnome3
purism at pureos:~$ ls -l /usr/bin/pinentr*
lrwxrwxrwx 1 root root    26 Nov  5 18:05 /usr/bin/pinentry -> /etc/alternatives/pinentry
-rwxr-xr-x 1 root root 59848 May  8  2020 /usr/bin/pinentry-curses
-rwxr-xr-x 1 root root 72136 May  8  2020 /usr/bin/pinentry-gnome3
lrwxrwxrwx 1 root root    30 Sep 11 08:25 /usr/bin/pinentry-x11 -> /etc/alternatives/pinentry-x11

And when the PIN is needed in a SSH session, then the PIN is asked in
the SSH session with:

                     ????????????????????????????????????????????????
                     ? Please unlock the card                       ?
                     ?                                              ?
                     ? Number: 0005 0000A6FE                        ?
                     ? Holder: Matthias Apitz                       ?
                     ?                                              ?
                     ? PIN ________________________________________ ?
                     ?                                              ?
                     ?      <OK>                        <Cancel>    ?
                     ????????????????????????????????????????????????

*when* the L5 is locked, when the L5 is not locked the PIN is asked on
its screen with the /usr/bin/pinentry-gnome3. Nice!

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still existing,
no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...


From tlikonen at iki.fi  Tue Nov 16 17:20:51 2021
From: tlikonen at iki.fi (Teemu Likonen)
Date: Tue, 16 Nov 2021 18:20:51 +0200
Subject: User id's without person's name, only email
Message-ID: <87sfvwrs0s.fsf@iki.fi>

I have seen a couple of new OpenPGP keys which have only email addresses
as user id's. No person's name at all. I also noticed that Notmuch Emacs
email client was changed in recent months so that it shows only signer's
email when the signature is verified with a valid key, even if key's
user id's have person's name.

Am I seeing a starting trend here? Do some people think that it is
better practice to have only have email address as user id? What might
be their reason? Or maybe it's not a trend and doesn't mean anything. I
got curious anyway. Add your speculation. :-)

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 434 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211116/bea835e2/attachment.sig>

From andrewg at andrewg.com  Tue Nov 16 18:06:02 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 16 Nov 2021 17:06:02 +0000
Subject: User id's without person's name, only email
In-Reply-To: <87sfvwrs0s.fsf@iki.fi>
References: <87sfvwrs0s.fsf@iki.fi>
Message-ID: <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>

On Tue, 2021-11-16 at 18:20 +0200, Teemu Likonen wrote:
> Am I seeing a starting trend here? Do some people think that it is
> better practice to have only have email address as user id? What
> might be their reason? Or maybe it's not a trend and doesn't mean
> anything. I got curious anyway. Add your speculation. :-)

When selecting a key for either encryption or verification purposes,
only the email address part is meaningful. "John Smith
<jsmith at example.com>" and "John David Smith (work email)
<jsmith at example.com>" are functionally equivalent. The "Real Name" and
"Comment" portions of the userID are mere conventions and, if you have
an address book, entirely redundant.

It is reasonable therefore to take the view that the non-email portion
of a userID is cruft at best (and an unnecessary leakage of personal
information at worst).

A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211116/ce404a86/attachment.sig>

From stefan.vasilev at posteo.ru  Wed Nov 17 00:17:58 2021
From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=)
Date: Tue, 16 Nov 2021 23:17:58 +0000
Subject: Key Management - BSI had send private key instead of public key
Message-ID: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>

Hello,

According to an article on the German site golem.de[1]
Germany's BSI[2] had sent its private key instead of
it's public key to a user via email, who requested its
public key.

I am only familiar with GnuPG command line usage
and assume that they may use a GUI based program
or add-on for an MUA.

My question is what can cause this, let's say if you
have a busy and stressful day and would accidentally
carry out such operation, as security professional
knowing such a cryptographic tool for a long time,
I assume.

If this can happen to professionals then it would
tell me that there is a design flaw in the software
used.

Because this german article does not go into details, has
someone of you more details on how this happened?

Regards
Stefan

[1] 
https://www.golem.de/news/verschluesselung-bsi-verschickt-privaten-pgp-schluessel-2111-161073.html

[2] https://www.bsi.bund.de/EN/Home/home_node.html




From christian.heinrich at cmlh.id.au  Wed Nov 17 02:20:27 2021
From: christian.heinrich at cmlh.id.au (Christian Heinrich)
Date: Wed, 17 Nov 2021 12:20:27 +1100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
Message-ID: <CAGKxTUQOrg5rajY9cNO30d9Zwamps_0+zgX_hqBaTruo4cAVuw@mail.gmail.com>

Stefan,

On Wed, 17 Nov 2021 at 11:47, ?????? ???????? via Gnupg-users
<gnupg-users at gnupg.org> wrote:
> If this can happen to professionals then it would
> tell me that there is a design flaw in the software
> used.

https://www.gnupg.org/gph/en/manual/r887.html is explicit that it will
"export-secret-keys"

I haven't confirmed the fingerprint of every Public Key they made
available for download on their web pages but it may have just been
one Private Key that was compromised rather than many Public Keys but
if want use their search function on their web page with "PGP
Fingerprint" and "GPG Fingerprint"?


-- 
Regards,
Christian Heinrich

http://cmlh.id.au/contact


From keine-eile at e-mail.de  Wed Nov 17 14:26:32 2021
From: keine-eile at e-mail.de (Keine Eile)
Date: Wed, 17 Nov 2021 14:26:32 +0100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
Message-ID: <23e87032-3c79-427c-f40f-decdd42e30f2@e-mail.de>

Am 17.11.21 um 00:17 schrieb ?????? ???????? via Gnupg-users:
[...]
> My question is what can cause this, let's say if you
> have a busy and stressful day and would accidentally
> carry out such operation, as security professional
> knowing such a cryptographic tool for a long time,
> I assume.
> 
> If this can happen to professionals then it would
> tell me that there is a design flaw in the software
> used.
[...]
The folks working at the BSI are -for the most- not professional technicians, they are administrative officers. Don't believe there are a lot of people working, who know much about cryptography. Or how a command line gnupg works.


From keine-eile at e-mail.de  Wed Nov 17 14:33:49 2021
From: keine-eile at e-mail.de (Keine Eile)
Date: Wed, 17 Nov 2021 14:33:49 +0100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <23e87032-3c79-427c-f40f-decdd42e30f2@e-mail.de>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <23e87032-3c79-427c-f40f-decdd42e30f2@e-mail.de>
Message-ID: <6b49d17c-3088-eccb-aa27-14cb8285c131@e-mail.de>

Actually, there is a post in the forum Golem article, how this really happened: t.ly/1n0V


From bernhard at intevation.de  Wed Nov 17 15:59:39 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 17 Nov 2021 15:59:39 +0100
Subject: User id's without person's name, only email
In-Reply-To: <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
References: <87sfvwrs0s.fsf@iki.fi>
 <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
Message-ID: <202111171559.45185.bernhard@intevation.de>

Am Dienstag 16 November 2021 18:06:02 schrieb Andrew Gallagher via 
Gnupg-users:
> On Tue, 2021-11-16 at 18:20 +0200, Teemu Likonen wrote:
> > Am I seeing a starting trend here? Do some people think that it is
> > better practice to have only have email address as user id?

Some email providers offering pubkeys via WKD only accept email-only
uids, see the policy flag "mailbox-only" in
https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/13/

> It is reasonable therefore to take the view that the non-email portion
> of a userID is cruft at best (and an unnecessary leakage of personal
> information at worst).

There are two potential problems here:
 a) usability in case of deliberately missleading information
     madam president <joe.doe at example.ntvtn.de>
 b) abuse prevention and responsibility on case of illegal information
     Mr X is an XXX he lives at Drowning Street YY <joe.doe at example.ntvtn.de>

However an email provider can exclude those ab-use-cases in their terms of 
service with their users and hold them responsible in case of violation.

So it is still okay to use uids which are no email addresses or some uids with 
more or other information. Just do not expect other services to carry this 
information, do not fully trust them (just like you do not trust pubkeys by 
default) and be prepared to take responsibility for the contents you are 
transmitting.

Best Regards,
Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20211117/fe084989/attachment.sig>

From bernhard at intevation.de  Wed Nov 17 16:18:15 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 17 Nov 2021 16:18:15 +0100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
Message-ID: <202111171618.21731.bernhard@intevation.de>

Am Mittwoch 17 November 2021 00:17:58 schrieb ?????? ???????? via Gnupg-users:
> According to an article on the German site golem.de[1]
> Germany's BSI[2] had sent its private key instead of
> it's public key to a user via email, who requested its
> public key.

> 
https://www.golem.de/news/verschluesselung-bsi-verschickt-privaten-pgp-schluessel-2111-161073.html

The article says that is was one private key, password encrypted
for one email address (probably a functional address for a team).
I have no further information on the incident,
and know of no MUA or GUI that makes attaching private key material to an 
email easy.

The most likely scenario would be, that there was a private key in a file
somewhere on the system that could be attached to an email manually.
As GnuPG itself uses a directory clearly named like .gnupg/private-keys-v1.d/,
there is a good chance that it was an exported private key named differently.

The BSI says to have 1400 employees, so not all of them will be technical
security experts, they were growing a lot. The BSI increasingly seems to use 
OpenPGP/MIME instead of S/MIME and is getting more accessible this way for 
encrypted email exchange.

Overall a good case for using more WKD in the client and the server, where the 
pubkey would have been transfered automatically with some basic trust and no 
need for a manual email attachment. 

Best Regards,
Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20211117/68857888/attachment.sig>

From tlikonen at iki.fi  Wed Nov 17 15:40:46 2021
From: tlikonen at iki.fi (Teemu Likonen)
Date: Wed, 17 Nov 2021 16:40:46 +0200
Subject: User id's without person's name, only email
In-Reply-To: <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
References: <87sfvwrs0s.fsf@iki.fi>
 <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
Message-ID: <878rxm26c1.fsf@iki.fi>

* 2021-11-16 17:06:02+0000, Andrew Gallagher via Gnupg-users wrote:

> The "Real Name" and "Comment" portions of the userID are mere
> conventions and, if you have an address book, entirely redundant.

Thanks. That is rather technical point of view and correct in that
sense. In my opinion it is a bit too nerdy because real names are
convenient for other people. For example, I have to address books:

 1. Actual address books for people, their home addresses, phone numbers
    and emails. None of these people have OpenPGP key.

 2. Second "address book" is my OpenPGP keyring. It groups persons'
    names, their email and other key data. If many keys don't have name
    in their user id it could be inconvenience. Computer programs can
    find keys but often we need also manual "gpg -k" etc. Real names
    help there.

    (I understand that some people need to protect their identity and
    use some random strings in user id's. That is completely different
    from usual public communication.)

But this is nothing important. Key's owner decides.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 434 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211117/a9ac7409/attachment.sig>

From andrewg at andrewg.com  Wed Nov 17 18:11:30 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 17 Nov 2021 17:11:30 +0000
Subject: User id's without person's name, only email
In-Reply-To: <878rxm26c1.fsf@iki.fi>
References: <87sfvwrs0s.fsf@iki.fi>
 <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
 <878rxm26c1.fsf@iki.fi>
Message-ID: <1e1d5c25-094b-2d94-828f-5fef2e862cca@andrewg.com>

On 17/11/2021 14:40, Teemu Likonen wrote:
>   2. Second "address book" is my OpenPGP keyring. It groups persons'
>      names, their email and other key data. If many keys don't have name
>      in their user id it could be inconvenience. Computer programs can
>      find keys but often we need also manual "gpg -k" etc. Real names
>      help there.

It may sound like a nerdy quibble, but it's a fundamental weakness. 
Mapping a "Real Name" to an email address is a conceptually different 
thing from mapping an email address to a public key. Conflating the two 
introduces confusion about what exactly is being verified by the 
cryptographic toolchain. If an MUA's address book is not sufficiently 
user-friendly, then that's a user interface shortcoming that can't be 
fixed by introducing RFC-822 "Real Names", which were highly 
questionable long before email encryption was invented...

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211117/6338f948/attachment.sig>

From rjh at sixdemonbag.org  Wed Nov 17 19:15:17 2021
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 17 Nov 2021 13:15:17 -0500
Subject: User id's without person's name, only email
In-Reply-To: <1e1d5c25-094b-2d94-828f-5fef2e862cca@andrewg.com>
References: <87sfvwrs0s.fsf@iki.fi>
 <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
 <878rxm26c1.fsf@iki.fi> <1e1d5c25-094b-2d94-828f-5fef2e862cca@andrewg.com>
Message-ID: <2d37f64f51ccf0d46b5b8c8796daf50a@sixdemonbag.org>

> Mapping a "Real Name" to an email address is a conceptually different
> thing from mapping an email address to a public key.

Except that should we be mapping keys to email addresses in the first 
place?

When we sign a certificate we make an assertion that this cryptographic 
material is controlled by this entity.  I control the cryptographic 
material associated with certificate 0x1DCBDC01B44427C7.  
rjh at sixdemonbag.org controls nothing -- it's just one of several places 
I pick up mail.

I have long considered mapping keys to email addresses to be a 
fundamental flaw.  It obscures exactly what it is we're trying to 
assert: that cryptographic material is controlled by *people*.


From andrewg at andrewg.com  Wed Nov 17 20:04:57 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 17 Nov 2021 19:04:57 +0000
Subject: User id's without person's name, only email
In-Reply-To: <2d37f64f51ccf0d46b5b8c8796daf50a@sixdemonbag.org>
References: <87sfvwrs0s.fsf@iki.fi>
 <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
 <878rxm26c1.fsf@iki.fi> <1e1d5c25-094b-2d94-828f-5fef2e862cca@andrewg.com>
 <2d37f64f51ccf0d46b5b8c8796daf50a@sixdemonbag.org>
Message-ID: <76b44a5b-6b4c-afdf-bcbd-64f747687ed6@andrewg.com>

On 17/11/2021 18:15, Robert J. Hansen wrote:
>> Mapping a "Real Name" to an email address is a conceptually different
>> thing from mapping an email address to a public key.
> 
> Except that should we be mapping keys to email addresses in the first 
> place?
 >
> When we sign a certificate we make an assertion that this cryptographic 
> material is controlled by this entity.? I control the cryptographic 
> material associated with certificate 0x1DCBDC01B44427C7. 
> rjh at sixdemonbag.org controls nothing -- it's just one of several places 
> I pick up mail.

A cryptographic signature does not attest that anything belongs to you, 
the meatspace person - it merely attests a relationship between some 
cryptographic material and a particular identifier. The interpretation 
of the identifier is context-dependent and highly subjective.

If I want to send an email to you, I have to identify you to my MUA. If 
I want to encrypt it, I have to ask the MUA to associate the identifier 
I just gave it with a key. I either select your name from an address 
book (in which case the unique ID is your email address) or I type in 
your email address by hand. It doesn't matter how many other identifiers 
(emails, post boxes, passport numbers) you have - from my POV, and that 
of my MUA, they are irrelevant because they don't let me identify you 
any more precisely than I already can with just one.

The cryptographic binding is always between key material and a 
machine-readable identifier. This identifier may or may not be globally 
unique, but it should be unique in the context of the system within 
which it is used (e.g. my MUA). The mapping of contextual identifiers 
onto meatspace is a philosophical question that is beyond the reasoning 
capability of a computer, and the ability of natural persons to assume 
and discard identifiers is a feature, not a bug.

> I have long considered mapping keys to email addresses to be a 
> fundamental flaw.? It obscures exactly what it is we're trying to 
> assert: that cryptographic material is controlled by *people*.
Some cryptographic material is created, used and destroyed without any 
human interaction whatsoever, e.g. TLS session keys. The session key is 
signed by the server key to state "this session key is controlled by me" 
(i.e. the server). The server may be controlled by an organisation, and 
the organisation by people (or the people by the organisation, depending 
on your point of view!).

The point being that there are many layers of abstraction between the 
cryptographic material and a natural person. Software can only make and 
test claims about some of those layers at best, and some of those layers 
may not even be meaningful to the end user, depending on the context.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211117/6b0875aa/attachment-0001.sig>

From stuartl at longlandclan.id.au  Wed Nov 17 23:49:53 2021
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Thu, 18 Nov 2021 08:49:53 +1000
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
Message-ID: <20211118084953.51e0efb1@longlandclan.id.au>

On Tue, 16 Nov 2021 23:17:58 +0000
?????? ???????? via Gnupg-users <gnupg-users at gnupg.org> wrote:

> [1] 
> https://www.golem.de/news/verschluesselung-bsi-verschickt-privaten-pgp-schluessel-2111-161073.html

Is there an English translation of this article somewhere?  I never
learned German beyond what made its way into the English language or
what I might've picked up from episodes of 'Allo 'Allo or Hogan's
Heroes?

If I go to the link, I get a rather large pop-up dialogue which doesn't
look much like an article at all.  Throw the thing at Google Translate,
and the JavaScript on the page re-directs me back to the original page
in German.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


From jotoho+mailinglist at jotoho.de  Thu Nov 18 00:13:07 2021
From: jotoho+mailinglist at jotoho.de (Jonas Tobias Hopusch)
Date: Thu, 18 Nov 2021 00:13:07 +0100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <20211118084953.51e0efb1@longlandclan.id.au>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
Message-ID: <20211117231307.nvswqyrgeawyon2m@jotoho.de>

> Is there an English translation of this article somewhere?

No, I don't think so. To the best of my knowledge Golem.de publishes exclusively
in German and I didn't find anything with a search engine.

> If I go to the link, I get a rather large pop-up dialogue which doesn't
> look much like an article at all.  Throw the thing at Google Translate,
> and the JavaScript on the page re-directs me back to the original page
> in German.

That was just a mechanism to force users to either consent to extensive tracking
and ads or login with an account that has a paid subscription.

-- 
Jonas Tobias Hopusch


From gnupg at raf.org  Thu Nov 18 03:22:52 2021
From: gnupg at raf.org (raf)
Date: Thu, 18 Nov 2021 13:22:52 +1100
Subject: User id's without person's name, only email
In-Reply-To: <878rxm26c1.fsf@iki.fi>
References: <87sfvwrs0s.fsf@iki.fi>
 <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
 <878rxm26c1.fsf@iki.fi>
Message-ID: <YZW4/FPzuNha17YK@raf.org>

On Wed, Nov 17, 2021 at 04:40:46PM +0200, Teemu Likonen <tlikonen at iki.fi> wrote:

> * 2021-11-16 17:06:02+0000, Andrew Gallagher via Gnupg-users wrote:
> 
> > The "Real Name" and "Comment" portions of the userID are mere
> > conventions and, if you have an address book, entirely redundant.
> 
> Thanks. That is rather technical point of view and correct in that
> sense. In my opinion it is a bit too nerdy because real names are
> convenient for other people.

Real names aren't that useful. They're hardly unique,
even/especially within a single family.

In Australia, voting is mandatory (yay! for now).
Someone I know once received a letter from the
gorvernment asking why they didn't vote, and at the
same time, their father, who had with the same name and
address, received a letter asking why they voted twice
(or maybe it was the other way around). :-)

cheers,
raf



From tlikonen at iki.fi  Thu Nov 18 07:02:06 2021
From: tlikonen at iki.fi (Teemu Likonen)
Date: Thu, 18 Nov 2021 08:02:06 +0200
Subject: User id's without person's name, only email
In-Reply-To: <YZW4/FPzuNha17YK@raf.org>
References: <87sfvwrs0s.fsf@iki.fi>
 <fee7ed0a999a9348d609ee53b4ad53b24d356852.camel@andrewg.com>
 <878rxm26c1.fsf@iki.fi> <YZW4/FPzuNha17YK@raf.org>
Message-ID: <878rxmovc1.fsf@iki.fi>

* 2021-11-18 13:22:52+1100, raf via Gnupg-users wrote:

> Real names aren't that useful. They're hardly unique,
> even/especially within a single family.

That continues the technical or nerdy point of view. "Real names are not
unique. Therefore they are not (that) useful." Sometimes crypto nerds
seem to say that if everything is not perfect then all is lost. In
practice, real names are very useful for humans.

But another thing is that two separate things probably shouldn't be in
the same technical information field. Currently we could do this:

    pub   ed25519 2021-11-07 [C] [expires: 2023-11-07]
          [Not really my key, so fingerprint removed.]
    uid           [...] Teemu Likonen
    uid           [...] <tlikonen at iki.fi>
    uid           [...] <teemu.likonen at iki.fi>
    uid           [...] <dtw at kapsi.fi>

Then other people could more carefully certify different information in
user id's.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 434 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211118/99115d7d/attachment.sig>

From keine-eile at e-mail.de  Thu Nov 18 08:58:05 2021
From: keine-eile at e-mail.de (Keine Eile)
Date: Thu, 18 Nov 2021 08:58:05 +0100
Subject: Translation: Key Management - BSI had send private key instead of
 public key
In-Reply-To: <20211118084953.51e0efb1@longlandclan.id.au>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
Message-ID: <0b67f980-8289-39a3-7df1-8f8422e31541@e-mail.de>

**Translated by Google**

BSI sends private PGP keys
Public and private keys apparently also confused the BSI. That sent a private key, but with password protection.

An exclusive message from Hanno B?ck will be published on November 15, 2021, 2:30 p.m.

Is it a public key or a private key? Public key encryption is confusing.
The use of mail encryption by means of the OpenPGP standard is often considered to be complicated, which is one of the reasons why it has so far not been able to gain broad acceptance. This was apparently also confusing for the Federal Office for Information Security (BSI): It accidentally sent a private PGP key.

Someone had asked the BSI's contact e-mail address for product approval to send them a PGP key in order to be able to communicate with the authorities in encrypted form. In response, however, the person received a private PGP key rather than a public PGP key, as expected.

The BSI confirmed the incident to Golem.de: "In fact, a file was sent that contained a corresponding private key."

Luck in misfortune: a hopefully secure password
PGP-based encryption works with so-called public key cryptography. Different keys are used for encryption and decryption. The public key can be sent to communication partners who can use it to encrypt. You have to keep the private key to yourself, it is used for decryption.

Bad luck for the BSI: The private key sent was password-protected. The severity of the incident therefore depends on how secure the password is. Password-protected private keys can sometimes be cracked with a brute force attack, but this is only practicable with rather weak passwords.

The BSI informed Golem.de "that the mentioned password protection fulfills a very high level. In addition, attachments requiring protection are also encrypted with chiasmus. The BSI is therefore currently assuming that there is no specific risk to information security."

BSI was still using keys months after the incident
At first, the incident was not taken seriously at the BSI. The person to whom the key was sent immediately informed the authorities. But the BSI continued to use the key for several months.

It was only after a request from Golem.de to the BSI's press office that the key was replaced. "A new PGP key was immediately generated for the mailbox mentioned," replied the BSI. "The associated public key and a revocation certificate for the old PGP key will now be successively distributed to the respective contact person."


From jrf at mailbox.org  Thu Nov 18 10:48:55 2021
From: jrf at mailbox.org (Rainer Fiebig)
Date: Thu, 18 Nov 2021 10:48:55 +0100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <20211118084953.51e0efb1@longlandclan.id.au>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
Message-ID: <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>

Am 17.11.21 um 23:49 schrieb Stuart Longland via Gnupg-users:
> On Tue, 16 Nov 2021 23:17:58 +0000
> ?????? ???????? via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
>> [1] 
>> https://www.golem.de/news/verschluesselung-bsi-verschickt-privaten-pgp-schluessel-2111-161073.html
> 
> Is there an English translation of this article somewhere?  I never
> learned German beyond what made its way into the English language or
> what I might've picked up from episodes of 'Allo 'Allo or Hogan's
> Heroes?
That's kind of a misconception: as English is a western germanic
language it's not that German made its way into English but English is
*based* on German.

You would be amazed how many words are similar or even pronounced
identically - like Haus/house, Maus/mouse, Finger/finger etc. pp. The
similarities between English and the dialect spoken in coastal regions
of northern Germany ("Plattdeutsch") are even more striking.

So you already do speak German - to some extent. In case you don't
believe me or wonder where "Anglo-Saxon" comes from, start here:
https://en.wikipedia.org/wiki/Angles.

A bit OT, I know. But I couldn't resist. Hope you're not offended. ;)

Kind regards!

Rainer


From ineiev at gnu.org  Thu Nov 18 13:27:34 2021
From: ineiev at gnu.org (Ineiev)
Date: Thu, 18 Nov 2021 12:27:34 +0000
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
 <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
Message-ID: <20211118122734.GB6930@desdichado>

On Thu, Nov 18, 2021 at 10:48:55AM +0100, Rainer Fiebig via Gnupg-users wrote:
> That's kind of a misconception: as English is a western germanic
> language it's not that German made its way into English but English is
> *based* on German.

To be precise, not on German---it's based on the common ancestor.
both English and German deviate considerably from it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211118/a2faa0b8/attachment.sig>

From jrf at mailbox.org  Thu Nov 18 14:15:53 2021
From: jrf at mailbox.org (Rainer Fiebig)
Date: Thu, 18 Nov 2021 14:15:53 +0100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <20211118122734.GB6930@desdichado>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
 <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
 <20211118122734.GB6930@desdichado>
Message-ID: <1d24c743-c440-6f09-9049-6e70086c5c29@mailbox.org>

Am 18.11.21 um 13:27 schrieb Ineiev:
> On Thu, Nov 18, 2021 at 10:48:55AM +0100, Rainer Fiebig via Gnupg-users wrote:
>> That's kind of a misconception: as English is a western germanic
>> language it's not that German made its way into English but English is
>> *based* on German.
> 
> To be precise, not on German---it's based on the common ancestor.
> both English and German deviate considerably from it.
> 
I guess that saves the day for some. I can almost hear the sigh of
relief. ;)


From mwood at iupui.edu  Thu Nov 18 14:57:37 2021
From: mwood at iupui.edu (Mark H. Wood)
Date: Thu, 18 Nov 2021 08:57:37 -0500
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <1d24c743-c440-6f09-9049-6e70086c5c29@mailbox.org>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
 <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
 <20211118122734.GB6930@desdichado>
 <1d24c743-c440-6f09-9049-6e70086c5c29@mailbox.org>
Message-ID: <YZZb0XKH7dNdKIsU@IUPUI.Edu>

On Thu, Nov 18, 2021 at 02:15:53PM +0100, Rainer Fiebig via Gnupg-users wrote:
> Am 18.11.21 um 13:27 schrieb Ineiev:
> > On Thu, Nov 18, 2021 at 10:48:55AM +0100, Rainer Fiebig via Gnupg-users wrote:
> >> That's kind of a misconception: as English is a western germanic
> >> language it's not that German made its way into English but English is
> >> *based* on German.
> > 
> > To be precise, not on German---it's based on the common ancestor.
> > both English and German deviate considerably from it.
> > 
> I guess that saves the day for some. I can almost hear the sigh of
> relief. ;)

:-)

https://en.wikipedia.org/wiki/The_Story_of_English if anyone finds
this interesting.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.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/20211118/7ff48cb5/attachment.sig>

From jhs at berklix.com  Thu Nov 18 15:40:15 2021
From: jhs at berklix.com (Julian H. Stacey)
Date: Thu, 18 Nov 2021 15:40:15 +0100
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: Your message "Thu, 18 Nov 2021 10:48:55 +0100."
 <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
Message-ID: <202111181440.1AIEeFFb080222@fire.js.berklix.net>

> Am 17.11.21 um 23:49 schrieb Stuart Longland via Gnupg-users:
> > On Tue, 16 Nov 2021 23:17:58 +0000
> > ???????????? ???????????????? via Gnupg-users <gnupg-users at gnupg.org> wrote:
> > 
> >> [1] 
> >> https://www.golem.de/news/verschluesselung-bsi-verschickt-privaten-pgp-schluessel-2111-161073.html
> > 
> > Is there an English translation of this article somewhere?  I never

list of translator sites: http://www.berklix.org/trans/

Cheers,
-- 
Julian Stacey  http://berklix.com/jhs/  http://stolenvotes.uk


From azbigdogs at gmx.com  Thu Nov 18 18:01:49 2021
From: azbigdogs at gmx.com (Mark)
Date: Thu, 18 Nov 2021 10:01:49 -0700
Subject: Key Management - BSI had send private key instead of public key
In-Reply-To: <20211117231307.nvswqyrgeawyon2m@jotoho.de>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
 <20211117231307.nvswqyrgeawyon2m@jotoho.de>
Message-ID: <d8a1aeda-2efa-8da5-2d88-e94b6e12943e@gmx.com>

I used Edge and it's built in translator function to read it after I got
past the page asking regarding the cookies (which Privazer will remove
anyway)

On 11/17/2021 4:13 PM, Jonas Tobias Hopusch via Gnupg-users wrote:
>> Is there an English translation of this article somewhere?
> No, I don't think so. To the best of my knowledge Golem.de publishes exclusively
> in German and I didn't find anything with a search engine.
>
>> If I go to the link, I get a rather large pop-up dialogue which doesn't
>> look much like an article at all.  Throw the thing at Google Translate,
>> and the JavaScript on the page re-directs me back to the original page
>> in German.
> That was just a mechanism to force users to either consent to extensive tracking
> and ads or login with an account that has a paid subscription.
>
--
PGP Key Upon Request



From stuartl at longlandclan.id.au  Thu Nov 18 22:21:09 2021
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Fri, 19 Nov 2021 07:21:09 +1000
Subject: [OT] English [was Re: Key Management - BSI had send private key
 instead of public key]
In-Reply-To: <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
 <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
Message-ID: <20211119072109.68910959@longlandclan.id.au>

On Thu, 18 Nov 2021 10:48:55 +0100
Rainer Fiebig via Gnupg-users <gnupg-users at gnupg.org> wrote:

> That's kind of a misconception: as English is a western germanic
> language it's not that German made its way into English but English is
> *based* on German.

Ahh true, to the purists, English is not a language? it's a composite
of German, French, Italian, Spanish? and lots of others.

Some might say English is a "language" that beats up other languages
and steals their vocabulary.

It doesn't mean the source language is immediately understandable by
those that speak its derivative though even if individual words can be
identified. :-)
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


From stuartl at longlandclan.id.au  Thu Nov 18 22:26:39 2021
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Fri, 19 Nov 2021 07:26:39 +1000
Subject: Translation: Key Management - BSI had send private key instead
 of public key
In-Reply-To: <0b67f980-8289-39a3-7df1-8f8422e31541@e-mail.de>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
 <0b67f980-8289-39a3-7df1-8f8422e31541@e-mail.de>
Message-ID: <20211119072639.6983c98d@longlandclan.id.au>

On Thu, 18 Nov 2021 08:58:05 +0100
Keine Eile <keine-eile at e-mail.de> wrote:

> BSI was still using keys months after the incident
> At first, the incident was not taken seriously at the BSI. The person to whom the key was sent immediately informed the authorities. But the BSI continued to use the key for several months.

Ouch, that is damning?  There's a reason it gets called a "private" key.

Many thanks for the translation too.  Had Golem.de's site not
interfered, I might've gotten past their cookie pop-up (I hate those:
EU's privacy laws are not my problem) and read the article via a
translator (and they'd have gotten some advertising revenue).
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


From jrf at mailbox.org  Thu Nov 18 23:52:49 2021
From: jrf at mailbox.org (Rainer Fiebig)
Date: Thu, 18 Nov 2021 23:52:49 +0100
Subject: [OT] English [was Re: Key Management - BSI had send private key
 instead of public key]
In-Reply-To: <20211119072109.68910959@longlandclan.id.au>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <20211118084953.51e0efb1@longlandclan.id.au>
 <944acc72-4f7e-7aa4-a8d2-2fdfeb3e8c1a@mailbox.org>
 <20211119072109.68910959@longlandclan.id.au>
Message-ID: <cae19174-ad92-210a-2dbc-2dded570f16a@mailbox.org>

Am 18.11.21 um 22:21 schrieb Stuart Longland:
> On Thu, 18 Nov 2021 10:48:55 +0100
> Rainer Fiebig via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
>> That's kind of a misconception: as English is a western germanic
>> language it's not that German made its way into English but English is
>> *based* on German.
> 
> Ahh true, to the purists, English is not a language? it's a composite
> of German, French, Italian, Spanish? and lots of others.
> 
> Some might say English is a "language" that beats up other languages
> and steals their vocabulary.
That seems a bit too harsh to me. As I see it, English is a language
that evolved from its base by integrating useful or chic elements of
those languages that were present over time. A quite natural thing, I
guess. And perhaps one reason why it became so successful.

> 
> It doesn't mean the source language is immediately understandable by
> those that speak its derivative though even if individual words can be
> identified. :-)
> 
Yeah, that's a pity. But at least you have a head start should you ever
decide to go for the real thing. ;)

Cheers and good luck!

Rainer




From bernhard at intevation.de  Fri Nov 19 17:42:49 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 19 Nov 2021 17:42:49 +0100
Subject: Translations Popups and Cookiekalypse
In-Reply-To: <20211119072639.6983c98d@longlandclan.id.au>
References: <0519c4691eb5faa5a2f9ae6d7d08bbcd@posteo.de>
 <0b67f980-8289-39a3-7df1-8f8422e31541@e-mail.de>
 <20211119072639.6983c98d@longlandclan.id.au>
Message-ID: <202111191742.49696.bernhard@intevation.de>

Am Donnerstag 18 November 2021 22:26:39 schrieb Stuart Longland via 
Gnupg-users:
> I might've gotten past their cookie pop-up (I hate those:
> EU's privacy laws are not my problem)

But your privacy may be your concern.

The requirements of the laws have not changed that much with the introduction 
of the GDPR, they are just more unified over all Europe and more enforced.

Because service providers can only process the minimum personal data for 
providing the service to you, they need to ask you before they can use
your data for marketing purposes. So agreeing explicietly to a technical 
session cookie only is not strictely speaking necessary, it is the web site 
provider that want you to agree to more, so they can use your personal data 
to sell your attention to advertisment services.

Best,
Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20211119/7d1dddc4/attachment.sig>

From wk at gnupg.org  Tue Nov 23 13:22:33 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Nov 2021 13:22:33 +0100
Subject: [Announce] GnuPG 2.2.33 (LTS) released
Message-ID: <87pmqr83jq.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG LTS release:
version 2.2.33.  This release fixes a few minor problems and brings a
few new options to ease user support and large scale installations.

The LTS (long term support) series of GnuPG is guaranteed to be
maintained at least until the end of 2024.  See
https://gnupg.org/download/index.html#end-of-life


What is GnuPG
=============

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG can be freely used, modified and distributed under the terms of
the GNU General Public License.


Noteworthy changes in version 2.2.33 (2021-11-23)
=================================================

  * gpg: New option --min-rsa-length.  [rG6ee01c1d26]

  * gpg: New option --forbid-gen-key.  [rG985fb25c46]

  * gpg: New option --override-compliance-check.  [T5655]

  * gpgconf: New command --show-configs.  [rG8fe3f57643]

  * agent,dirmngr: New option --steal-socket.  [rG6507c6ab10]

  * scd: Improve the selection of the default PC/SC reader.  [T5644]

  * gpg: Fix printing of binary notations.  [T5667]

  * gpg: Remove stale ultimately trusted keys from the trustdb.  [T5685]

  * gpgsm: Detect circular chains in --list-chain.  [rGc9343bec83]

  * gpgconf: Create the local option file even if the global file
    exists.  [T5650]

  * dirmngr: Make reading resolv.conf more robust.  [T5657]

  * gpg-wks-server: Fix created file permissions.  [rGf54feb4470]

  * scd: Support longer data for ssh-agent authentication with openpgp
    cards.  [T5682]

  * Support gpgconf.ctl for NetBSD and Solaris.  [T5656,T5671]

  * Silence "Garbled console data" warning under Windows in most
    cases.

  * Silence warning about the rootdir under Unices w/o a mounted /proc
    file system.

  * Fix possible build problems about missing include files.  [T5592]

  * i18n: Replace the term "PIN-Cache" by "Passswort-Cache" in the
    German translation. [rgf453d52e53]

  * i18n: Update the Russian translation.

  Release-info: https://dev.gnupg.org/T5641

  The provided Windows installer is now build against Libgpg-error 1.43
  and thus features versatile meta options for the config file.  For
  example, it is possible to read and use option values from the
  Registry or from environment variables.  More on this is in a not
  published written blog article.


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.2.33 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.33.tar.bz2 (7068k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.33.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.33_20211123.exe (4424k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.33_20211123.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.

A new version of Gpg4win 3 will not be published.  Gpg4win users may
instead install this version on top of 3.1.16 or wait for Gpg4win 4.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.33.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.33.tar.bz2.sig gnupg-2.2.33.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.2.33.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.33.tar.bz2

   and check that the output matches the next line:

70053b799a79139e0e7889282805fc889dd22540  gnupg-2.2.33.tar.bz2
6bf876e04ba00bebb64dffe7d2224206521948a7  gnupg-w32-2.2.33_20211123.tar.xz
c67151e92fc82bd4138ef441dbeba61e9bf4de5f  gnupg-w32-2.2.33_20211123.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, and Ukrainian being almost
completely translated.


Documentation and Support
=========================

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in thee manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T5641 for updated information.

Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and until this year mostly financed by donations.  Three full-time
employed developers as well as two contractors exclusively work on GnuPG
and closely related software like Libgcrypt, GPGME and Gpg4win.

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, or answering questions on the mailing
lists.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not have been possible to keep GnuPG
in a good and secure shape and to address all the small and larger
requests made by our users.  Thanks.


Happy hacking,

   Your GnuPG hackers


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these 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.

--
Please read

  Nils Melzer: Der Fall Julian Assange

It is really important to know the background of the Assange case to
understand the massive perils to free journalism.  The book is right
now only available in German: https://dev.gnupg.org/u/melzerassang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211123/ac760ce2/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From stephen_j_jeffrey at yahoo.com.au  Wed Nov 24 12:39:15 2021
From: stephen_j_jeffrey at yahoo.com.au (Stephen Jeffrey)
Date: Wed, 24 Nov 2021 11:39:15 +0000 (UTC)
Subject: Cannot decrypt file after clearing cache
References: <797383010.622093.1637753955849.ref@mail.yahoo.com>
Message-ID: <797383010.622093.1637753955849@mail.yahoo.com>

Hi all,
I wish to encrypt a file with a passphrase, possibly copy the file elsewhere, and decrypt using the same passphrase.?
If I encrypt a file (with a passphrase) it can then be decypted without entering a passphrase:> echo "test" > test.txt> gpg -c test.txt> gpg -d test.txt.gpg?gpg: AES256.CFB encrypted datagpg: encrypted with 1 passphrasetest
I assume it does not prompt me for a passphrase because it is cached.
If I clear the password cache, and then try to decrypt, the decryption fails (it does not prompt for a password):> gpg-connect-agent reloadagent /byeOK> gpg -d test.txt.gpggpg: AES256.CFB encrypted datagpg: problem with the agent: End of filegpg: encrypted with 1 passphrasegpg: decryption failed: Bad session key
Rebooting the machine does not fix the problem i.e. if I reboot and try to decrypt the file, it fails with the same error (Bad session key). In this case however it does prompt me for the password. After entering the password it fails.
I am using a fresh install of Fedora 35 and gpg2 version 2.3.2.
Why is it failing after I clear the cache?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211124/a3d549f7/attachment-0001.html>

From kloecker at kde.org  Wed Nov 24 13:46:24 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Wed, 24 Nov 2021 13:46:24 +0100
Subject: Cannot decrypt file after clearing cache
In-Reply-To: <797383010.622093.1637753955849@mail.yahoo.com>
References: <797383010.622093.1637753955849.ref@mail.yahoo.com>
 <797383010.622093.1637753955849@mail.yahoo.com>
Message-ID: <4151779.Exnuk0Oc7e@daneel>

On Mittwoch, 24. November 2021 12:39:15 CET Stephen Jeffrey via Gnupg-users 
wrote:
> After entering the
> password it fails. I am using a fresh install of Fedora 35 and gpg2 version
> 2.3.2.
> Why is it failing after I clear the cache?

Because symmetric encryption is broken in version 2.3.2. See 
https://dev.gnupg.org/T5577 for details.

Use any other version. Too bad that Fedora 35 seems to have packaged this 
version. Please file a bug with them so that they can backport the fix or 
update to 2.3.3.

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/20211124/f9abb6fb/attachment.sig>

From stephen_j_jeffrey at yahoo.com.au  Thu Nov 25 11:35:00 2021
From: stephen_j_jeffrey at yahoo.com.au (Stephen Jeffrey)
Date: Thu, 25 Nov 2021 10:35:00 +0000 (UTC)
Subject: Cannot decrypt file after clearing cache
In-Reply-To: <4151779.Exnuk0Oc7e@daneel>
References: <797383010.622093.1637753955849.ref@mail.yahoo.com>
 <797383010.622093.1637753955849@mail.yahoo.com> <4151779.Exnuk0Oc7e@daneel>
Message-ID: <357065736.1218084.1637836500800@mail.yahoo.com>

 Thanks Ingo.
I submitted a bug report, it is here?(https://bugzilla.redhat.com/show_bug.cgi?id=2026617).
CheersSteve

    On Wednesday, 24 November 2021, 10:51:52 pm AEST, Ingo Kl?cker <kloecker at kde.org> wrote:  
 
 On Mittwoch, 24. November 2021 12:39:15 CET Stephen Jeffrey via Gnupg-users 
wrote:
> After entering the
> password it fails. I am using a fresh install of Fedora 35 and gpg2 version
> 2.3.2.
> Why is it failing after I clear the cache?

Because symmetric encryption is broken in version 2.3.2. See 
https://dev.gnupg.org/T5577 for details.

Use any other version. Too bad that Fedora 35 seems to have packaged this 
version. Please file a bug with them so that they can backport the fix or 
update to 2.3.3.

Regards,
Ingo
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20211125/c871698a/attachment.html>