From gnupg-users at spodhuis.org  Sun Mar  1 22:21:20 2020
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Sun, 1 Mar 2020 16:21:20 -0500
Subject: Help me on this
In-Reply-To: <MN2PR02MB6415BDB102AA476F7017CDC0D4E80@MN2PR02MB6415.namprd02.prod.outlook.com>
References: <MN2PR02MB6415BDB102AA476F7017CDC0D4E80@MN2PR02MB6415.namprd02.prod.outlook.com>
Message-ID: <20200301212120.GA18979@fullerene>

On 2020-02-28 at 22:31 +0000, Gubba, Srikanth (HNI Corp) via Gnupg-users wrote:
> When I want to decryption for the encrypted file am getting below error message :

> gpg: using subkey 7E5B6A6AB3392A8D instead of primary key 1CC8C8AD84BF7E76
> gpg: encrypted with 2048-bit ELG key, ID 7E5B6A6AB3392A8D, created 2018-06-12
>       "HNICorp <ITServiceDesk at hnicorp.com>"
> gpg: public key decryption failed: Timeout
> gpg: decryption failed: No secret key
> 
> I have imported my private and public key and trusted ultimately but still getting same error message . Can you please help me on this.

You have not imported the private key.

You can list which private keys you do have with:

    gpg --list-secret-keys

If you do see the 1CC8C8AD84BF7E76 key listed, look closely to make sure
that you also have the 7E5B6A6AB3392A8D sub-key, which the file was
encrypted to.  If you don't have that sub-key, you'll need to find it
and import it too.

-Phil


From gnupg-users at spodhuis.org  Mon Mar  2 18:59:14 2020
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Mon, 2 Mar 2020 12:59:14 -0500
Subject: Help me on this
In-Reply-To: <CH2PR02MB6407C7BE0BE7EBA486F2FC0BD4E70@CH2PR02MB6407.namprd02.prod.outlook.com>
References: <MN2PR02MB6415BDB102AA476F7017CDC0D4E80@MN2PR02MB6415.namprd02.prod.outlook.com>
 <20200301212120.GA18979@fullerene>
 <CH2PR02MB6407C7BE0BE7EBA486F2FC0BD4E70@CH2PR02MB6407.namprd02.prod.outlook.com>
Message-ID: <20200302175914.GA10075@fullerene>

On 2020-03-02 at 14:23 +0000, Gubba, Srikanth (HNI Corp) wrote:
> Thank you for your response , please see this screen shot it has both keys.

> I have imported secret key but still getting same error message , can you please help on this.

Oh, I didn't look closely enough at the error in the original.

} gpg: encrypted with 2048-bit ELG key, ID 7E5B6A6AB3392A8D, created 2018-06-12
}       "HNICorp <ITServiceDesk at hnicorp.com>"
} gpg: public key decryption failed: Timeout

I think that this is GnuPG timing out while waiting for the private key
to be unlocked via a passphrase pop-up.

On Unix, it's done with "pinentry", I don't know Windows so don't know
the details there.  But hopefully this provides enough to point you in
the right direction.

On Unix, if you don't see a pop-up, then usually either something else
already has a gpg-agent pop-up open, or something is not configured
right to invoke the pop-up correctly.

-Phil


From GubbaS at hnicorp.com  Mon Mar  2 15:23:42 2020
From: GubbaS at hnicorp.com (Gubba, Srikanth (HNI Corp))
Date: Mon, 2 Mar 2020 14:23:42 +0000
Subject: Help me on this
In-Reply-To: <20200301212120.GA18979@fullerene>
References: <MN2PR02MB6415BDB102AA476F7017CDC0D4E80@MN2PR02MB6415.namprd02.prod.outlook.com>
 <20200301212120.GA18979@fullerene>
Message-ID: <CH2PR02MB6407C7BE0BE7EBA486F2FC0BD4E70@CH2PR02MB6407.namprd02.prod.outlook.com>

Hi Phil,



Thank you for your response , please see this screen shot it has both keys.



[cid:image001.png at 01D5F06B.E0CB6290]





I have imported secret key but still getting same error message , can you please help on this.



Thanks,

Srikanth Gubba





-----Original Message-----
From: Phil Pennock <gnupg-users at spodhuis.org>
Sent: Sunday, March 1, 2020 3:21 PM
To: Gubba, Srikanth (HNI Corp) <GubbaS at hnicorp.com>
Cc: Gnupg-users at gnupg.org
Subject: [EXTERNAL] Re: Help me on this



On 2020-02-28 at 22:31 +0000, Gubba, Srikanth (HNI Corp) via Gnupg-users wrote:

> When I want to decryption for the encrypted file am getting below error message :



> gpg: using subkey 7E5B6A6AB3392A8D instead of primary key

> 1CC8C8AD84BF7E76

> gpg: encrypted with 2048-bit ELG key, ID 7E5B6A6AB3392A8D, created 2018-06-12

>       "HNICorp <ITServiceDesk at hnicorp.com<mailto:ITServiceDesk at hnicorp.com>>"

> gpg: public key decryption failed: Timeout

> gpg: decryption failed: No secret key

>

> I have imported my private and public key and trusted ultimately but still getting same error message . Can you please help me on this.



You have not imported the private key.



You can list which private keys you do have with:



    gpg --list-secret-keys



If you do see the 1CC8C8AD84BF7E76 key listed, look closely to make sure that you also have the 7E5B6A6AB3392A8D sub-key, which the file was encrypted to.  If you don't have that sub-key, you'll need to find it and import it too.



-Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200302/67c8f722/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 65414 bytes
Desc: image001.png
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200302/67c8f722/attachment-0001.png>

From info at adnplanet.com  Mon Mar  2 23:14:00 2020
From: info at adnplanet.com (ADNPLANET)
Date: Mon, 2 Mar 2020 19:14:00 -0300
Subject: GNUGP new key with old data under an old gnu version - how to fix
 it?
In-Reply-To: <78f0de45-9608-0c33-80ae-b0e24f1807b0@andrewg.com>
References: <004101d5ece0$a1bf5cc0$e53e1640$@adnplanet.com>
 <78f0de45-9608-0c33-80ae-b0e24f1807b0@andrewg.com>
Message-ID: <01b501d5f0df$e1ceb010$a56c1030$@adnplanet.com>

Thanks Andrew!

I fixed the issue with your tips.

I get a backup of the deleted old version keys and use that to display old
data and the new key to enter and display the new data.
Both are installed and both are working fine.

Many thanks for your help!

Fabian

-----Mensaje original-----
De: Gnupg-users <gnupg-users-bounces at gnupg.org> En nombre de Andrew
Gallagher
Enviado el: jueves, 27 de febrero de 2020 07:32
Para: gnupg-users at gnupg.org
Asunto: Re: GNUGP new key with old data under an old gnu version - how to
fix it?

On 26/02/2020 20:09, ADNPLANET via Gnupg-users wrote:
> 
> The new gnugp key was generated under version 2.0.22 and the data 
> stored in database is under gnugp 1.45 Then.. ALL new record is 
> encrypted perfectly and appears in the database, but the archive of a 
> LOT records are missing, because the system is not displaying the data 
> encrypted with the old version.

Firstly, are you sure you have both the old and new keys in your private
keyring? If an encryption key expires, it just means that nothing should be
encrypted *to* it any more, but unless you believe that it has been
compromised it is still safe to use to process existing data. So don't
delete it. :-)

If you do have the old key but it isn't decrypting the old data, then it may
be because the old data is using an outdated format. Try passing the option
--ignore-mdc-error and see what happens. Are there any error messages
emitted? Can you export one of the encrypted blobs to local disk and decrypt
it on the command line?

> My questions :
> 
> 1 - is possible to dwongrade the GNUGP version to 1.45 in the server 
> using cpanel + cloudlinux and then, re-generate the key using the old
> 1.45 version?

Yes, but I would only recommend this as a last resort. Also note that if you
do this you will lose access to all your *new* data, which may be a worse
outcome for you, depending on your use case.

> 2 - or is possible to update the entire database to read the encrypted 
> data wit the new key generated under the new version?

Yes, but it will depend on you being able to decrypt the old data so we
should fix that problem first...

> 3 - or i?m doing something wrong ???

Maybe, what *exactly* are you doing? Without divulging any secrets. :-)

--
Andrew Gallagher




From wk at gnupg.org  Tue Mar  3 12:29:57 2020
From: wk at gnupg.org (Werner Koch)
Date: Tue, 03 Mar 2020 12:29:57 +0100
Subject: Help me on this
In-Reply-To: <20200302175914.GA10075@fullerene> (Phil Pennock via
 Gnupg-users's message of "Mon, 2 Mar 2020 12:59:14 -0500")
References: <MN2PR02MB6415BDB102AA476F7017CDC0D4E80@MN2PR02MB6415.namprd02.prod.outlook.com>
 <20200301212120.GA18979@fullerene>
 <CH2PR02MB6407C7BE0BE7EBA486F2FC0BD4E70@CH2PR02MB6407.namprd02.prod.outlook.com>
 <20200302175914.GA10075@fullerene>
Message-ID: <87pndtvfpm.fsf@wheatstone.g10code.de>

On Mon,  2 Mar 2020 12:59, Phil Pennock said:

> On Unix, it's done with "pinentry", I don't know Windows so don't know
> the details there.  But hopefully this provides enough to point you in

On Windows we can't make it 100% sure that the Pinentry pops up above
the other windows.  In some cases it can't raise itself and thus you
see, as usual under Windows, a blinking icon in the taskbar which you
click to pop up the pinentry.


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/20200303/c6eb34e1/attachment.sig>

From jcross at gmail.com  Tue Mar  3 22:32:01 2020
From: jcross at gmail.com (Jonathan Cross)
Date: Tue, 3 Mar 2020 22:32:01 +0100
Subject: gpg --import-options import-drop-uids not available?
Message-ID: <5E7A76D7-19FA-49D6-9ED0-CEE490C48BD8@gmail.com>


Hello,

I see this option being added here:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8e83493dae426fe36a0e0081198b10db1e103ff1

However it doesn't seem to have been released as of 2.2.19.

Is there a reason this still hasn't been released?

Thanks,  Jonathan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200303/b9bfa238/attachment.sig>

From wk at gnupg.org  Wed Mar  4 11:41:10 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 04 Mar 2020 11:41:10 +0100
Subject: gpg --import-options import-drop-uids not available?
In-Reply-To: <5E7A76D7-19FA-49D6-9ED0-CEE490C48BD8@gmail.com> (Jonathan Cross
 via Gnupg-users's message of "Tue, 3 Mar 2020 22:32:01 +0100")
References: <5E7A76D7-19FA-49D6-9ED0-CEE490C48BD8@gmail.com>
Message-ID: <87pndsl7w9.fsf@wheatstone.g10code.de>

Hi!

if you look at the commit

    gpg: New options import-drop-uids and export-drop-uids.
    [...]   
    These options are required for experiments with changes to the
    keyserver infrastructure.

you can see that they are used for experiments and part of the master
branch.  It is unlikley that they will be backported to 2.2 and they may
even be removed from master.  master is not released software and thus
there is no guarantee for a stable API.


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/20200304/69681eea/attachment.sig>

From info at nuvistastech.com  Fri Mar  6 11:14:28 2020
From: info at nuvistastech.com (NuVista)
Date: Fri, 6 Mar 2020 03:14:28 -0700 (MST)
Subject: Please start a new thread
In-Reply-To: <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com>
References: <ee9c1b0c-fc6f-4e23-9ae5-0494ccc88fb6@www.fastmail.com>
 <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com>
 <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com>
 <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com>
 <87d0mfvwqm.fsf@wheatstone.g10code.de>
 <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com>
 <87sgvauk2x.fsf@wheatstone.g10code.de>
 <b17fb451-a388-4d71-dc19-0fd1d588dba7@digitalbrains.com>
 <CAPwDx1ZMDt-4acH+JtOo0BNxeCjqkx9cVeX2QONGSqe02yZr7Q@mail.gmail.com>
 <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com>
Message-ID: <1583489668567-0.post@n7.nabble.com>

In the output from --export-ssh-key is also a comment field. This
fieldd, in my case shows: openpgp:0xF852DAEE

This should be enough to identify the key. It is the short ID of the
referred authentication subkey.

Website: https://www.nuvistastech.com/



-----

[url=https://www.nuvistastech.com/]NetSuite Partner in India[/url]
--
Sent from: http://gnupg.10057.n7.nabble.com/GnuPG-User-f3.html


From dilfridge at gentoo.org  Sat Mar  7 18:03:40 2020
From: dilfridge at gentoo.org (Andreas K. Huettel)
Date: Sat, 07 Mar 2020 18:03:40 +0100
Subject: Sunset of a smartcard encryption key
Message-ID: <5579054.lOV4Wx5bFT@noumea>

Hi all, 

so here's a question that I'm sure people here have already been thinking 
about... Like probably many others here I have a gpg smartcard with three 
subkeys Sign, Encrypt, Authenticate, and an offline Certify master key at a safe 
place. 

* If I want to let my Signature subkey expire and generate a new one, that's 
not a big problem for me, since the public key is still available to everyone 
on the keyservers for verifying sigs.
* If I want to let my Auth subkey expire and generate a new one, well I just 
need to add the new one to all authorized_keys files in time.

But how do I sensibly handle a graceful sunset of an encryption key? If I 
replace the subkey on my card, I immediately can't read old e-mails anymore.

If I had the key in a file, I could keep the old, expired subkey around and 
still decrypt the data, but that would kinda defy the security provided by the 
card...

My best idea so far is to generate a second token (Nitrokey, Yubikey or 
similar) *only* for old encryption subkeys, and additionally plug that in if I 
need to read an old message. Does anyone already have experience with such a 
setup?

Best, 
Andreas

-- 
Andreas K. H?ttel
dilfridge at gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200307/950dafcd/attachment.sig>

From sac at 300baud.de  Sun Mar  8 00:11:55 2020
From: sac at 300baud.de (Stefan Claas)
Date: Sun, 8 Mar 2020 00:11:55 +0100
Subject: Sunset of a smartcard encryption key
In-Reply-To: <5579054.lOV4Wx5bFT@noumea>
References: <5579054.lOV4Wx5bFT@noumea>
Message-ID: <20200308001155.00005463.sac@300baud.de>

Andreas K. Huettel via Gnupg-users wrote:

> Hi all, 
> 
> so here's a question that I'm sure people here have already been thinking 
> about... Like probably many others here I have a gpg smartcard with three 
> subkeys Sign, Encrypt, Authenticate, and an offline Certify master key at a
> safe place. 
> 
> * If I want to let my Signature subkey expire and generate a new one, that's 
> not a big problem for me, since the public key is still available to everyone 
> on the keyservers for verifying sigs.
> * If I want to let my Auth subkey expire and generate a new one, well I just 
> need to add the new one to all authorized_keys files in time.
> 
> But how do I sensibly handle a graceful sunset of an encryption key? If I 
> replace the subkey on my card, I immediately can't read old e-mails anymore.
> 
> If I had the key in a file, I could keep the old, expired subkey around and 
> still decrypt the data, but that would kinda defy the security provided by
> the card...
> 
> My best idea so far is to generate a second token (Nitrokey, Yubikey or 
> similar) *only* for old encryption subkeys, and additionally plug that in if
> I need to read an old message. Does anyone already have experience with such
> a setup?

What I would like to know how people handle the case when a SmardCard gets lost,
broken or maybe confiscicated at an Airport etc.?

Why not using an encrypted harddisk (VeraCrypt etc.), for important documents,
files, which could be mounted on a dedicated offline computer (or maybe used
with an online computer) and when not used put in a safe place?

Regards
Stefan

-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
           


From andrewg at andrewg.com  Sun Mar  8 00:40:27 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sat, 7 Mar 2020 23:40:27 +0000
Subject: Sunset of a smartcard encryption key
In-Reply-To: <20200308001155.00005463.sac@300baud.de>
References: <20200308001155.00005463.sac@300baud.de>
Message-ID: <7DB6F918-00D7-4F8C-B8FD-3996E398BD5B@andrewg.com>


> On 7 Mar 2020, at 23:13, Stefan Claas via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> What I would like to know how people handle the case when a SmardCard gets lost,
> broken or maybe confiscicated at an Airport etc.?

I generate my keys in a copy of Tails and then copy to smartcard without saving changes on disk; that way I have a backup of all key material. I?ve never lost a smartcard but last year I had to factory reset one and restore from the backup when it went a little haywire.

Andrew Gallagher

From dilfridge at gentoo.org  Sun Mar  8 09:11:49 2020
From: dilfridge at gentoo.org (Andreas K. Huettel)
Date: Sun, 08 Mar 2020 09:11:49 +0100
Subject: Broken / lost smartcard
In-Reply-To: <20200308001155.00005463.sac@300baud.de>
References: <5579054.lOV4Wx5bFT@noumea>
 <20200308001155.00005463.sac@300baud.de>
Message-ID: <2015264.irdbgypaU6@noumea>

[changing the subject since this is quite a different topic]

> What I would like to know how people handle the case when a SmardCard gets
> lost, broken or maybe confiscicated at an Airport etc.?

Well, that's the argument for having at least primary/cert key and encryption 
subkey not *only* on the smartcard but also in a safe place somewhere.

For a signature subkey it doesnt matter then if you lose it (just make a new 
one), and for an authentication subkey you need to prepare to have some 
alternative means of access (or also a backup).

-- 
Andreas K. H?ttel
dilfridge at gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200308/87d07580/attachment.sig>

From sac at 300baud.de  Sun Mar  8 09:32:51 2020
From: sac at 300baud.de (Stefan Claas)
Date: Sun, 8 Mar 2020 09:32:51 +0100
Subject: Broken / lost smartcard
In-Reply-To: <2015264.irdbgypaU6@noumea>
References: <5579054.lOV4Wx5bFT@noumea>
 <20200308001155.00005463.sac@300baud.de>
 <2015264.irdbgypaU6@noumea>
Message-ID: <20200308093251.000033b4.sac@300baud.de>

Andreas K. Huettel via Gnupg-users wrote:

> [changing the subject since this is quite a different topic]
> 
> > What I would like to know how people handle the case when a SmardCard gets
> > lost, broken or maybe confiscicated at an Airport etc.?
> 
> Well, that's the argument for having at least primary/cert key and encryption 
> subkey not *only* on the smartcard but also in a safe place somewhere.
> 
> For a signature subkey it doesnt matter then if you lose it (just make a new 
> one), and for an authentication subkey you need to prepare to have some 
> alternative means of access (or also a backup).
> 

Yes, I only asked because it sounded like you don't have a back-up, after
creating the key-pair.

Regards
Stefan

-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
           


From guru at unixarea.de  Sun Mar  8 10:03:28 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 8 Mar 2020 10:03:28 +0100
Subject: Broken / lost smartcard
In-Reply-To: <2015264.irdbgypaU6@noumea>
References: <5579054.lOV4Wx5bFT@noumea>
 <20200308001155.00005463.sac@300baud.de>
 <2015264.irdbgypaU6@noumea>
Message-ID: <20200308090328.GA5608@c720-r342378>

El d?a domingo, marzo 08, 2020 a las 09:11:49a. m. +0100, Andreas K. Huettel via Gnupg-users escribi?:

> [changing the subject since this is quite a different topic]
> 
> > What I would like to know how people handle the case when a SmardCard gets
> > lost, broken or maybe confiscicated at an Airport etc.?
> 
> Well, that's the argument for having at least primary/cert key and encryption 
> subkey not *only* on the smartcard but also in a safe place somewhere.
> 
> For a signature subkey it doesnt matter then if you lose it (just make a new 
> one), and for an authentication subkey you need to prepare to have some 
> alternative means of access (or also a backup).

For me the bigger problem would be the stored crypted data in the
password-store where I have nearly 300 credentials:

$ find .password-store -type f | wc -l
     282

I wrote a script which decrypts all these files to STDOUT in a form which
could be fed again into the pass(1) command and stores this
in some secure place from time to time.

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Deutschland raus aus der NATO! NATO raus aus Deutschland! Frieden mit Russland!
Germany out of NATO! NATO out of Germany! Peace with Russia!
?Alemania fuera de OTAN! ?OTAN fuera de Alemania! ?Paz con Rusia!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200308/54ae9d87/attachment.sig>

From andrewg at andrewg.com  Tue Mar 10 16:59:02 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 10 Mar 2020 15:59:02 +0000
Subject: How to use reprepro (or anything really) over ssh?
Message-ID: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com>

Hi, all.

I maintain a private debian repository using reprepro. This requires me
to sign updates using a code-signing key, which I keep on my home
machine. I am not always on my home machine of course, meaning I would
like to ssh into it and run reprepro remotely.

This does not work.

reprepro uses gpgme, so it doesn't support `pinentry-mode loopback` (it
crashes if I try). And since I am normally logged in to my home machine,
there is almost guaranteed to be a display active (localhost:0).

Even if I kill all instances of gpg-agent before running reprepro, the
pinentry comes up on :0. Running `ps ax` shows that the pinentry process
is being invoked using `pinentry --display localhost:10.0`, and yet
PINENTRY STILL COMES UP ON :0 WITHOUT FAIL.

Is pinentry ignoring its command line parameters? And how do I get it to
behave? I can only manage this repository when I'm sitting at my home
computer, which is not acceptable.

-- 
Andrew Gallagher

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

From jcross at gmail.com  Tue Mar 10 20:30:45 2020
From: jcross at gmail.com (Jonathan Cross)
Date: Tue, 10 Mar 2020 20:30:45 +0100
Subject: ed448 support in gpg?
Message-ID: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>

Hello,

I am looking into making a new key that is as "future-proof" as possible.
Offline master key that is ed448 would be ideal if possible with Curve25519 subkeys for daily use on a smartcard.

Is ed448 available / in development?
Or a similar 256bit "safe-curves" option?

Thank you,  Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200310/2d870c17/attachment.sig>

From wk at gnupg.org  Wed Mar 11 09:56:24 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Mar 2020 09:56:24 +0100
Subject: ed448 support in gpg?
In-Reply-To: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com> (Jonathan Cross
 via Gnupg-users's message of "Tue, 10 Mar 2020 20:30:45 +0100")
References: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>
Message-ID: <87h7yvgthj.fsf@wheatstone.g10code.de>

On Tue, 10 Mar 2020 20:30, Jonathan Cross said:

> Is ed448 available / in development?

Will be part of 2.3.  However, even then I do not suggest to create such
a key because the majority of deployed software won't be able to use
it.  If you care about the secuity of your key use a smartcard.

Think of your threat model and, as usual, see https://www.xkcd.com/538/


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/20200311/bac708af/attachment-0001.sig>

From wk at gnupg.org  Wed Mar 11 10:04:06 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Mar 2020 10:04:06 +0100
Subject: How to use reprepro (or anything really) over ssh?
In-Reply-To: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com> (Andrew
 Gallagher's message of "Tue, 10 Mar 2020 15:59:02 +0000")
References: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com>
Message-ID: <87blp3gt4p.fsf@wheatstone.g10code.de>

On Tue, 10 Mar 2020 15:59, Andrew Gallagher said:

> reprepro uses gpgme, so it doesn't support `pinentry-mode loopback` (it
> crashes if I try). And since I am normally logged in to my home machine,

GPGME supports pinentry modes since 1.4.0 (release early 2013):

7.4.7 Pinentry Mode
-------------------

 -- Function: gpgme_error_t gpgme_set_pinentry_mode (gpgme_ctx_t CTX,
     gpgme_pinentry_mode_t MODE)

     SINCE: 1.4.0

     The function ?gpgme_set_pinentry_mode? specifies the pinentry mode
     to be used.

     For GnuPG >= 2.1 this option is required to be set to
     ?GPGME_PINENTRY_MODE_LOOPBACK? to enable the passphrase callback
     mechanism in GPGME through ?gpgme_set_passphrase_cb?.

> Is pinentry ignoring its command line parameters? And how do I get it to
> behave? I can only manage this repository when I'm sitting at my home
> computer, which is not acceptable.

After having sshed into the other box run there:

  gpg-connect-agent updatestartuptty /bye


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/20200311/8beb3eff/attachment.sig>

From andrewg at andrewg.com  Wed Mar 11 11:07:57 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 11 Mar 2020 10:07:57 +0000
Subject: How to use reprepro (or anything really) over ssh?
In-Reply-To: <87blp3gt4p.fsf@wheatstone.g10code.de>
References: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com>
 <87blp3gt4p.fsf@wheatstone.g10code.de>
Message-ID: <fe51a068-1f5a-3d12-484e-bf34849c4b05@andrewg.com>

On 11/03/2020 09:04, Werner Koch wrote:
> On Tue, 10 Mar 2020 15:59, Andrew Gallagher said:
> 
>> reprepro uses gpgme, so it doesn't support `pinentry-mode loopback` (it
>> crashes if I try). And since I am normally logged in to my home machine,
> 
> GPGME supports pinentry modes since 1.4.0 (release early 2013):

OK, apologies.

*reprepro* doesn't appear to support `pinentry-mode loopback`, for
whatever reason. But this is orthogonal to the substantial point...

>> Is pinentry ignoring its command line parameters? And how do I get it to
>> behave? I can only manage this repository when I'm sitting at my home
>> computer, which is not acceptable.
> 
> After having sshed into the other box run there:
> 
>   gpg-connect-agent updatestartuptty /bye

I have tried this, and it makes no difference. I have also attempted to
work around the problem by killing gpg-agent entirely. But given that
`pinentry` is being passed the correct `display` option (as evidenced by
`ps ax`), the issue does not appear to be on the agent side.

If I run `pinentry --display $DISPLAY` inside my ssh session, and then
say `GETPIN`, it does not bring up a window. If I do the same in a local
terminal, it brings up the correct window.

The evidence would suggest that pinentry-gnome3 v1.1.0-2 on Debian
blindly uses `:0` no matter what parameters are passed.

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Wed Mar 11 11:47:19 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 11 Mar 2020 10:47:19 +0000
Subject: How to use reprepro (or anything really) over ssh?
In-Reply-To: <fe51a068-1f5a-3d12-484e-bf34849c4b05@andrewg.com>
References: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com>
 <87blp3gt4p.fsf@wheatstone.g10code.de>
 <fe51a068-1f5a-3d12-484e-bf34849c4b05@andrewg.com>
Message-ID: <f4f90a6d-7dff-3886-7a10-338362b6dfc9@andrewg.com>

On 11/03/2020 10:07, Andrew Gallagher wrote:
>
> The evidence would suggest that pinentry-gnome3 v1.1.0-2 on Debian
> blindly uses `:0` no matter what parameters are passed.

As suggested by the stackoverflow answer here:

https://superuser.com/a/1327409/244202

I used update-alternatives to change pinentry-gnome3 to pinentry-gtk-2
and sane behaviour is now observed.

The linked ticket in the above answer is still open and has seen no
activity in three years:

https://dev.gnupg.org/T2818

-- 
Andrew Gallagher

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

From johndoe65534 at mail.com  Wed Mar 11 12:18:44 2020
From: johndoe65534 at mail.com (john doe)
Date: Wed, 11 Mar 2020 12:18:44 +0100
Subject: How to use reprepro (or anything really) over ssh?
In-Reply-To: <f4f90a6d-7dff-3886-7a10-338362b6dfc9@andrewg.com>
References: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com>
 <87blp3gt4p.fsf@wheatstone.g10code.de>
 <fe51a068-1f5a-3d12-484e-bf34849c4b05@andrewg.com>
 <f4f90a6d-7dff-3886-7a10-338362b6dfc9@andrewg.com>
Message-ID: <14009077-060e-0fe3-e9c4-cc87be308006@mail.com>

On 3/11/2020 11:47 AM, Andrew Gallagher wrote:
> On 11/03/2020 10:07, Andrew Gallagher wrote:
>>
>> The evidence would suggest that pinentry-gnome3 v1.1.0-2 on Debian
>> blindly uses `:0` no matter what parameters are passed.
>
> As suggested by the stackoverflow answer here:
>
> https://superuser.com/a/1327409/244202
>
> I used update-alternatives to change pinentry-gnome3 to pinentry-gtk-2
> and sane behaviour is now observed.
>
> The linked ticket in the above answer is still open and has seen no
> activity in three years:
>
> https://dev.gnupg.org/T2818
>
>

Is it the same with pinentry-tty?

--
John Doe


From jcross at gmail.com  Wed Mar 11 13:30:49 2020
From: jcross at gmail.com (Jonathan Cross)
Date: Wed, 11 Mar 2020 13:30:49 +0100
Subject: ed448 support in gpg?
In-Reply-To: <87h7yvgthj.fsf@wheatstone.g10code.de>
References: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>
 <87h7yvgthj.fsf@wheatstone.g10code.de>
Message-ID: <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>


>> Is ed448 available / in development?
> 
> Will be part of 2.3.

Great news!

> However, even then I do not suggest to create such
> a key because the majority of deployed software won't be able to use
> it.

How will older clients deal with a certification signature from this unrecognized algorithm?

> If you care about the secuity of your key use a smartcard.

Yes, I intend to do this with the subkeys (Curve25519)
Only the primary (certification key) would use ed448 which would rarely be used and only offline.

> Think of your threat model and, as usual, see https://www.xkcd.com/538/

Agreed  :-)
In this situation, I just want to avoid creating a new key-pair as long as possible and ed448 is likely to survive just a bit longer from what I understand.
Performance is irrelevant.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200311/655ff39a/attachment.sig>

From andrewg at andrewg.com  Wed Mar 11 15:58:19 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 11 Mar 2020 14:58:19 +0000
Subject: ed448 support in gpg?
In-Reply-To: <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>
References: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>
 <87h7yvgthj.fsf@wheatstone.g10code.de>
 <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>
Message-ID: <9a3b653e-d0a4-6bf2-5e7e-99e11843210a@andrewg.com>

On 11/03/2020 12:30, Jonathan Cross via Gnupg-users wrote:
> ed448 is likely to survive just a bit longer from what I understand.

It depends on how soon you think general-purpose quantum computers will
be available. Elliptic-curve keys are *less* resistant to quantum
algorithms than classically-equivalent RSA, due to their smaller size.

Prioritising speculative future strength (on the order of decades) above
real-world usefulness in the present strikes me as a courageous
decision. :-)

-- 
Andrew Gallagher

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

From wk at gnupg.org  Wed Mar 11 17:21:51 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Mar 2020 17:21:51 +0100
Subject: How to use reprepro (or anything really) over ssh?
In-Reply-To: <fe51a068-1f5a-3d12-484e-bf34849c4b05@andrewg.com> (Andrew
 Gallagher's message of "Wed, 11 Mar 2020 10:07:57 +0000")
References: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com>
 <87blp3gt4p.fsf@wheatstone.g10code.de>
 <fe51a068-1f5a-3d12-484e-bf34849c4b05@andrewg.com>
Message-ID: <875zfahnfk.fsf@wheatstone.g10code.de>

On Wed, 11 Mar 2020 10:07, Andrew Gallagher said:

> The evidence would suggest that pinentry-gnome3 v1.1.0-2 on Debian
> blindly uses `:0` no matter what parameters are passed.

Oh pinentry-gnome - it is intertwined with the gnome-keyring stuff and
does all kind of surprings things.  Indeed, the GTK and QT pinentries
are easier to understand.

BYW: Running gpg with -v (aka --verbose) shows infos about the used
pinentry.



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/20200311/ddaa822a/attachment.sig>

From wk at gnupg.org  Wed Mar 11 17:25:18 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Mar 2020 17:25:18 +0100
Subject: ed448 support in gpg?
In-Reply-To: <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com> (Jonathan Cross
 via Gnupg-users's message of "Wed, 11 Mar 2020 13:30:49 +0100")
References: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>
 <87h7yvgthj.fsf@wheatstone.g10code.de>
 <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>
Message-ID: <871rpyhn9t.fsf@wheatstone.g10code.de>

On Wed, 11 Mar 2020 13:30, Jonathan Cross said:

> How will older clients deal with a certification signature from this
> unrecognized algorithm?

They want use them and print a '?' with --check-sigs.

> Yes, I intend to do this with the subkeys (Curve25519)
> Only the primary (certification key) would use ed448 which would
> rarely be used and only offline.

If the primary key can't be validated the subkeys can't be validated
either.  For migration you can use an ed488 subkey though.  I did
similar with my old key by having a Cv25519 subkey and an rsa subkey.


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/20200311/4983322a/attachment.sig>

From andrewg at andrewg.com  Wed Mar 11 17:40:25 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 11 Mar 2020 16:40:25 +0000
Subject: How to use reprepro (or anything really) over ssh?
In-Reply-To: <875zfahnfk.fsf@wheatstone.g10code.de>
References: <84cb6010-9e43-f86d-5368-d43e8141dd6b@andrewg.com>
 <87blp3gt4p.fsf@wheatstone.g10code.de>
 <fe51a068-1f5a-3d12-484e-bf34849c4b05@andrewg.com>
 <875zfahnfk.fsf@wheatstone.g10code.de>
Message-ID: <f75079ff-4b60-54ed-339d-2a762b66a3eb@andrewg.com>

On 11/03/2020 16:21, Werner Koch wrote:
> Oh pinentry-gnome - it is intertwined with the gnome-keyring stuff and
> does all kind of surprings things.

That explains *eeeverything* :-D

Thanks.

-- 
Andrew Gallagher

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

From rjh at sixdemonbag.org  Wed Mar 11 20:49:12 2020
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 11 Mar 2020 15:49:12 -0400
Subject: ed448 support in =?UTF-8?Q?gpg=3F?=
In-Reply-To: <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>
References: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>
 <87h7yvgthj.fsf@wheatstone.g10code.de>
 <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>
Message-ID: <5431c282f9fa7a0759a3d54fdb41ef7f@mail.monkeyblade.net>

> In this situation, I just want to avoid creating a new key-pair as
> long as possible and ed448 is likely to survive just a bit longer from
> what I understand.

Why is it so important your keypair be as long-lived as possible, when 
there's very little likelihood of you going for that long a period 
without a key compromise event?

Think about key compromise events as you would a building fire.  We 
don't make our buildings fireproof: instead, we clearly mark fire exits, 
hold drills, make backups, and write continuity-of-operations plans.  
The fire *will* happen, but how quickly we recover from it is up to us.

Murphy *will* find us, Murphy *will* beat us, Murphy *will* take our 
lunch money.  When making a new keypair, I think people are well-served 
to remember the key lifetime is fundamentally in Murphy's hands -- not 
theirs.


From johndoe65534 at mail.com  Thu Mar 12 07:56:32 2020
From: johndoe65534 at mail.com (john doe)
Date: Thu, 12 Mar 2020 07:56:32 +0100
Subject: ed448 support in gpg?
In-Reply-To: <5431c282f9fa7a0759a3d54fdb41ef7f@mail.monkeyblade.net>
References: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>
 <87h7yvgthj.fsf@wheatstone.g10code.de>
 <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>
 <5431c282f9fa7a0759a3d54fdb41ef7f@mail.monkeyblade.net>
Message-ID: <725f9087-e7e5-8925-ae4d-76dcc54b9d85@mail.com>

On 3/11/2020 8:49 PM, Robert J. Hansen wrote:
>> In this situation, I just want to avoid creating a new key-pair as
>> long as possible and ed448 is likely to survive just a bit longer from
>> what I understand.
>
> Why is it so important your keypair be as long-lived as possible, when
> there's very little likelihood of you going for that long a period
> without a key compromise event?
>

You could also "transsition" to a new key.

--
John Doe


From jcross at gmail.com  Fri Mar 13 22:12:26 2020
From: jcross at gmail.com (Jonathan Cross)
Date: Fri, 13 Mar 2020 22:12:26 +0100
Subject: ed448 support in gpg?
In-Reply-To: <9a3b653e-d0a4-6bf2-5e7e-99e11843210a@andrewg.com>
References: <A01A709C-CB3E-454F-B2E8-06A70652C4B6@gmail.com>
 <87h7yvgthj.fsf@wheatstone.g10code.de>
 <8099B4A0-390A-42E3-9C50-E0498CDA3A8B@gmail.com>
 <9a3b653e-d0a4-6bf2-5e7e-99e11843210a@andrewg.com>
Message-ID: <5F8ABADC-7060-4EB7-9E2F-B46C5DB25E04@gmail.com>



> On Mar 11, 2020, at 3:58 PM, Andrew Gallagher <andrewg at andrewg.com> wrote:
> 
> Signed PGP part
> On 11/03/2020 12:30, Jonathan Cross via Gnupg-users wrote:
>> ed448 is likely to survive just a bit longer from what I understand.
> 
> It depends on how soon you think general-purpose quantum computers will
> be available. Elliptic-curve keys are *less* resistant to quantum
> algorithms than classically-equivalent RSA, due to their smaller size.

Ah, I was not aware of that.
Seems I should stick with RSA-4096 primary key for now.
I can add an Cv25519 subkey (and even an ed448 subkey later)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200313/909f7371/attachment.sig>

From sac at 300baud.de  Tue Mar 17 19:21:16 2020
From: sac at 300baud.de (Stefan Claas)
Date: Tue, 17 Mar 2020 19:21:16 +0100
Subject: Fw: Save encryption
Message-ID: <20200317192116.0000624e.sac@300baud.de>



Beginn der weitergeleiteten Nachricht:

Datum: Thu, 12 Mar 2020 11:05:20 -0700
Von: "Elliot Harmon | EFF Activism Team" <action at eff.org>
An: <sac at 300baud.de>
Betreff: Save encryption


This is a friendly message from the Electronic Frontier Foundation.

EFF - Electronic Frontier Foundation

Action Alert
Members of Congress have mounted a major threat to your
security online.

The Graham-Blumenthal bill deals with the very serious issue
of child exploitation online, but it offers no meaningful
solutions. It doesn't help organizations that support
victims. It doesn't equip law enforcement agencies with
resources to investigate claims of child exploitation or
training in how to use online platforms to catch
perpetrators. Rather, the bill's authors have used defending
children as the pretense for an attack on our free speech
and security online.

Bottom line: the Graham-Blumenthal bill would give the
Attorney General far too much power to dictate how Internet
companies must operate. We all know how AG William Barr
would use that power: to break encryption.

Barr has repeatedly insisted that communications platforms
should undermine their own security in order to give law
enforcement agencies access to our private messages. The
Graham-Blumenthal bill would finally give Barr the power to
demand that those platforms obey him or face serious
repercussions, including both civil and criminal liability.
Barr's demands would put encryption providers like WhatsApp
and Signal in an awful conundrum: either face the
possibility of losing everything in a single lawsuit or
knowingly undermine their users' security, making all of us
more vulnerable to criminals.

The so-called EARN IT Act is anti-speech, anti-security,
anti-innovation, and unnecessary. Let's tell Congress to
reject it.

Take action now:
https://act.eff.org/action/protect-our-speech-and-security-online-reject-the-graham-blumenthal-bill

Thank you,

Elliot Harmon
Activism Team
Electronic Frontier Foundation

Support our work to defend free speech and security online:
https://supporters.eff.org/donate/graham-blumenthal
ABOUT EFF

The Electronic Frontier Foundation is the leading organization protecting
civil liberties in the digital world. Founded in 1990, we defend free
speech online, fight illegal surveillance, promote the rights of digital
innovators, and work to ensure that the rights and freedoms we enjoy are
enhanced, rather than eroded, as our use of technology grows. EFF is a
member-supported organization. Find out more at https://eff.org. 

 		 Activism 
 		|
 		 Impact Litigation 
 		|
 		 Technology 

This newsletter is printed from 100% recycled electrons. 
815 Eddy Street, San Francisco, CA 94109 United States 
EFF appreciates your support and respects your PRIVACY [1]. 

UNSUBSCRIBE OR CHANGE YOUR EMAIL PREFERENCES [2], or OPT OUT OF ALL EFF
EMAIL [3] 

815 Eddy Street
San Francisco, CA 94109-7701
United States
 

 

Links:
------
[1] http://www.eff.org/policy
[2]
https://supporters.eff.org/update-your-preferences?cid1=3020681&cs=6b62b54e6bce81426700479e8dc83949_1584036320_672
[3]
https://supporters.eff.org/civicrm/mailing/optout?reset=1&jid=94105&qid=115846076&h=f8b271f40f2f2e23


-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
           
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200317/27b4355b/attachment-0001.html>

From andrewg at andrewg.com  Fri Mar 20 12:35:34 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 20 Mar 2020 11:35:34 +0000
Subject: keys.openpgp.org not working on CentOS 7
Message-ID: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com>

Hi, all.

CentOS 7* uses gnupg v2.022, and it appears to be unusable with Hagrid.
Does anyone know what's going on here?

```
[andrewg at delphi ~]$ gpg --search-keys andrewg at andrewg.com
gpg: searching for "andrewg at andrewg.com" from hkp server keys.openpgp.org
gpg: key "andrewg at andrewg.com" not found on keyserver
[andrewg at delphi ~]$ gpg --recv-keys 00CC54C6A0C601691AF4931FFB73E21AF1163937
gpg: requesting key F1163937 from hkp server keys.openpgp.org
gpgkeys: key 00CC54C6A0C601691AF4931FFB73E21AF1163937 can't be retrieved
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
[andrewg at delphi ~]$ gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
```

(*) Yes, I have to use CentOS 7. Customer requirement. :-(

-- 
Andrew Gallagher

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

From wk at gnupg.org  Fri Mar 20 14:37:49 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Mar 2020 14:37:49 +0100
Subject: keys.openpgp.org not working on CentOS 7
In-Reply-To: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com> (Andrew
 Gallagher's message of "Fri, 20 Mar 2020 11:35:34 +0000")
References: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com>
Message-ID: <877dzf9mfm.fsf@wheatstone.g10code.de>

On Fri, 20 Mar 2020 11:35, Andrew Gallagher said:

> CentOS 7* uses gnupg v2.022, and it appears to be unusable with Hagrid.
> Does anyone know what's going on here?

GnuPG 2.0.22 was released in fall 2013(!) has since then received 8
updates and reached end-of-life at thend of 2017.  The question is why
they are using such an old version and in particular on a network
connected box.



Shalom-Salam,

   Werner


p.s.
And well, keys.openpgp.org does not send compliant keys backs but strips
off important parts of OpenPGP key blocks.  It reminds me on the
problems we had pre-2000 with the keyserver.net company.

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

From andrewg at andrewg.com  Fri Mar 20 15:22:53 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 20 Mar 2020 14:22:53 +0000
Subject: keys.openpgp.org not working on CentOS 7
In-Reply-To: <877dzf9mfm.fsf@wheatstone.g10code.de>
References: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com>
 <877dzf9mfm.fsf@wheatstone.g10code.de>
Message-ID: <03b1c954-5302-5a6d-1f06-a1b0e241f16e@andrewg.com>

On 20/03/2020 13:37, Werner Koch wrote:
> > keys.openpgp.org does not send compliant keys backs but strips
> off important parts of OpenPGP key blocks.

Even for keys with verified user-ids?

-- 
Andrew Gallagher

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

From wk at gnupg.org  Fri Mar 20 16:46:12 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Mar 2020 16:46:12 +0100
Subject: keys.openpgp.org not working on CentOS 7
In-Reply-To: <03b1c954-5302-5a6d-1f06-a1b0e241f16e@andrewg.com> (Andrew
 Gallagher's message of "Fri, 20 Mar 2020 14:22:53 +0000")
References: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com>
 <877dzf9mfm.fsf@wheatstone.g10code.de>
 <03b1c954-5302-5a6d-1f06-a1b0e241f16e@andrewg.com>
Message-ID: <87v9mz81x7.fsf@wheatstone.g10code.de>

On Fri, 20 Mar 2020 14:22, Andrew Gallagher said:

> Even for keys with verified user-ids?

I have no idea because I do not have such a key.


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: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200320/cab85f71/attachment-0001.sig>

From konstantin at linuxfoundation.org  Fri Mar 20 16:18:06 2020
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Fri, 20 Mar 2020 11:18:06 -0400
Subject: keys.openpgp.org not working on CentOS 7
In-Reply-To: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com>
References: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com>
Message-ID: <20200320151806.jfsw3modgbfwdshe@chatter.i7.local>

On Fri, Mar 20, 2020 at 11:35:34AM +0000, Andrew Gallagher wrote:
> (*) Yes, I have to use CentOS 7. Customer requirement. :-(

If using third-party repositories is an option for you, we package 
gnupg22-static here:
https://copr.fedorainfracloud.org/coprs/icon/lfit/packages/

-K
-------------- 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/20200320/571091b2/attachment.sig>

From wk at gnupg.org  Fri Mar 20 17:51:09 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Mar 2020 17:51:09 +0100
Subject: [Announce] GnuPG 2.2.20 released
Message-ID: <87h7yj7ywy.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.20.  This is maintenace release fixing a minor security
problem and adding a new OpenPGP feature.  See below for details.


About GnuPG
===========

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

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

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.20
====================================

  * Protect the error counter against overflow to guarantee that the
    tools can't be tricked into returning success after an error.

  * gpg: Make really sure that --verify-files always returns an error.

  * gpg: Fix key listing --with-secret if a pattern is given.  [#4061]

  * gpg: Fix detection of certain keys used as default-key.  [#4810]

  * gpg: Fix default-key selection when a card is available.  [#4850]

  * gpg: Fix key expiration and key usage for keys created with a
    creation date of zero.  [#4670]

  * gpgsm: Fix import of some CR,LF terminated certificates.  [#4847]

  * gpg: New options --include-key-block and --auto-key-import to
    allow encrypted replies after an initial signed message.  [#4856]

  * gpg: Allow the use of a fingerprint with --trusted-key. [#4855]

  * gpg: New property "fpr" for use by --export-filter.

  * scdaemon: Disable the pinpad if a KDF DO is used.  [#4832]

  * dirmngr: Improve finding OCSP certificates.  [#4536]

  * Avoid build problems with LTO or gcc-10. [#4831]

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


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

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

GnuPG 2.2.20 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.20.tar.bz2 (6627k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.20.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.20_20200320.exe (4144k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.20_20200320.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 GnuPG's full installer for Windows (aka Gpg4win)
featuring several frontends and plugins will be released shortly.


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.20.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.20.tar.bz2.sig gnupg-2.2.20.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.20.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.20.tar.bz2

   and check that the output matches the next line:

d5290f0781df5dc83302127d6065fb59b35e53d7  gnupg-2.2.20.tar.bz2
a8b47222875b31661f79c1e7414657b02b44da78  gnupg-w32-2.2.20_20200320.tar.xz
e6547a9bd2cdca3264ccb36d64f755ba6c8da2ba  gnupg-w32-2.2.20_20200320.exe


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

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


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

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

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/T4860 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
======

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs two full-time developers and one
contractor.  They all work exclusively on GnuPG and closely related
software like Libgcrypt, GPGME and Gpg4win.

We have to thank all the people who helped the GnuPG project, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not be possible to keep GnuPG in a
good 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.

p.p.s
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 three keys:

  rsa2048 2011-01-12 [expires: 2021-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048 2014-10-29 [expires: 2020-10-30]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa3072 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

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.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200320/984e8c91/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From andrewg at andrewg.com  Sat Mar 21 17:24:11 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sat, 21 Mar 2020 16:24:11 +0000
Subject: keys.openpgp.org not working on CentOS 7
In-Reply-To: <20200320151806.jfsw3modgbfwdshe@chatter.i7.local>
References: <1b5a2704-c8de-d7ae-df7b-3ecb7565822c@andrewg.com>
 <20200320151806.jfsw3modgbfwdshe@chatter.i7.local>
Message-ID: <c748fab2-b300-d240-f2e1-b9da5eea36cb@andrewg.com>

On 20/03/2020 15:18, Konstantin Ryabitsev wrote:
> On Fri, Mar 20, 2020 at 11:35:34AM +0000, Andrew Gallagher wrote:
>> (*) Yes, I have to use CentOS 7. Customer requirement. :-(
> 
> If using third-party repositories is an option for you, we package 
> gnupg22-static here:
> https://copr.fedorainfracloud.org/coprs/icon/lfit/packages/

I discovered your blog on the subject[1] earlier and it helped me over
that particular hump, thank you! :-)

In order to get the distro monkeysphere to work, I also had to edit its
default PATH, force-migrate its core keyring, and hot-patch one of its
library routines to ignore subkey fingerprints. It will break on the
next upgrade, but it's CentOS 7 so it will never be upgraded.

I'm learning to live with a very low bar of "acceptability"...

Thanks again!

[1]
https://people.kernel.org/monsieuricon/run-gnupg-2-2-17-on-your-el7-system

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Sun Mar 22 00:30:09 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sat, 21 Mar 2020 23:30:09 +0000
Subject: WKS server problems
Message-ID: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>

Hi, all.

I'm trying to follow the WKS instructions from the wiki[1] on a remote
VM, but it hangs at the key generation stage:

```
key-submission at keys1:~$ gpg --passphrase '' --batch --quick-gen-key
"$SUBMISSION_ADDRESS"


^C
gpg: signal Interrupt caught ... exiting
```

There are no rogue pinentry processes in the `ps` list. I've tried
pinentry loopback just in case, but to no avail.

Any idea what's going on?

gpg (GnuPG) 2.2.4

[1] https://wiki.gnupg.org/WKS

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Sun Mar 22 00:39:19 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sat, 21 Mar 2020 23:39:19 +0000
Subject: monkeysign removal from bullseye
Message-ID: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>

It would appear that the python2/3 migration dumpster fire has claimed
yet another good package[1]:

```
> Hi,
> Has there been further development? Otherwise I'd suggest to remove
monkeysign
> for now, it's blocking the removal of pygtk (and in turn a few other
libraries)
> and it can still be re-introduced by bullseye release if it gets ported.

i'm sorry to say there has been no progress and must now admit this is
the only short term solution.
```

I cannot stress enough how awesome monkeysign is. I have a pet project
that is only reasonably possible because of its existence, and which I
will have to abandon if monkeysign becomes unmaintained.

How much work would be involved in getting it back into production? I'm
not a python programmer (the python2/3 migration catastrophe has put me
off ever wasting my brain cells on it) but I might be willing to suffer
it for this one project.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937066

-- 
Andrew Gallagher

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

From gnupg-users at spodhuis.org  Sun Mar 22 04:17:19 2020
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Sat, 21 Mar 2020 23:17:19 -0400
Subject: WKS server problems
In-Reply-To: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
Message-ID: <20200322031719.GA13838@fullerene>

On 2020-03-21 at 23:30 +0000, Andrew Gallagher wrote:
> I'm trying to follow the WKS instructions from the wiki[1] on a remote
> VM, but it hangs at the key generation stage:
[...]
> gpg (GnuPG) 2.2.4

Is this a newly created VM?  Can you not use the opportunity of "nothing
else on the system which needs to be left untouched" to install newer
GnuPG?

GnuPG 2.2.4 is from 2017, there have been many fixes and security
improvements since then.

Besides, 2.2.14 is the first version with WKS support.  Is that what you
meant?

Please, for new VMs just install the latest version from whatever
backports / compatibility package repository your OS distribution uses.

> key-submission at keys1:~$ gpg --passphrase '' --batch --quick-gen-key
> "$SUBMISSION_ADDRESS"

> Any idea what's going on?

Assuming Linux:

For such an old GnuPG release, assuming an equally old libgcrypt, my
best guess is that it's trying to use /dev/random for entropy and
blocking, since /dev/urandom isn't safe (for key generation) on Linux.

    cat /proc/sys/kernel/random/entropy_avail

Newer GnuPG / libgcrypt use better system calls (getentropy/getrandom)
which are still safe but which don't use calls which cause Linux to get
its knickers in a twist about too many calls for entropy.

-Phil


From mgorny at gentoo.org  Sun Mar 22 06:31:55 2020
From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=)
Date: Sun, 22 Mar 2020 06:31:55 +0100
Subject: monkeysign removal from bullseye
In-Reply-To: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
Message-ID: <c291a293c61651064ce9db040be88102e32cbf59.camel@gentoo.org>

On Sat, 2020-03-21 at 23:39 +0000, Andrew Gallagher wrote:
> It would appear that the python2/3 migration dumpster fire has claimed
> yet another good package[1]:
> 
> ```
> > Hi,
> > Has there been further development? Otherwise I'd suggest to remove
> monkeysign
> > for now, it's blocking the removal of pygtk (and in turn a few other
> libraries)
> > and it can still be re-introduced by bullseye release if it gets ported.
> 
> i'm sorry to say there has been no progress and must now admit this is
> the only short term solution.
> ```
> 
> I cannot stress enough how awesome monkeysign is. I have a pet project
> that is only reasonably possible because of its existence, and which I
> will have to abandon if monkeysign becomes unmaintained.
> 
> How much work would be involved in getting it back into production? I'm
> not a python programmer (the python2/3 migration catastrophe has put me
> off ever wasting my brain cells on it) but I might be willing to suffer
> it for this one project.
> 

Gentoo has removed it back in 2018.  It says:

| Please use caff from app-crypt/signing-party instead.

Maybe that's an option for you as well.

-- 
Best regards,
Micha? G?rny

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

From johndoe65534 at mail.com  Sun Mar 22 06:38:12 2020
From: johndoe65534 at mail.com (john doe)
Date: Sun, 22 Mar 2020 06:38:12 +0100
Subject: WKS server problems
In-Reply-To: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
Message-ID: <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>

On 3/22/2020 12:30 AM, Andrew Gallagher wrote:
> Hi, all.
>
> I'm trying to follow the WKS instructions from the wiki[1] on a remote
> VM, but it hangs at the key generation stage:
>
> ```
> key-submission at keys1:~$ gpg --passphrase '' --batch --quick-gen-key
> "$SUBMISSION_ADDRESS"
>
>
> ^C
> gpg: signal Interrupt caught ... exiting
> ```
>
> There are no rogue pinentry processes in the `ps` list. I've tried
> pinentry loopback just in case, but to no avail.
>
> Any idea what's going on?
>
> gpg (GnuPG) 2.2.4
>
> [1] https://wiki.gnupg.org/WKS
>


Do you have enough entropy on the VM?

In a Stretch VM, I had to install 'haveged' to have enough entropy
otherwise it would hang for ages.

--
John Doe


From andrewg at andrewg.com  Sun Mar 22 13:36:42 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 22 Mar 2020 12:36:42 +0000
Subject: WKS server problems
In-Reply-To: <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
Message-ID: <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>

On 22/03/2020 05:38, john doe wrote:
> Do you have enough entropy on the VM?

Argh, thank you. I thought I had enough entropy because monkeysphere
created its trust root without issue, but installing haveged did fix the
problem.

Rule of thumb, don't debug systems at 11pm...

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Sun Mar 22 13:58:39 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 22 Mar 2020 12:58:39 +0000
Subject: WKS server problems
In-Reply-To: <20200322031719.GA13838@fullerene>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <20200322031719.GA13838@fullerene>
Message-ID: <598ec28f-c67b-3a88-0c6e-4b43690b827e@andrewg.com>

On 22/03/2020 03:17, Phil Pennock wrote:
> On 2020-03-21 at 23:30 +0000, Andrew Gallagher wrote:
>> I'm trying to follow the WKS instructions from the wiki[1] on a remote
>> VM, but it hangs at the key generation stage:
> [...]
>> gpg (GnuPG) 2.2.4
> 
> Is this a newly created VM?  Can you not use the opportunity of "nothing
> else on the system which needs to be left untouched" to install newer
> GnuPG?

I'm using vanilla ubuntu 18.04, but I'm having no problems otherwise
with the distro gnupg's wkd/wks support:

```
key-submission at keys1:~$ gpg --with-wkd-hash -K "$SUBMISSION_ADDRESS"
sec   rsa3072 2020-03-22 [SC] [expires: 2022-03-22]
      ABAAE8DD259B21B4B7C65EFC40DB83CEBF81AB3A
uid           [ultimate] key-submission@<go away spiders>
              54f6ry7x1qqtpor16txw5gdmdbbh6a73@<go away spiders>
ssb   rsa3072 2020-03-22 [E]
key-submission at keys1:~$ gpg-wks-server --version
gpg-wks-server (GnuPG) 2.2.4
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
```

I will be upgrading to 20.04 ASAP, however.

> Assuming Linux:
> 
> For such an old GnuPG release, assuming an equally old libgcrypt, my
> best guess is that it's trying to use /dev/random for entropy and
> blocking, since /dev/urandom isn't safe (for key generation) on Linux.

Yes, that's probably the issue. As mentioned in my reply to John,
haveged cleaned up the problem.

Thanks, and sorry for the silly questions.

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Sun Mar 22 17:42:42 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 22 Mar 2020 16:42:42 +0000
Subject: monkeysign removal from bullseye
In-Reply-To: <c291a293c61651064ce9db040be88102e32cbf59.camel@gentoo.org>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <c291a293c61651064ce9db040be88102e32cbf59.camel@gentoo.org>
Message-ID: <3aef17ce-269f-6974-b964-2d78aeddb3b7@andrewg.com>

On 22/03/2020 05:31, Micha? G?rny wrote:
> Gentoo has removed it back in 2018.  It says:
> 
> | Please use caff from app-crypt/signing-party instead.
> 
> Maybe that's an option for you as well.

Not really. Monkeysign is a caff replacement, not the other way around.
And monkeysign's GUI, monkeyscan, is the real killer app. I know of
nothing comparable.

-- 
Andrew Gallagher

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

From johndoe65534 at mail.com  Sun Mar 22 18:08:58 2020
From: johndoe65534 at mail.com (john doe)
Date: Sun, 22 Mar 2020 18:08:58 +0100
Subject: monkeysign removal from bullseye
In-Reply-To: <3aef17ce-269f-6974-b964-2d78aeddb3b7@andrewg.com>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <c291a293c61651064ce9db040be88102e32cbf59.camel@gentoo.org>
 <3aef17ce-269f-6974-b964-2d78aeddb3b7@andrewg.com>
Message-ID: <e17914f6-2c59-39a9-68d4-003be6f138d0@mail.com>

On 3/22/2020 5:42 PM, Andrew Gallagher wrote:
> On 22/03/2020 05:31, Micha? G?rny wrote:
>> Gentoo has removed it back in 2018.  It says:
>>
>> | Please use caff from app-crypt/signing-party instead.
>>
>> Maybe that's an option for you as well.
>
> Not really. Monkeysign is a caff replacement, not the other way around.
> And monkeysign's GUI, monkeyscan, is the real killer app. I know of
> nothing comparable.
>

I might be missing the point here but why don't you simply use a Buster
VM for monkeysign?

Also, monkeysign is convenient but you can do it yourself as well! :)

--
John Doe


From andrewg at andrewg.com  Sun Mar 22 19:01:09 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 22 Mar 2020 18:01:09 +0000
Subject: monkeysign removal from bullseye
In-Reply-To: <87tv2ggxey.fsf@angela.anarc.at>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <87tv2ggxey.fsf@angela.anarc.at>
Message-ID: <f5f55fa7-d703-291a-307d-29a16d0e0a5d@andrewg.com>

On 22/03/2020 16:35, Antoine Beaupr? wrote:
>
> Within less than 24 hours, I get this email offering help.

Hi, Antoine.

I'm sorry to hear about the lack of support for your project. It had so
many maintainers! I personally only became aware of this when all of my
open tickets against monkeysign were forcibly closed.

> Besides, if people want a GUI to sign keys, GNOME keysign is pretty much
> the state of the art there, as the issue above documents.

GNOME keysign looks similar, but AFAICT it requires a "keysign server"
on the (mutual?) local network. That seems to be an extreme restriction,
and makes it totally useless to me (and I suspect most other people
too). It also doesn't see any of my private keys, which is a pretty big
blocker.

> I have a dev/python3 branch that is the latest work on this, if people
> want to take a look. Right now tests hang and I doubt the thing actually
> works.

I'm not a python programmer and my skills here are probably nowhere near
what is required. I certainly wouldn't be comfortable taking the lead on
any large porting project, but I would be willing to help out wherever I
can. If however you think helping to improve an alternative project is a
better use of time and effort, I'll defer to your wisdom.

> Part of the problem with monkeysign is it was written before gpgme
> gained support for signing keys and dealing with keyrings (and I'm not
> sure its support is still good enough). I also didn't find out about the
> python-gnupg python library before writing the first spike on a train,
> so I ended up rewriting my own wrapper around `gpg --status-fd`, which
> was a terrible mistake.
>
> In retrospect, I consider it's a mistake to write *anything* that talks
> with `gpg --status-fd` now. 
...
> I'm sorry about this. I know it sucks to have a piece of software you
> use on a daily basis just disappear from under you.

I feel your pain. I've been trying for the past few years to knock
together a menu-driven offline-key management interface[1] for PGP CAs,
for use in corporate environments. I therefore wanted to make the entire
process (for both users and admins) as painless as possible. Monkeysign
became a key part of that once I discovered that writing my own flaky
wrappers around the gpg command line was duplicating your work. :-) And
there is approximately zero chance that I would have developed the
camera/qrcode interface myself.

If bringing monkeysign back from the dead is too much to ask, then maybe
I can work around it using caff - although I will lose much
functionality in doing so. GNOME keysign looks to have too many
restrictions to be usable (I want to run it on Tails, how on earth does
that work?). Any suggestions for workable alternatives will be
gratefully received.

Sorry again,
Andrew.

[1] If anyone is interested you can find the barely-functional carcass
of the project at https://github.com/andrewgdotcom/frith . Beware that
it is embarrassingly amateur, with no test suite, a shamefully
monolithic structure and lots of exposed wires.

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Sun Mar 22 19:01:18 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 22 Mar 2020 18:01:18 +0000
Subject: monkeysign removal from bullseye
In-Reply-To: <e17914f6-2c59-39a9-68d4-003be6f138d0@mail.com>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <c291a293c61651064ce9db040be88102e32cbf59.camel@gentoo.org>
 <3aef17ce-269f-6974-b964-2d78aeddb3b7@andrewg.com>
 <e17914f6-2c59-39a9-68d4-003be6f138d0@mail.com>
Message-ID: <bc2aa837-750b-d26a-9ab3-14f10f770baa@andrewg.com>

On 22/03/2020 17:08, john doe wrote:
> I might be missing the point here but why don't you simply use a Buster
> VM for monkeysign?

I'm actually using Tails, and Tails is a fast-moving target. No, I'm not
going to install a VM on my Tails persistent partition.

> Also, monkeysign is convenient but you can do it yourself as well! 

Come back to me when there is a fully scriptable interface to gpg.
Monkeysign abstracted away a *LOT* of that pain.

-- 
Andrew Gallagher

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

From anarcat at debian.org  Sun Mar 22 17:35:33 2020
From: anarcat at debian.org (=?utf-8?Q?Antoine_Beaupr=C3=A9?=)
Date: Sun, 22 Mar 2020 12:35:33 -0400
Subject: monkeysign removal from bullseye
In-Reply-To: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
Message-ID: <87tv2ggxey.fsf@angela.anarc.at>

On 2020-03-21 23:39:19, Andrew Gallagher wrote:
> It would appear that the python2/3 migration dumpster fire has claimed
> yet another good package[1]:
>
> ```
>> Hi,
>> Has there been further development? Otherwise I'd suggest to remove
> monkeysign
>> for now, it's blocking the removal of pygtk (and in turn a few other
> libraries)
>> and it can still be re-introduced by bullseye release if it gets ported.
>
> i'm sorry to say there has been no progress and must now admit this is
> the only short term solution.
> ```
>
> I cannot stress enough how awesome monkeysign is. I have a pet project
> that is only reasonably possible because of its existence, and which I
> will have to abandon if monkeysign becomes unmaintained.
>
> How much work would be involved in getting it back into production? I'm
> not a python programmer (the python2/3 migration catastrophe has put me
> off ever wasting my brain cells on it) but I might be willing to suffer
> it for this one project.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937066

TL;DR: a lot of work.

Hi!

Monkeysign author here.

I've been beating this drum for years now. In july 2018, I posted this:

https://0xacab.org/monkeysphere/monkeysign/issues/64

No one stepped up.

Then that issue was opened in the Debian bugtracker about the out of
date Python 2 and pygtk dependencies. Again, I said I didn't have time
to deal with it.

No one stepped up.

Then I was pinged again on friday, and was told my package was keeping
everyone else from moving on, away from pygtk and python2. I gave it the
green light, with the understanding that someone could re-introduce the
package later in the bullseye release process.

Within less than 24 hours, I get this email offering help.

While I'm flattered and happy to hear people say "how awesome monkeysign
is", I must say it's a bit frustrating to hear that only after years of
silence and only a handful of people providing any sort of help to the
project. I know this is typical for free software projects, but at this
point, it's a bit disheartening.

There's a lot of work to do to bring Monkeysign back into Debian. First,
ideally, it would need to be ported to GTK3:

https://0xacab.org/monkeysphere/monkeysign/issues/21
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885517
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935335

But that's so much work that it might be better ripping out the entire
GUI code and just remove the GTK dependency. It would be the first step
to a port anyways: I don't think it makes sense to "rewrite" from gtk to
gtk3. It's basically "write a new UI", so removing the code would at
least remove this hurdle in the path to Debian inclusion.

Besides, if people want a GUI to sign keys, GNOME keysign is pretty much
the state of the art there, as the issue above documents.

Then the other part of the challenge is to port to Python 3. @simonft
already did an awesome job there porting from our custom stderr logging
to the logging module. It takes care of a huge chunk of the porting (as
we were using old-style print statements!). But there's still more work
to be done to port to Python3:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937066

I have a dev/python3 branch that is the latest work on this, if people
want to take a look. Right now tests hang and I doubt the thing actually
works.

Part of the problem with monkeysign is it was written before gpgme
gained support for signing keys and dealing with keyrings (and I'm not
sure its support is still good enough). I also didn't find out about the
python-gnupg python library before writing the first spike on a train,
so I ended up rewriting my own wrapper around `gpg --status-fd`, which
was a terrible mistake.

In retrospect, I consider it's a mistake to write *anything* that talks
with `gpg --status-fd` now. That protocol is brittle, changing,
minimally documented and extremely hard to use. It's better to use
gpgme, but it feels really strange, from a developer's perspective, to
talk to a C library that talks to the gpg binary. I can't help but think
there are many bugs (if not security issues) lying underneath those many
layers.

If I would be seriously resuming work on monkeysign (ie. if I had time
for it at all), I would just start from scratch, without GnuPG. I would
use a library like PGPy (probably forking it, because so far upstream
has not been very responsive) and implement what's missing (mostly
HKPS/WKD, ECC, keyring management, and GnuPG interoperability).

But I don't have time for this, at all. So someone else will need to do
it. Otherwise, I'll just do like everyone else does and use pius or
caff.

I'm sorry about this. I know it sucks to have a piece of software you
use on a daily basis just disappear from under you. But there are real
people, mostly volunteers, behind those projects, and they need your
support. A little "thank you" goes a long way, already, and it's
something anyone can do. But we also need real work and hours into
projects, otherwise they will die, just like that.

I hope that clarifies, again, the situation with monkeysign and wish you
the best of luck in your future endeavors.

A.

-- 
To understand how any society functions you must understand the
relationship between the men and the women
                        - Angela Davis


From wk at gnupg.org  Sun Mar 22 20:55:23 2020
From: wk at gnupg.org (Werner Koch)
Date: Sun, 22 Mar 2020 20:55:23 +0100
Subject: WKS server problems
In-Reply-To: <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com> (Andrew
 Gallagher's message of "Sun, 22 Mar 2020 12:36:42 +0000")
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
Message-ID: <87r1xk6u6s.fsf@wheatstone.g10code.de>

On Sun, 22 Mar 2020 12:36, Andrew Gallagher said:
> On 22/03/2020 05:38, john doe wrote:
>> Do you have enough entropy on the VM?
>
> Argh, thank you. I thought I had enough entropy because monkeysphere
> created its trust root without issue, but installing haveged did fix the
> problem.

You might be better off using this:

--8<---------------cut here---------------start------------->8---
$ cat /etc/gcrypt/random.conf
# Options for the random generator

# We don't trust the the Jitter based thing -  do not use it.
#disable-jent

only-urandom

--8<---------------cut here---------------end--------------->8---

instead if the very brittle and CPU dependent haveged.  On any decent
Linux urandom is good enough.  Right at some early boot stages and on a
fresh or not properly shutdown system, it might have too less entropy.
But if you have such concerns you should anyway use the latest Libgcrypt
which does not only mix in RDRAND but als entropy from its own
JitterRNG.


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: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200322/dc55e1c0/attachment.sig>

From wiktor at metacode.biz  Sun Mar 22 20:22:54 2020
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Sun, 22 Mar 2020 20:22:54 +0100
Subject: monkeysign removal from bullseye
In-Reply-To: <bc2aa837-750b-d26a-9ab3-14f10f770baa@andrewg.com>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <c291a293c61651064ce9db040be88102e32cbf59.camel@gentoo.org>
 <3aef17ce-269f-6974-b964-2d78aeddb3b7@andrewg.com>
 <e17914f6-2c59-39a9-68d4-003be6f138d0@mail.com>
 <bc2aa837-750b-d26a-9ab3-14f10f770baa@andrewg.com>
Message-ID: <806e5728-09fb-3830-1049-681a4d813f51@metacode.biz>

Hi Andrew,

On 22.03.2020 19:01, Andrew Gallagher wrote:
> Come back to me when there is a fully scriptable interface to gpg.
> Monkeysign abstracted away a*LOT*  of that pain.

Actually newer GnuPG already has a lot of interesting options. For key 
signing automation the most interesting one is "--quick-sign-key" that 
can sign a given UID in a key given by fingerprint.

Used like that:

https://github.com/wiktor-k/airsigner/blob/master/offline/sign-and-create-emails#L28

Monkeysign's README already notes that but OpenKeychain can also import 
and sign keys with its built-in QR code scanner. But that's probably not 
a direct replacement for monkeyscan.

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

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

From look at my.amazin.horse  Sun Mar 22 23:16:27 2020
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Sun, 22 Mar 2020 23:16:27 +0100
Subject: monkeysign removal from bullseye
In-Reply-To: <f5f55fa7-d703-291a-307d-29a16d0e0a5d@andrewg.com>
References: <f5f55fa7-d703-291a-307d-29a16d0e0a5d@andrewg.com>
 <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <87tv2ggxey.fsf@angela.anarc.at>
Message-ID: <26U7YWAKFF83U.3E1A9SE5CJ1OJ@my.amazin.horse>


Hi Andrew,

> I feel your pain. I've been trying for the past few years to knock
> together a menu-driven offline-key management interface[1] for PGP CAs,
> for use in corporate environments.

Have you seen openpgp-ca? It's an effort that sounds similar to what you are
describing, based on sequoia-pgp. They project is still in the requirements
engineering phase I believe, so if you have specific needs for a conrete use
case, your input may be very valuable to them:

https://gitlab.com/openpgp-ca/openpgp-ca

Cheers

 - V


From andrewg at andrewg.com  Mon Mar 23 10:12:21 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 23 Mar 2020 09:12:21 +0000
Subject: monkeysign removal from bullseye
In-Reply-To: <26U7YWAKFF83U.3E1A9SE5CJ1OJ@my.amazin.horse>
References: <f5f55fa7-d703-291a-307d-29a16d0e0a5d@andrewg.com>
 <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <87tv2ggxey.fsf@angela.anarc.at>
 <26U7YWAKFF83U.3E1A9SE5CJ1OJ@my.amazin.horse>
Message-ID: <f40c6975-fb01-cd8f-a7b1-f77cce899caa@andrewg.com>

On 22/03/2020 22:16, Vincent Breitmoser wrote:
> Have you seen openpgp-ca? It's an effort that sounds similar to what you are
> describing, based on sequoia-pgp.

That sounds very interesting, thank you!
A

-- 
Andrew Gallagher

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

From johndoe65534 at mail.com  Mon Mar 23 10:16:44 2020
From: johndoe65534 at mail.com (john doe)
Date: Mon, 23 Mar 2020 10:16:44 +0100
Subject: WKS server problems
In-Reply-To: <87r1xk6u6s.fsf@wheatstone.g10code.de>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
 <87r1xk6u6s.fsf@wheatstone.g10code.de>
Message-ID: <83465a10-bc28-90cc-a1bb-1a7c539e4976@mail.com>

On 3/22/2020 8:55 PM, Werner Koch via Gnupg-users wrote:
> On Sun, 22 Mar 2020 12:36, Andrew Gallagher said:
>> On 22/03/2020 05:38, john doe wrote:
>>> Do you have enough entropy on the VM?
>>
>> Argh, thank you. I thought I had enough entropy because monkeysphere
>> created its trust root without issue, but installing haveged did fix the
>> problem.
>
> You might be better off using this:
>
> --8<---------------cut here---------------start------------->8---
> $ cat /etc/gcrypt/random.conf
> # Options for the random generator
>
> # We don't trust the the Jitter based thing -  do not use it.
> #disable-jent
>
> only-urandom
>
> --8<---------------cut here---------------end--------------->8---
>
> instead if the very brittle and CPU dependent haveged.  On any decent
> Linux urandom is good enough.  Right at some early boot stages and on a
> fresh or not properly shutdown system, it might have too less entropy.
> But if you have such concerns you should anyway use the latest Libgcrypt
> which does not only mix in RDRAND but als entropy from its own
> JitterRNG.
>

Thank you Werner, I wrapped the above as an one liner:

$ mkdir -p /etc/gcrypt && printf "# Options for the random
generator\n#\n#
https://lists.gnupg.org/pipermail/gnupg-users/2020-March/063372.html\n#\n#
We don't trust the Jitter based thing -  do not use
it.\n#disable-jent\n\nonly-urandom\n" > /etc/gcrypt/random.conf


Note that this e-mail is folded by my mailer.

--
John Doe


From andrewg at andrewg.com  Mon Mar 23 10:40:50 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 23 Mar 2020 09:40:50 +0000
Subject: WKS server problems
In-Reply-To: <87r1xk6u6s.fsf@wheatstone.g10code.de>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
 <87r1xk6u6s.fsf@wheatstone.g10code.de>
Message-ID: <8dad5473-b9b9-8c73-93a9-aeda90efe5c9@andrewg.com>

On 22/03/2020 19:55, Werner Koch wrote:
> You might be better off using this:
...
> instead if the very brittle and CPU dependent haveged.

Thanks, Werner! That seems to work.

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Mon Mar 23 10:47:32 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 23 Mar 2020 09:47:32 +0000
Subject: monkeysign removal from bullseye
In-Reply-To: <806e5728-09fb-3830-1049-681a4d813f51@metacode.biz>
References: <66e62fc5-7c60-2cb4-c377-c2793e4a401b@andrewg.com>
 <c291a293c61651064ce9db040be88102e32cbf59.camel@gentoo.org>
 <3aef17ce-269f-6974-b964-2d78aeddb3b7@andrewg.com>
 <e17914f6-2c59-39a9-68d4-003be6f138d0@mail.com>
 <bc2aa837-750b-d26a-9ab3-14f10f770baa@andrewg.com>
 <806e5728-09fb-3830-1049-681a4d813f51@metacode.biz>
Message-ID: <1e66e7b5-ad3f-64c9-3b02-b7a9314733fa@andrewg.com>

On 22/03/2020 19:22, Wiktor Kwapisiewicz wrote:
> Actually newer GnuPG already has a lot of interesting options. For key
> signing automation the most interesting one is "--quick-sign-key" that
> can sign a given UID in a key given by fingerprint.

This will be very useful in the future, thanks. The --quick-* options
are a great help. Unfortunately I'm trying to maintain a package that's
compatible with stable .deb distros so I can't rely upon new features
until the distros bump...

-- 
Andrew Gallagher


From wk at gnupg.org  Mon Mar 23 13:01:53 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Mar 2020 13:01:53 +0100
Subject: WKS server problems
In-Reply-To: <83465a10-bc28-90cc-a1bb-1a7c539e4976@mail.com> (john doe's
 message of "Mon, 23 Mar 2020 10:16:44 +0100")
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
 <87r1xk6u6s.fsf@wheatstone.g10code.de>
 <83465a10-bc28-90cc-a1bb-1a7c539e4976@mail.com>
Message-ID: <87d093700e.fsf@wheatstone.g10code.de>

On Mon, 23 Mar 2020 10:16, john doe said:

> Thank you Werner, I wrapped the above as an one liner:

This is even easier.

$ mkdir -p /etc/gcrypt && echo only-urandom>/etc/gcrypt/random.conf

The '#' lines are merely comments to show which other options are
available.


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: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200323/b39d972c/attachment-0001.sig>

From johndoe65534 at mail.com  Mon Mar 23 16:58:19 2020
From: johndoe65534 at mail.com (john doe)
Date: Mon, 23 Mar 2020 16:58:19 +0100
Subject: WKS server problems
In-Reply-To: <87d093700e.fsf@wheatstone.g10code.de>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
 <87r1xk6u6s.fsf@wheatstone.g10code.de>
 <83465a10-bc28-90cc-a1bb-1a7c539e4976@mail.com>
 <87d093700e.fsf@wheatstone.g10code.de>
Message-ID: <3805099b-026a-3009-b92c-573b78a81924@mail.com>

On 3/23/2020 1:01 PM, Werner Koch wrote:
> On Mon, 23 Mar 2020 10:16, john doe said:
>
>> Thank you Werner, I wrapped the above as an one liner:
>
> This is even easier.
>
> $ mkdir -p /etc/gcrypt && echo only-urandom>/etc/gcrypt/random.conf
>
> The '#' lines are merely comments to show which other options are
> available.
>
>
> Shalom-Salam,
>

Actually, I just reinstalled the Stretch VM in question to test the
above option and I'm back to square one.

$ gpg --version
gpg (GnuPG) 2.1.18
libgcrypt 1.7.6-beta


Is it not working because of a too old release?

--
John Doe


From andrewg at andrewg.com  Mon Mar 23 17:21:20 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 23 Mar 2020 16:21:20 +0000
Subject: WKS server problems
In-Reply-To: <3805099b-026a-3009-b92c-573b78a81924@mail.com>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
 <87r1xk6u6s.fsf@wheatstone.g10code.de>
 <83465a10-bc28-90cc-a1bb-1a7c539e4976@mail.com>
 <87d093700e.fsf@wheatstone.g10code.de>
 <3805099b-026a-3009-b92c-573b78a81924@mail.com>
Message-ID: <722693a8-36a2-0ec2-3efc-99a36172c65d@andrewg.com>

On 23/03/2020 15:58, john doe wrote:
> $ gpg --version
> gpg (GnuPG) 2.1.18
> libgcrypt 1.7.6-beta
> 
> Is it not working because of a too old release?

Yes, that's FAR too old. :-) You need to dist-upgrade to buster.

-- 
Andrew Gallagher

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

From johndoe65534 at mail.com  Mon Mar 23 17:52:40 2020
From: johndoe65534 at mail.com (john doe)
Date: Mon, 23 Mar 2020 17:52:40 +0100
Subject: WKS server problems
In-Reply-To: <722693a8-36a2-0ec2-3efc-99a36172c65d@andrewg.com>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
 <87r1xk6u6s.fsf@wheatstone.g10code.de>
 <83465a10-bc28-90cc-a1bb-1a7c539e4976@mail.com>
 <87d093700e.fsf@wheatstone.g10code.de>
 <3805099b-026a-3009-b92c-573b78a81924@mail.com>
 <722693a8-36a2-0ec2-3efc-99a36172c65d@andrewg.com>
Message-ID: <961ba305-8e5c-753a-beaf-64faae715761@mail.com>

On 3/23/2020 5:21 PM, Andrew Gallagher wrote:
> On 23/03/2020 15:58, john doe wrote:
>> $ gpg --version
>> gpg (GnuPG) 2.1.18
>> libgcrypt 1.7.6-beta
>>
>> Is it not working because of a too old release?
>
> Yes, that's FAR too old. :-) You need to dist-upgrade to buster.
>

I'll go back to using havege then as I need to generate a gpg key for
testing purposes on this VM.

I thought that 'only-urandom' could be used as an replacement of haveged
on this Stretch VM, looks like I misunderstood when to use this option.

--
John Doe


From andrewg at andrewg.com  Mon Mar 23 18:42:22 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 23 Mar 2020 17:42:22 +0000
Subject: WKS server problems
In-Reply-To: <961ba305-8e5c-753a-beaf-64faae715761@mail.com>
References: <5a68f3c8-d5b0-7ab9-6e1a-4cb4afa84bce@andrewg.com>
 <4d58e96f-d792-3101-4aaf-bbe40b941296@mail.com>
 <319095a7-7c17-2bc0-d383-565617e8d7f0@andrewg.com>
 <87r1xk6u6s.fsf@wheatstone.g10code.de>
 <83465a10-bc28-90cc-a1bb-1a7c539e4976@mail.com>
 <87d093700e.fsf@wheatstone.g10code.de>
 <3805099b-026a-3009-b92c-573b78a81924@mail.com>
 <722693a8-36a2-0ec2-3efc-99a36172c65d@andrewg.com>
 <961ba305-8e5c-753a-beaf-64faae715761@mail.com>
Message-ID: <2ca1a7ac-c1df-b275-1915-0906abc1b3da@andrewg.com>

On 23/03/2020 16:52, john doe wrote:
> I thought that 'only-urandom' could be used as an replacement of haveged
> on this Stretch VM, looks like I misunderstood when to use this option.

Try it anyway, debian often backport newer features if they have
security implications (dkg should be able to tell you definitively).

-- 
Andrew Gallagher

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

From gus at torproject.org  Thu Mar 26 22:55:49 2020
From: gus at torproject.org (gus)
Date: Thu, 26 Mar 2020 17:55:49 -0400
Subject: Error running auto-key-locate wkd in Windows 10
Message-ID: <20200326215415.GL1301@localhost>

Hi,

I'm trying to fetch a key using wkd in Windows 10. I installed
Gpg4win[1], but when I run this command:

  gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser at torproject.org

I get this error:

  gpg: error retrieving 'torbrowser at torproject.org' via WKD: Ricevuto un
  messaggio di avviso fatale 
  gpg: error reading key: Ricevuto un messaggio di avviso fatale

The same command works fine in Debian 10. Running the command above with
'gpg --verbose' mode wasn't helpful. I searched another key using a
specific keyserver and worked, so Gpg4win seems to work. Thoughts?

Thanks!
Gus

[1] Gpg4win 3.1.11 (Released: 2019-12-17) 
-- 
The Tor Project
Community Team Lead
http://expyuzz4wqqyqhjn.onion/


From wk at gnupg.org  Fri Mar 27 09:48:01 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 27 Mar 2020 09:48:01 +0100
Subject: Error running auto-key-locate wkd in Windows 10
In-Reply-To: <20200326215415.GL1301@localhost> (gus's message of "Thu, 26 Mar
 2020 17:55:49 -0400")
References: <20200326215415.GL1301@localhost>
Message-ID: <87mu822nge.fsf@wheatstone.g10code.de>

On Thu, 26 Mar 2020 17:55, gus said:

>   gpg: error retrieving 'torbrowser at torproject.org' via WKD: Ricevuto
> un
>   messaggio di avviso fatale 
>   gpg: error reading key: Ricevuto un messaggio di avviso fatale

That is: "Fatal alert message received" which comes from the TLS
layer.  To see the actual cause you need to add

  log-file /some/file
  tls-debug 2

or a higher level to dirmngr.conf and "gpgconf --reload dirmngr".  For
me a

  gpg --locate-external-keys -v torbrowser at torproject.org

(--locate-external-key is easier to type than yours.  It excludes the
 local keys and thus always goes out to the WKD) then gives:
  
  DBG: ntbtls(2): got an alert message, type: [2:40]
  DBG: ntbtls(1): is a fatal alert message (msg 40)
  DBG: ntbtls(1): (handshake failed)
  DBG: ntbtls(1): read_record returned: Fatal alert message received <TLS>
  DBG: ntbtls(2): handshake ready
  TLS handshake failed: Fatal alert message received <TLS>
  error connecting to 'https://openpgpkey.tor[...]

A reason for the failed handhake might be that no common parameters
could be found.  We would need to look at the server log or run tests
with that server to see what it expects.  I copy the full TLS log below.
I have no GNUTLS based build currently available, if that works, it log
could give also some conclusion.  However, on Windows we always use
NTBTLS.



Salam-Shalom,

   Werner


--8<---------------cut here---------------start------------->8---
DBG: ntbtls(2): handshake
DBG: ntbtls(2): client state: 0 (hello_request)
DBG: ntbtls(3): flush output
DBG: ntbtls(2): client state: 1 (client_hello)
DBG: ntbtls(3): flush output
DBG: ntbtls(2): write client_hello
DBG: ntbtls(3): client_hello, max version: [3:3]
DBG: ntbtls(3): client_hello, current time: 1585298512
DBG: client_hello, random bytes: 5e7dbc5008b76aa83d09c4393a4bdbe792ad9fee5198c6d9f88357ad16020156
DBG: ntbtls(3): client_hello, session id len.: 0
DBG: client_hello, session id: 
DBG: ntbtls(5): client_hello, add ciphersuite: 49192 TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite:   107 TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49172 TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:    57 TLS-DHE-RSA-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49271 TLS-ECDHE-RSA-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite:   196 TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   136 TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49191 TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   103 TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49171 TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:    51 TLS-DHE-RSA-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49270 TLS-ECDHE-RSA-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   190 TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:    69 TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49170 TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:    22 TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49208 TLS-ECDHE-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite:   179 TLS-DHE-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 49206 TLS-ECDHE-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:   145 TLS-DHE-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49307 TLS-ECDHE-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 49303 TLS-DHE-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 49207 TLS-ECDHE-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   178 TLS-DHE-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49205 TLS-ECDHE-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:   144 TLS-DHE-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49302 TLS-DHE-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49306 TLS-ECDHE-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49204 TLS-ECDHE-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:   143 TLS-DHE-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:    61 TLS-RSA-WITH-AES-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:    53 TLS-RSA-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:   192 TLS-RSA-WITH-CAMELLIA-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   132 TLS-RSA-WITH-CAMELLIA-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:    60 TLS-RSA-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:    47 TLS-RSA-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:   186 TLS-RSA-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:    65 TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:    10 TLS-RSA-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:   183 TLS-RSA-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite:   149 TLS-RSA-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49305 TLS-RSA-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite:   182 TLS-RSA-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   148 TLS-RSA-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49304 TLS-RSA-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   147 TLS-RSA-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite:   175 TLS-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite:   141 TLS-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49301 TLS-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite:   174 TLS-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   140 TLS-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49300 TLS-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite:   139 TLS-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(3): client_hello, got 54 ciphersuites
DBG: ntbtls(3): client_hello, compress len.: 2
DBG: ntbtls(3): client_hello, compress alg.: 1 0
DBG: ntbtls(3): client_hello, adding server name extension: 'openpgpkey.torproject.org'
DBG: ntbtls(3): client_hello, adding signature_algorithms extension
DBG: ntbtls(3): client hello, adding supported_elliptic_curves extension
DBG: ntbtls(3): client hello, adding supported_point_formats extension
DBG: ntbtls(3): client_hello, adding session ticket extension
DBG: ntbtls(3): client_hello, total extension length: 88
DBG: ntbtls(3): write record
DBG: ntbtls(3): output record: msgtype = 22, version = [3:3], msglen = 242
DBG: output record sent to network: 16030300f2010000ee03035e7dbc5008b76aa83d09c4393a4bdbe792ad9fee51 \
DBG:                                98c6d9f88357ad1602015600006c00ffc028006bc0140039c07700c40088c027 \
DBG:                                0067c0130033c07600be0045c0120016c03800b3c0360091c09bc097c03700b2 \
DBG:                                c0350090c096c09ac034008f003d003500c00084003c002f00ba0041000a00b7 \
DBG:                                0095c09900b60094c098009300af008dc09500ae008cc094008b020100005800 \
DBG:                                00001e001c0000196f70656e7067706b65792e746f7270726f6a6563742e6f72 \
DBG:                                67000d001600140601050104010301020106030503040303030203000a000e00 \
DBG:                                0c001700180019001a001b001c000b0002010000230000
DBG: ntbtls(3): flush output
DBG: ntbtls(3): message length: 247, out_left: 247
DBG: ntbtls(3): es_write returned: success
DBG: ntbtls(2): client state: 2 (server_hello)
DBG: ntbtls(3): flush output
DBG: ntbtls(2): read server_hello
DBG: ntbtls(3): read record
DBG: ntbtls(3): fetch input
DBG: ntbtls(3): in_left: 0, nb_want: 5
DBG: ntbtls(3): es_read returned: success
DBG: ntbtls(3): input record: msgtype = 21, version = [3:3], msglen = 2
DBG: ntbtls(3): fetch input
DBG: ntbtls(3): in_left: 5, nb_want: 7
DBG: ntbtls(3): es_read returned: success
DBG: input record from network: 15030300020228
DBG: ntbtls(2): got an alert message, type: [2:40]
DBG: ntbtls(1): is a fatal alert message (msg 40)
DBG: ntbtls(1): (handshake failed)
DBG: ntbtls(1): read_record returned: Fatal alert message received <TLS>
DBG: ntbtls(2): handshake ready
TLS handshake failed: Fatal alert message received <TLS>
error connecting to 'https://openpgpkey.torproject.org/.well-known/openpgpkey/torproject.org/hu/kounek7zrdx745qydx6p59t9mqjpuhdf?l=torbrowser': Fatal alert message received
DBG: ntbtls(2): release
command 'WKD_GET' failed: Fatal alert message received <TLS>
--8<---------------cut here---------------end--------------->8---


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

From kloecker at kde.org  Fri Mar 27 15:42:39 2020
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Fri, 27 Mar 2020 15:42:39 +0100
Subject: Error running auto-key-locate wkd in Windows 10
In-Reply-To: <87mu822nge.fsf@wheatstone.g10code.de>
References: <20200326215415.GL1301@localhost>
 <87mu822nge.fsf@wheatstone.g10code.de>
Message-ID: <14554773.31YW1QerDo@thufir>

On Freitag, 27. M?rz 2020 09:48:01 CET Werner Koch via Gnupg-users wrote:
> That is: "Fatal alert message received" which comes from the TLS
> layer.  To see the actual cause you need to add
> 
>   log-file /some/file
>   tls-debug 2
> 
> or a higher level to dirmngr.conf and "gpgconf --reload dirmngr".  For
> me a
> 
>   gpg --locate-external-keys -v torbrowser at torproject.org
> 
> (--locate-external-key is easier to type than yours.  It excludes the
>  local keys and thus always goes out to the WKD) then gives:
> 
>   DBG: ntbtls(2): got an alert message, type: [2:40]
>   DBG: ntbtls(1): is a fatal alert message (msg 40)
>   DBG: ntbtls(1): (handshake failed)
>   DBG: ntbtls(1): read_record returned: Fatal alert message received <TLS>
>   DBG: ntbtls(2): handshake ready
>   TLS handshake failed: Fatal alert message received <TLS>
>   error connecting to 'https://openpgpkey.tor[...]
> 
> A reason for the failed handhake might be that no common parameters
> could be found.

Probably, no matching cipher suite. According to ssllabs.com/ssltest 
openpgpkey.torproject.org (well, at least one of the actual servers) only 
supports the following cipher suites:
# TLS 1.3 (server has no preference)
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

# TLS 1.2 (server has no preference)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

I think none of those matches any of those in the output of ntbtls in your 
message.

Regards,
Ingo





From gus at torproject.org  Sat Mar 28 03:37:52 2020
From: gus at torproject.org (gus)
Date: Fri, 27 Mar 2020 22:37:52 -0400
Subject: Error running auto-key-locate wkd in Windows 10
In-Reply-To: <14554773.31YW1QerDo@thufir>
References: <20200326215415.GL1301@localhost>
 <87mu822nge.fsf@wheatstone.g10code.de> <14554773.31YW1QerDo@thufir>
Message-ID: <20200328023752.GN1301@localhost>

On Fri, Mar 27, 2020 at 03:42:39PM +0100, Ingo Kl?cker wrote:
> On Freitag, 27. M?rz 2020 09:48:01 CET Werner Koch via Gnupg-users wrote:
> > That is: "Fatal alert message received" which comes from the TLS
> > layer.  To see the actual cause you need to add
> > 
> >   log-file /some/file
> >   tls-debug 2
> > 
> > or a higher level to dirmngr.conf and "gpgconf --reload dirmngr".  For
> > me a
> > 
> >   gpg --locate-external-keys -v torbrowser at torproject.org
> > 
> > (--locate-external-key is easier to type than yours.  It excludes the
> >  local keys and thus always goes out to the WKD) then gives:
> > 
> >   DBG: ntbtls(2): got an alert message, type: [2:40]
> >   DBG: ntbtls(1): is a fatal alert message (msg 40)
> >   DBG: ntbtls(1): (handshake failed)
> >   DBG: ntbtls(1): read_record returned: Fatal alert message received <TLS>
> >   DBG: ntbtls(2): handshake ready
> >   TLS handshake failed: Fatal alert message received <TLS>
> >   error connecting to 'https://openpgpkey.tor[...]
> > 
> > A reason for the failed handhake might be that no common parameters
> > could be found.
> 
> Probably, no matching cipher suite. According to ssllabs.com/ssltest 
> openpgpkey.torproject.org (well, at least one of the actual servers) only 
> supports the following cipher suites:
> # TLS 1.3 (server has no preference)
> TLS_AES_128_GCM_SHA256
> TLS_AES_256_GCM_SHA384
> TLS_CHACHA20_POLY1305_SHA256
> 
> # TLS 1.2 (server has no preference)
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> 
> I think none of those matches any of those in the output of ntbtls in your 
> message.
> 
> Regards,
> Ingo
> 

It was a ciphersuite change on our server, and it's fixed now.

Thanks all!

Gus

-- 
The Tor Project
Community Team Lead
http://expyuzz4wqqyqhjn.onion/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200327/61607f75/attachment.sig>