From wk at gnupg.org  Fri May  3 10:42:49 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 May 2019 10:42:49 +0200
Subject: Trust model tofu+pgp and User ID in Signer's UID packet
In-Reply-To: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> (Wiktor
 Kwapisiewicz via Gnupg-devel's message of "Thu, 25 Apr 2019 13:48:18
 +0200")
References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz>
Message-ID: <87lfzo53p2.fsf@wheatstone.g10code.de>

On Thu, 25 Apr 2019 13:48, gnupg-devel at gnupg.org said:

> As I've seen previously OpenKeychain embeds full User ID as Signer's
> UID (that is "John Doe <john at example.com>") but GnuPG users only

They should not do that becuase only the addrspec identifies the user.
The real name in a mail address is often changed.

> e-mail ("john at example.com"). It seems when GnuPG encounters Signer's
> UID in full form it cannot get TOFU validity.

Right, in gpg the user id from the signature is only sanitized of bad
characters and then used verbatim.  Using only the addrspec part, if it
exists, is a better idea.  I 'll change that for 2.2.


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-devel/attachments/20190503/0114d8a3/attachment.sig>

From wk at gnupg.org  Fri May  3 10:57:00 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 May 2019 10:57:00 +0200
Subject: Trust model tofu+pgp and User ID in Signer's UID packet
In-Reply-To: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> (Wiktor
 Kwapisiewicz via Gnupg-devel's message of "Thu, 25 Apr 2019 13:48:18
 +0200")
References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz>
Message-ID: <87h8ab6hlv.fsf@wheatstone.g10code.de>

Hi,

the attached patch is for master but it should also apply to 2.2.  Would
you be so kind and give it a try?

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gpg-Use-just-the-addrspec-from-the-Signer-s-UID.patch
Type: text/x-diff
Size: 1721 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190503/85ee7bb8/attachment-0001.patch>
-------------- 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-devel/attachments/20190503/85ee7bb8/attachment-0001.sig>

From wiktor at metacode.biz  Fri May  3 13:20:30 2019
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Fri, 3 May 2019 13:20:30 +0200
Subject: Trust model tofu+pgp and User ID in Signer's UID packet
In-Reply-To: <87h8ab6hlv.fsf@wheatstone.g10code.de>
References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz>
 <87h8ab6hlv.fsf@wheatstone.g10code.de>
Message-ID: <9bf14ef6-e13f-e482-49d7-92bec115c9ed@metacode.biz>

Hi Werner,

On 03.05.2019 10:57, Werner Koch wrote:
> the attached patch is for master but it should also apply to 2.2.  Would
> you be so kind and give it a try?

I did try it on master and yes, it does work.

The message printed changes from (before patch):

gpg: Good signature from "John Doe <john at example.com>" [full]
gpg: WARNING: We do NOT trust this key!
gpg:          The signature is probably a FORGERY.

To this (after patching):

gpg: Good signature from "John Doe <john at example.com>" [full]
gpg: john at example.com: Verified 2 signatures in the past 59 minutes.
      Encrypted 0 messages.

Thanks for the quick fix!

For the record it seems there is a minor issue when the patch is applied 
on 2.2.15 as mailbox_from_userid changed the number of arguments.

Kind regards,
Wiktor

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

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

From wk at gnupg.org  Fri May  3 15:49:31 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 May 2019 15:49:31 +0200
Subject: Trust model tofu+pgp and User ID in Signer's UID packet
In-Reply-To: <9bf14ef6-e13f-e482-49d7-92bec115c9ed@metacode.biz> (Wiktor
 Kwapisiewicz's message of "Fri, 3 May 2019 13:20:30 +0200")
References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz>
 <87h8ab6hlv.fsf@wheatstone.g10code.de>
 <9bf14ef6-e13f-e482-49d7-92bec115c9ed@metacode.biz>
Message-ID: <87y33n4phw.fsf@wheatstone.g10code.de>

On Fri,  3 May 2019 13:20, wiktor at metacode.biz said:

> I did try it on master and yes, it does work.

Thanks for testing.

> For the record it seems there is a minor issue when the patch is
> applied on 2.2.15 as mailbox_from_userid changed the number of
> arguments.

Possible, I didn't tried.


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-devel/attachments/20190503/768c6edb/attachment.sig>

From wk at gnupg.org  Fri May  3 16:10:48 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 May 2019 16:10:48 +0200
Subject: Is ECC ready and increase the default RSA key size to 3072 bits?
In-Reply-To: <201904250842.18173.bernhard@intevation.de> (Bernhard Reiter's
 message of "Thu, 25 Apr 2019 08:42:13 +0200")
References: <20190418072148.GN1226@zeromail.org>
 <87o952xfxm.fsf@fifthhorseman.net>
 <201904250842.18173.bernhard@intevation.de>
Message-ID: <87r29f4oif.fsf@wheatstone.g10code.de>

On Thu, 25 Apr 2019 08:42, bernhard at intevation.de said:

> Is ECC ready to be the default?
> My estimation is: It is not, and then we should switch the default to RSA3072
> until it is.

2.3 will use ed25519/cv25519 as default algorithms for new keys.  All
other major implementations support ed25519 and thus we are ready to
switch this summer.


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-devel/attachments/20190503/509172e6/attachment.sig>

From wk at gnupg.org  Fri May  3 16:18:21 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 May 2019 16:18:21 +0200
Subject: [PATCH] doc: clarify dirmngr use-tor documentation
In-Reply-To: <20190419142149.8679-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Fri, 19 Apr 2019 10:21:49 -0400")
References: <20190419142149.8679-1-dkg@fifthhorseman.net>
Message-ID: <87muk34o5u.fsf@wheatstone.g10code.de>

On Fri, 19 Apr 2019 10:21, dkg at fifthhorseman.net said:

> reloading dirmngr wouldn't allow me to clear --use-tor.  Does that
> mean i just need to restart dirmngr to clear --use-tor, instead of
> reloading?  Is that a deliberate design decision, or an accident of
> implementation?  If it's deliberate, what do i (as a user) gain from

Right.  You need to restart dirmngr and it is not sufficient to SIGHUP
it.  This is to make it extra hard to bypass Tor if it has been used
before in this session.

> -or even be reloading gpg-agent.  The use of @option{--no-use-tor}
> +or even by reloading dirmngr.  The use of @option{--no-use-tor}

Thanks.  Fixed.


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-devel/attachments/20190503/f0e33220/attachment.sig>

From wk at gnupg.org  Fri May  3 16:26:23 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 May 2019 16:26:23 +0200
Subject: Storing key on multiple smartcards
In-Reply-To: <87pnpeodk1.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of
 "Mon, 22 Apr 2019 13:43:10 +0900")
References: <b41b05b6-39ac-d744-718e-3adf280459c5@tsundere.moe>
 <87tvf6loi8.fsf@iwagami.gniibe.org>
 <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
 <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com>
 <b299a2ce-784a-5e29-3195-3c8dd5d16093@tsundere.moe>
 <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com>
 <e1ebddc3-e9ec-59e7-7f08-50d44fa5903c@tsundere.moe>
 <87zhomg44u.fsf@iwagami.gniibe.org>
 <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe>
 <87pnpeodk1.fsf@iwagami.gniibe.org>
Message-ID: <87imur4nsg.fsf@wheatstone.g10code.de>

On Mon, 22 Apr 2019 13:43, gniibe at fsij.org said:

> Then, we don't need the serial number as shadow-info in private key file.

The information is also used to prompt the user to insert a specific
card.  The serial number is a good way to identify a card because it is
printed onto the card.  However some configurable way to name a card is
also useful.

I am currently working on recording all serial numbers used with a token
based key in the shadow key info file.  The new format allows easy
manual editing of that info and also allows to put a "Label:" line into
the the file to be prompted with e.g. "The green token on my keyring".


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-devel/attachments/20190503/4fad0287/attachment.sig>

From dkg at fifthhorseman.net  Fri May  3 16:50:01 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 03 May 2019 10:50:01 -0400
Subject: [PATCH] doc: clarify dirmngr use-tor documentation
In-Reply-To: <87muk34o5u.fsf@wheatstone.g10code.de>
References: <20190419142149.8679-1-dkg@fifthhorseman.net>
 <87muk34o5u.fsf@wheatstone.g10code.de>
Message-ID: <87k1f7oana.fsf@fifthhorseman.net>

On Fri 2019-05-03 16:18:21 +0200, Werner Koch wrote:
> On Fri, 19 Apr 2019 10:21, dkg at fifthhorseman.net said:
>
>> reloading dirmngr wouldn't allow me to clear --use-tor.  Does that
>> mean i just need to restart dirmngr to clear --use-tor, instead of
>> reloading?  Is that a deliberate design decision, or an accident of
>> implementation?  If it's deliberate, what do i (as a user) gain from
>
> Right.  You need to restart dirmngr and it is not sufficient to SIGHUP
> it.  This is to make it extra hard to bypass Tor if it has been used
> before in this session.

Thanks for thinking about this!

This isn't "extra hard" though -- it just means "gpgconf --kill dirmngr"
instead of "gpgconf --reload dirmngr", right?  (or SIGTERM instead of
SIGHUP)

Is this marginal increase in "hardness" worth the additional confusion
and complexity in configuration?

    --dkg
-------------- 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-devel/attachments/20190503/b0bd4083/attachment-0001.sig>

From robbat2 at gentoo.org  Mon May  6 06:25:23 2019
From: robbat2 at gentoo.org (Robin H. Johnson)
Date: Mon, 6 May 2019 04:25:23 +0000
Subject: Storing key on multiple smartcards
In-Reply-To: <87imur4nsg.fsf@wheatstone.g10code.de>
References: <87tvf6loi8.fsf@iwagami.gniibe.org>
 <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
 <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com>
 <b299a2ce-784a-5e29-3195-3c8dd5d16093@tsundere.moe>
 <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com>
 <e1ebddc3-e9ec-59e7-7f08-50d44fa5903c@tsundere.moe>
 <87zhomg44u.fsf@iwagami.gniibe.org>
 <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe>
 <87pnpeodk1.fsf@iwagami.gniibe.org>
 <87imur4nsg.fsf@wheatstone.g10code.de>
Message-ID: <robbat2-20190506T042319-608663283Z@orbis-terrarum.net>

On Fri, May 03, 2019 at 04:26:23PM +0200, Werner Koch wrote:
> On Mon, 22 Apr 2019 13:43, gniibe at fsij.org said:
> 
> > Then, we don't need the serial number as shadow-info in private key file.
> 
> The information is also used to prompt the user to insert a specific
> card.  The serial number is a good way to identify a card because it is
> printed onto the card.  However some configurable way to name a card is
> also useful.
It's NOT always printed on cards. I have multiple NitroKey Pro units,
and aside from my own labelling, there are no unit-specific identifiers
on the units themselves, or even on the internal cards.

Consider me entirely in favour of being able to specify an arbitrary
label.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2 at gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1113 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190506/30be08d1/attachment.sig>

From bernhard at intevation.de  Mon May  6 08:55:05 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 6 May 2019 08:55:05 +0200
Subject: Is ECC ready and increase the default RSA key size to 3072 bits?
In-Reply-To: <87r29f4oif.fsf@wheatstone.g10code.de>
References: <20190418072148.GN1226@zeromail.org>
 <201904250842.18173.bernhard@intevation.de>
 <87r29f4oif.fsf@wheatstone.g10code.de>
Message-ID: <201905060855.05674.bernhard@intevation.de>

Am Freitag 03 Mai 2019 16:10:48 schrieb Werner Koch:
> On Thu, 25 Apr 2019 08:42, bernhard at intevation.de said:
> > Is ECC ready to be the default?
> > My estimation is: It is not, and then we should switch the default to
> > RSA3072 until it is.
>
> 2.3 will use ed25519/cv25519 as default algorithms for new keys. ?All
> other major implementations support ed25519 and thus we are ready to
> switch this summer.

What will the status of a 2.3.0 release be?
(Is it a "development" line or ready for packaging?)

Would it make sense to announce the step so people could flag potential 
implementations that may be interesting from an interoperability side?

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190506/983f632d/attachment.sig>

From gniibe at fsij.org  Tue May  7 03:21:41 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 07 May 2019 10:21:41 +0900
Subject: Storing key on multiple smartcards
In-Reply-To: <87imur4nsg.fsf@wheatstone.g10code.de>
References: <b41b05b6-39ac-d744-718e-3adf280459c5@tsundere.moe>
 <87tvf6loi8.fsf@iwagami.gniibe.org>
 <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
 <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com>
 <b299a2ce-784a-5e29-3195-3c8dd5d16093@tsundere.moe>
 <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com>
 <e1ebddc3-e9ec-59e7-7f08-50d44fa5903c@tsundere.moe>
 <87zhomg44u.fsf@iwagami.gniibe.org>
 <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe>
 <87pnpeodk1.fsf@iwagami.gniibe.org> <87imur4nsg.fsf@wheatstone.g10code.de>
Message-ID: <871s1bnjoa.fsf@iwagami.gniibe.org>

Hello,

I merged the scdaemon change of mine to master.  Now,
PKSIGN/PKAUTH/PKDECRYPT command can be used with KEYGRIP directly, and
it is scdaemon which selects card (among possibly multiple cards).

Werner Koch <wk at gnupg.org> wrote:
> The information is also used to prompt the user to insert a specific
> card.  The serial number is a good way to identify a card because it is
> printed onto the card.  However some configurable way to name a card is
> also useful.
>
> I am currently working on recording all serial numbers used with a token
> based key in the shadow key info file.  The new format allows easy
> manual editing of that info and also allows to put a "Label:" line into
> the the file to be prompted with e.g. "The green token on my keyring".

Yes.  Support of label (and serial number) is orthogonal to ongoing
change of mine.

			*	*	*

My plan to change gpg-agent is: By gpg-agent's offering private key
information in a better way, gpg frontend can be modified to select
a key easier (so that user can have better UI).

Now, gpg-agent KEYINFO command is like this:

# KEYINFO [--[ssh-]list] [--data] [--ssh-fpr[=algo]] [--with-ssh] <keygrip>
# 
# Return information about the key specified by the KEYGRIP.  If the
# key is not available GPG_ERR_NOT_FOUND is returned.  If the option
# --list is given the keygrip is ignored and information about all
# available keys are returned.  If --ssh-list is given information
# about all keys listed in the sshcontrol are returned.  With --with-ssh
# information from sshcontrol is always added to the info. Unless --data
# is given, the information is returned as a status line using the format:
# 
#   KEYINFO <keygrip> <type> <serialno> <idstr> <cached> <protection> <fpr>
# 
# KEYGRIP is the keygrip.
# 
# TYPE is describes the type of the key:
#     'D' - Regular key stored on disk,
#     'T' - Key is stored on a smartcard (token),
#     'X' - Unknown type,
#     '-' - Key is missing.
# 
# SERIALNO is an ASCII string with the serial number of the
#          smartcard.  If the serial number is not known a single
#          dash '-' is used instead.
# 
# IDSTR is the IDSTR used to distinguish keys on a smartcard.  If it
#       is not known a dash is used instead.
# 
# CACHED is 1 if the passphrase for the key was found in the key cache.
#        If not, a '-' is used instead.
# 
# PROTECTION describes the key protection type:
#     'P' - The key is protected with a passphrase,
#     'C' - The key is not protected,
#     '-' - Unknown protection.
# 
# FPR returns the formatted ssh-style fingerprint of the key.  It is only
#     printed if the option --ssh-fpr has been used.  If ALGO is not given
#     to that option the default ssh fingerprint algo is used.  Without the
#     option a '-' is printed.
# 
# TTL is the TTL in seconds for that key or '-' if n/a.
# 
# FLAGS is a word consisting of one-letter flags:
#       'D' - The key has been disabled,
#       'S' - The key is listed in sshcontrol (requires --with-ssh),
#       'c' - Use of the key needs to be confirmed,
#       '-' - No flags given.
# 
# More information may be added in the future.

I'm going to modify this, to distinguish a key on card which is
inserted, and a key on card which is not inserted.  This can be either:

(1) For key on inserted card, add another flag into FLAGS (say, 'A' for
    active),

or

(2) Introduce new TYPE (say, 'O' for offline) and change the semantics
of 'T' meaning inserted card.


Currently, both of gpg frontend and gpg-agent need to have code of loop
for enumerating active cards.  Using KEYINFO command of scdaemon,
gpg-agent can merge card key information and disk key information.
-- 


From andrewg at andrewg.com  Tue May  7 16:14:10 2019
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 7 May 2019 15:14:10 +0100
Subject: poldi localdb structure
Message-ID: <fd821366-ff07-d5b3-0d7b-f2d22bc00ea7@andrewg.com>

Hi, all.

I just installed poldi on a new laptop for the first time in a while,
and noticed that the structure of the localdb is unfriendly,
particularly now that the command line tools are no longer available.

At the moment, an entry is added to the `users` file mapping a userid
onto a card id, and then a file is created under `keys` that maps the
card id to the public key.

Surely it makes more sense to map the userid directly onto the public
key (cf. monkeysphere's `authorized_user_ids`), and then let scdaemon
worry about which card contains the private key material?

And if we're going that direction, why not use monkeysphere's user
keyring as the localdb? O_o

-- 
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-devel/attachments/20190507/4e7c446f/attachment.sig>

From wk at gnupg.org  Wed May  8 08:18:57 2019
From: wk at gnupg.org (Werner Koch)
Date: Wed, 08 May 2019 08:18:57 +0200
Subject: [PATCH] doc: clarify dirmngr use-tor documentation
In-Reply-To: <87k1f7oana.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Fri, 03 May 2019 10:50:01 -0400")
References: <20190419142149.8679-1-dkg@fifthhorseman.net>
 <87muk34o5u.fsf@wheatstone.g10code.de>
 <87k1f7oana.fsf@fifthhorseman.net>
Message-ID: <87bm0d1nam.fsf@wheatstone.g10code.de>

On Fri,  3 May 2019 10:50, dkg at fifthhorseman.net said:

> This isn't "extra hard" though -- it just means "gpgconf --kill dirmngr"
> instead of "gpgconf --reload dirmngr", right?  (or SIGTERM instead of
> SIGHUP)

GPA and Kleopatra can do an reload automatically on changing an option.
They don't provide a GUI element to restart dirmngr.

> Is this marginal increase in "hardness" worth the additional confusion
> and complexity in configuration?

Probably not; we may change it in 2.3


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-devel/attachments/20190508/a6865ca2/attachment-0001.sig>

From wk at gnupg.org  Wed May  8 08:26:04 2019
From: wk at gnupg.org (Werner Koch)
Date: Wed, 08 May 2019 08:26:04 +0200
Subject: Storing key on multiple smartcards
In-Reply-To: <871s1bnjoa.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of
 "Tue, 07 May 2019 10:21:41 +0900")
References: <b41b05b6-39ac-d744-718e-3adf280459c5@tsundere.moe>
 <87tvf6loi8.fsf@iwagami.gniibe.org>
 <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
 <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com>
 <b299a2ce-784a-5e29-3195-3c8dd5d16093@tsundere.moe>
 <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com>
 <e1ebddc3-e9ec-59e7-7f08-50d44fa5903c@tsundere.moe>
 <87zhomg44u.fsf@iwagami.gniibe.org>
 <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe>
 <87pnpeodk1.fsf@iwagami.gniibe.org>
 <87imur4nsg.fsf@wheatstone.g10code.de>
 <871s1bnjoa.fsf@iwagami.gniibe.org>
Message-ID: <877eb11myr.fsf@wheatstone.g10code.de>

On Tue,  7 May 2019 10:21, gniibe at fsij.org said:

> # TYPE is describes the type of the key:
> #     'D' - Regular key stored on disk,
> #     'T' - Key is stored on a smartcard (token),
> #     'X' - Unknown type,
> #     '-' - Key is missing.
> # 
> # SERIALNO is an ASCII string with the serial number of the
> #          smartcard.  If the serial number is not known a single
> #          dash '-' is used instead.
> # 
> # IDSTR is the IDSTR used to distinguish keys on a smartcard.  If it
> #       is not known a dash is used instead.
> # 
> # CACHED is 1 if the passphrase for the key was found in the key cache.
> #        If not, a '-' is used instead.
> # 
> # PROTECTION describes the key protection type:
> #     'P' - The key is protected with a passphrase,
> #     'C' - The key is not protected,
> #     '-' - Unknown protection.
> # 
> # FPR returns the formatted ssh-style fingerprint of the key.  It is only
> #     printed if the option --ssh-fpr has been used.  If ALGO is not given
> #     to that option the default ssh fingerprint algo is used.  Without the
> #     option a '-' is printed.
> # 
> # TTL is the TTL in seconds for that key or '-' if n/a.
> # 
> # FLAGS is a word consisting of one-letter flags:
> #       'D' - The key has been disabled,
> #       'S' - The key is listed in sshcontrol (requires --with-ssh),
> #       'c' - Use of the key needs to be confirmed,
> #       '-' - No flags given.
> # 
> # More information may be added in the future.
>
> I'm going to modify this, to distinguish a key on card which is
> inserted, and a key on card which is not inserted.  This can be either:
>
> (1) For key on inserted card, add another flag into FLAGS (say, 'A' for
>     active),

I think that is the proper solution. 

> (2) Introduce new TYPE (say, 'O' for offline) and change the semantics
> of 'T' meaning inserted card.

Alsthough I don't think we will run into problems with that it is not as
clear as using an extra flag.



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-devel/attachments/20190508/dcc1e3a8/attachment.sig>

From dkg at fifthhorseman.net  Wed May  8 13:57:42 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 08 May 2019 07:57:42 -0400
Subject: [PATCH] doc: clarify dirmngr use-tor documentation
In-Reply-To: <87bm0d1nam.fsf@wheatstone.g10code.de>
References: <20190419142149.8679-1-dkg@fifthhorseman.net>
 <87muk34o5u.fsf@wheatstone.g10code.de> <87k1f7oana.fsf@fifthhorseman.net>
 <87bm0d1nam.fsf@wheatstone.g10code.de>
Message-ID: <87ef59yx8p.fsf@fifthhorseman.net>

On Wed 2019-05-08 08:18:57 +0200, Werner Koch wrote:
> On Fri,  3 May 2019 10:50, dkg at fifthhorseman.net said:
>
>> This isn't "extra hard" though -- it just means "gpgconf --kill dirmngr"
>> instead of "gpgconf --reload dirmngr", right?  (or SIGTERM instead of
>> SIGHUP)
>
> GPA and Kleopatra can do an reload automatically on changing an option.
> They don't provide a GUI element to restart dirmngr.

so if you change this option in GPA or Kleopatra, it doesn't actually
change?  That sounds perplexing.

>> Is this marginal increase in "hardness" worth the additional confusion
>> and complexity in configuration?
>
> Probably not; we may change it in 2.3

Thanks.  I've opened https://dev.gnupg.org/T4488 to track this issue.

         --dkg
-------------- 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-devel/attachments/20190508/3d129af0/attachment.sig>

From dirk.gottschalk1980 at googlemail.com  Wed May  8 15:23:08 2019
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Wed, 08 May 2019 15:23:08 +0200
Subject: Trust deepths (tsign)
Message-ID: <ee3a1932a9d0a94f158a1fd1e0d27c4d0c8638fe.camel@googlemail.com>

Hi all.

As we all know, with tsign, you can set a trust deepth and a trust
domain.

I did not find any way to change this options afterwards. Is this
intented?

Bernhard Reiter suggested I should ask this question on the developers
list.

I know, one can delete the key, reimport it an set a new trust lebel,
but this seems not to be the best way, IMHO.

Regards,
Dirk

-- 
Dirk Gottschalk
Ardennenstrasse 25
52076 Aachen, Germany

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac


-------------- 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-devel/attachments/20190508/832c4604/attachment.sig>

From dgouttegattat at incenp.org  Wed May  8 17:16:35 2019
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 8 May 2019 16:16:35 +0100
Subject: Trust deepths (tsign)
In-Reply-To: <ee3a1932a9d0a94f158a1fd1e0d27c4d0c8638fe.camel@googlemail.com>
References: <ee3a1932a9d0a94f158a1fd1e0d27c4d0c8638fe.camel@googlemail.com>
Message-ID: <20190508151634.6rdzfxikduwa5cds@CHS-TMB-078.qmcr.qmul.ac.uk>

Hi,

On Wed, May 08, 2019 at 03:23:08PM +0200, Dirk Gottschalk via Gnupg-devel wrote:
>As we all know, with tsign, you can set a trust deepth and a trust
>domain.
>
>I did not find any way to change this options afterwards. Is this
>intented?

Yes. A trust signature (tsign) is first and foremost, well, a signature.  
You cannot change it after it has been emitted.


>I know, one can delete the key, reimport it an set a new trust lebel,
>but this seems not to be the best way, IMHO.

If the trust signature is only present on your own keyring (meaning that 
after signing the key you have not sent it back to its owner, or 
uploaded to a keyserver, or published it in any way), then you can 
simply delete the trust signature (`delsig` command in gpg's key 
editor).

Otherwise, if the signature is already out, then there's no point in 
removing it from your keyring (any later refresh from a keyserver would 
import the signature back). What you can do instead is to *revoke* the 
first signature and then emit a new trust signature.

Hope that helps,

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190508/182445e9/attachment.sig>

From look at my.amazin.horse  Sun May 12 12:36:55 2019
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Sun, 12 May 2019 12:36:55 +0200
Subject: [PATCH GnuPG 1/2] gpg: fix fpr comparison in keyserver screener
In-Reply-To: <20190512103655.25693-1-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
Message-ID: <20190512103655.25693-2-look@my.amazin.horse>

* g10/keyserver.c (keyserver_retrieval_screener): Only compare actual
fpr_len
---
 g10/keyserver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/keyserver.c b/g10/keyserver.c
index 04802d1a5..5b5cf1c13 100644
--- a/g10/keyserver.c
+++ b/g10/keyserver.c
@@ -1055,7 +1055,7 @@ keyserver_retrieval_screener (kbnode_t keyblock, void *opaque)
         {
           if (desc[n].mode == KEYDB_SEARCH_MODE_FPR)
             {
-              if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, 32))
+              if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, fpr_len))
                 return 0;
             }
           else if (desc[n].mode == KEYDB_SEARCH_MODE_LONG_KID)
-- 
2.20.1



From look at my.amazin.horse  Sun May 12 12:36:54 2019
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Sun, 12 May 2019 12:36:54 +0200
Subject: [PATCH gpg] allow import without user ids
Message-ID: <20190512103655.25693-1-look@my.amazin.horse>

This patch allows import of keys that have no user ids, if they are already
known. This allows update of subkeys, revocation certificates, etc from sources
that don't deal with user ids. See also https://dev.gnupg.org/T4393

Second commit is simple bugfix to the keyserver screener, which memcmp'd 32
bytes rather than the actual length of the fpr to compare.

Signed-Off-By: Vincent Breitmoser <look at my.amazin.horse>




From look at my.amazin.horse  Sun May 12 12:36:56 2019
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Sun, 12 May 2019 12:36:56 +0200
Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys,
 even without UIDs
In-Reply-To: <20190512103655.25693-1-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
Message-ID: <20190512103655.25693-3-look@my.amazin.horse>

* g10/import.c (import_one): Allow import of keys that have no user ids,
if we already know them.  Keys are still rejected if they contained
invalid user ids, or none that pass a given filter criteria.
---
 g10/import.c | 21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/g10/import.c b/g10/import.c
index 00bc47cc1..89ec18840 100644
--- a/g10/import.c
+++ b/g10/import.c
@@ -1806,16 +1806,6 @@ import_one (ctrl_t ctrl,
       log_printf ("\n");
     }
 
-
-  /* Unless import-drop-uids has been requested we don't allow import
-   * of a key without UIDs.  */
-  if (!uidnode && !(options & IMPORT_DROP_UIDS))
-    {
-      if (!silent)
-        log_error( _("key %s: no user ID\n"), keystr_from_pk(pk));
-      return 0;
-    }
-
   if (screener && screener (keyblock, screener_arg))
     {
       log_error (_("key %s: %s\n"), keystr_from_pk (pk),
@@ -1888,9 +1878,9 @@ import_one (ctrl_t ctrl,
     }
 
   /* Delete invalid parts and without the drop option bail out if
-   * there are no user ids.  */
+   * there were user ids, but none was actually valid.  */
   if (!delete_inv_parts (ctrl, keyblock, keyid, options)
-      && !(options & IMPORT_DROP_UIDS) )
+      && uidnode && !(options & IMPORT_DROP_UIDS) )
     {
       if (!silent)
         {
@@ -1985,6 +1975,13 @@ import_one (ctrl_t ctrl,
       err = 0;
       stats->skipped_new_keys++;
     }
+  else if (err && !uidnode && !(options & IMPORT_DROP_UIDS) )
+    {
+      if (!silent)
+        log_info( _("key %s: new key but contains no user ID - skipped\n"), keystr(keyid));
+      err = 0;
+      stats->no_user_id++;
+    }
   else if (err)  /* Insert this key. */
     {
       /* Note: ERR can only be NO_PUBKEY or UNUSABLE_PUBKEY.  */
-- 
2.20.1



From dkg at fifthhorseman.net  Mon May 13 18:19:20 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 13 May 2019 12:19:20 -0400
Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys,
 even without UIDs
In-Reply-To: <20190512103655.25693-3-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
 <20190512103655.25693-3-look@my.amazin.horse>
Message-ID: <871s12wcmv.fsf@fifthhorseman.net>

Thanks for this series, Vincent!  I like the motivation behind it.  I
think it is concretely useful to import an OpenPGP certificate as part
of a merge even if the incoming cert does not have a
cryptographically-valid self-sig over any user ID.

This permits the use of public keystores that perform the "redacting
User IDs" mitigation described at
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-5.1

In particular, it allows gpg to perform "Certificate Update with
Redacted User IDs":
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-5.1.1

(other operations later in section 5.1 that might involve synthesizing
user IDs are not yet supported, even with this patch, and that's ok)

It would be great to add a test to the test suite for this behavior --
to show what does *not* work before the patch is applied, and then to
have the test suite succeed after the patches are applied.  This would
also help us avoid regressions on this behavior in the future.

For example, here is a severely stripped down OpenPGP certificate.  Just
a primary key and one user ID and a self-sig:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: [A] primary key, user ID, and self-sig expiring in 2021

mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
631VAN20CHRlc3Qga2V5iJYEExYIAD4WIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC
XNmUGQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAIQ9qWmqja
+0G1AQDdQiwhXxjXLMqoth+D4SigVHTJK8ORwifzsy3UE7mPGwD/aZ67XbAF/lgI
kv2O1Jo0u9BL9RNNF+L0DM7rAFbfMAs=
=1eII
-----END PGP PUBLIC KEY BLOCK-----

Here is a cert for the same primary key, but with a subkey and no user
ID attached:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: [B] primary key, subkey, subkey binding sig (no user ID)

mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK
j++lwwWDAOlkVicDAQgHiHgEGBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC
XNmUIQIbDAAKCRAIQ9qWmqja++vFAP98G1L+1/rWTGbsnxOAV2RocBYIroAvsbkR
Ly6FdP8YNwEA7jOgT05CoKIe37MstpOz23mM80AK369Ca3JMmKKCQgg=
=xuDu
-----END PGP PUBLIC KEY BLOCK-----

And here is a cert for the same primary key, with the user ID packet
stripped entirely, but with updated self-sig (issued after the initial
one) that contains a later expiration date over that same user ID:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: [C] primary key and self-sig expiring in 2024 (no user ID)

mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
631VAN2IlgQTFggAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBLRpj5W8
2H/gSMzKKQhD2paaqNr7BQJc2ZR1BQkJZgHcAAoJEAhD2paaqNr79soA/0lWkUsu
3NLwgbni6EzJxnTzgeNMpljqNpipHAwfix9hAP93AVtFdC8g7hdUZxawobl9lnSN
9ohXOEBWvdJgVv2YAg==
=KWIK
-----END PGP PUBLIC KEY BLOCK-----


If i do "gpg --import" on A, then B, then C, and then i do "gpg
--edit-key test clean save" and "gpg --list-keys", i think gpg display
have a merged certificate that expires in 2024, and has a subkey, like
this:

    pub   ed25519 2019-05-13 [SC] [expires: 2024-05-11]
          B4698F95BCD87FE048CCCA290843DA969AA8DAFB
    uid           [ unknown] test key
    sub   cv25519 2019-05-13 [E]

but in practice, the imports of both B and C fail with:

    gpg: key 0843DA969AA8DAFB: no user ID

and the result is instead the same as if only A were present:

    pub   ed25519 2019-05-13 [SC] [expires: 2021-05-12]
          B4698F95BCD87FE048CCCA290843DA969AA8DAFB
    uid           [ unknown] test key


Feel free to use these example objects in the test suite if that's
useful.

On Sun 2019-05-12 12:36:56 +0200, Vincent Breitmoser wrote:
> * g10/import.c (import_one): Allow import of keys that have no user ids,
> if we already know them.  Keys are still rejected if they contained
> invalid user ids, or none that pass a given filter criteria.

Your commit message here doesn't seem to match the intent of this patch,
for several reasons:

 * It talks about several different keys, but it would be good to
   clarify in each circumstance whether we're talking about:
   
   a) the known copy of the OpenPGP certificate,
   b) the incoming copy of the OpenPGP certificate, or
   c) the merged copy of the OpenPGP certificate.

 * "contained invalid user ids" is different from "contained no valid
   user IDs"

 * "validity" for user IDs in the OpenPGP typically means something
   subtly different from "has a cryptographically correct self-sig from
   the primary key". It would be good to avoid mixing those up.

As a nit-pick, i'd also convert the description to refer to the
certificate in the singular instead of plural where possible, because
it's easier to read and make sense of (esp. when the cert itself might
have multiple elements internally).

rewriting to what i *think* the intent of the series is, i'd have
written it this way:


* g10/import.c (import_one): Accept an incoming OpenPGP certificate that
has no user id, as long as we already have a local variant of the cert
that matches the primary key.  Import still fails if the resulting
merged certificate contains no self-signed user ids that pass any given
filter criteria.


Is this your intent?

   --dkg

-------------- 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-devel/attachments/20190513/46e699b6/attachment-0001.sig>

From ilf at zeromail.org  Mon May 13 19:35:10 2019
From: ilf at zeromail.org (ilf)
Date: Mon, 13 May 2019 19:35:10 +0200
Subject: Keyservers and GDPR
In-Reply-To: <20180523092715.GC1663@zeromail.org>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
Message-ID: <20190513173510.GA24471@zeromail.org>

Almost one year ago, there was a big debate about the GDPR and 
keyservers. 

Now I would like to know: Did any keyserver admin(s) receive any 
(serious) GDPR-related complaint? Or even an official complaint by a 
data protection authority? Or even a penalty like a fine?

I assume not, at least for the latter two.

The fines by German DPAs have been rather low: 
https://www.welt.de/finanzen/article193326155/DSGVO-Verstoesse-Bundeslaender-ziehen-Bussgeld-Bilanz.html

So far, I stand by last year's statement:

> tl;dr: Keep calm and keep running keyservers.

-- 
ilf

If you upload your address book to "the cloud", I don't want to be in it.
-------------- 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-devel/attachments/20190513/f492f691/attachment.sig>

From dkg at fifthhorseman.net  Mon May 13 19:44:11 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 13 May 2019 13:44:11 -0400
Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys,
 even without UIDs
In-Reply-To: <871s12wcmv.fsf@fifthhorseman.net>
References: <20190512103655.25693-1-look@my.amazin.horse>
 <20190512103655.25693-3-look@my.amazin.horse>
 <871s12wcmv.fsf@fifthhorseman.net>
Message-ID: <87sgtiuu50.fsf@fifthhorseman.net>

On Mon 2019-05-13 12:19:20 -0400, Daniel Kahn Gillmor wrote:
> It would be great to add a test to the test suite for this behavior --
> to show what does *not* work before the patch is applied, and then to
> have the test suite succeed after the patches are applied.  This would
> also help us avoid regressions on this behavior in the future.

Following up on this test regime, here are 2 additional OpenPGP
certificates that use the same primary key and lack user IDs, but
dealing with revocations of key material:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: [D] primary key, subkey, subkey revocation (no user ID)

mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK
j++lwwWDAOlkVicDAQgHiHgEKBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC
XNmnkAIdAgAKCRAIQ9qWmqja+ylaAQDmIKf86BJEq4OpDqU+V9D+wn2cyuxbyWVQ
3r9LiL9qNwD/QAjyrhSN8L3Mfq+wdTHo5i0yB9ZCCpHLXSbhCqfWZwQ=
=dwx2
-----END PGP PUBLIC KEY BLOCK-----


-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: [E] primary key, revocation signature over primary (no user ID)

mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
631VAN2IeAQgFggAIBYhBLRpj5W82H/gSMzKKQhD2paaqNr7BQJc2ZQZAh0AAAoJ
EAhD2paaqNr7qAwA/2jBUpnN0BxwRO/4CrxvrLIsL+C9aSXJUOTv8XkP4lvtAQD3
XsDFfFNgEueiTfF7HtOGt5LPmRqVvUpQSMVgJJW6CQ==
=tM90
-----END PGP PUBLIC KEY BLOCK-----

I believe that failing to import these revocation certificates
represents a security risk to users of GnuPG, because it means leaving
the user with a certificate that GnuPG knows is revoked, but it is left
unrevoked.

        --dkg
-------------- 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-devel/attachments/20190513/d9482e34/attachment.sig>

From dkg at fifthhorseman.net  Mon May 13 21:38:23 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 13 May 2019 15:38:23 -0400
Subject: [PATCH GnuPG 1/2] gpg: fix fpr comparison in keyserver screener
In-Reply-To: <20190512103655.25693-2-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
 <20190512103655.25693-2-look@my.amazin.horse>
Message-ID: <87lfzauouo.fsf@fifthhorseman.net>

On Sun 2019-05-12 12:36:55 +0200, Vincent Breitmoser wrote:
> * g10/keyserver.c (keyserver_retrieval_screener): Only compare actual
> fpr_len
> ---
>  g10/keyserver.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/g10/keyserver.c b/g10/keyserver.c
> index 04802d1a5..5b5cf1c13 100644
> --- a/g10/keyserver.c
> +++ b/g10/keyserver.c
> @@ -1055,7 +1055,7 @@ keyserver_retrieval_screener (kbnode_t keyblock, void *opaque)
>          {
>            if (desc[n].mode == KEYDB_SEARCH_MODE_FPR)
>              {
> -              if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, 32))
> +              if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, fpr_len))
>                  return 0;
>              }
>            else if (desc[n].mode == KEYDB_SEARCH_MODE_LONG_KID)

fwiw, this looks like it is only relevant on the master branch
(presumably used for testing v5 keys?) -- the STABLE-BRANCH-2-2 branch
doesn't have this stanza.

aiui, Vincent is saying here that uninitialized memory might be compared
here in the case of a v4 fingerprint.  I haven't tested this myself.

I'd recommend considering this as a distinct change from the other patch
in this series, rather than treating them as interdependent.

     --dkg
-------------- 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-devel/attachments/20190513/41e01f0c/attachment.sig>

From wk at gnupg.org  Wed May 15 07:30:54 2019
From: wk at gnupg.org (Werner Koch)
Date: Wed, 15 May 2019 07:30:54 +0200
Subject: [PATCH GnuPG 1/2] gpg: fix fpr comparison in keyserver screener
In-Reply-To: <87lfzauouo.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Mon, 13 May 2019 15:38:23 -0400")
References: <20190512103655.25693-1-look@my.amazin.horse>
 <20190512103655.25693-2-look@my.amazin.horse>
 <87lfzauouo.fsf@fifthhorseman.net>
Message-ID: <87pnokthbl.fsf@wheatstone.g10code.de>

On Mon, 13 May 2019 15:38, dkg at fifthhorseman.net said:

> aiui, Vincent is saying here that uninitialized memory might be compared
> here in the case of a v4 fingerprint.  I haven't tested this myself.

Yep, the keyserver screen does not yet work in master.


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-devel/attachments/20190515/3775cc30/attachment.sig>

From gniibe at fsij.org  Thu May 16 01:58:23 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 16 May 2019 08:58:23 +0900
Subject: Storing key on multiple smartcards
In-Reply-To: <871s1bnjoa.fsf@iwagami.gniibe.org>
References: <b41b05b6-39ac-d744-718e-3adf280459c5@tsundere.moe>
 <87tvf6loi8.fsf@iwagami.gniibe.org>
 <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
 <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com>
 <b299a2ce-784a-5e29-3195-3c8dd5d16093@tsundere.moe>
 <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com>
 <e1ebddc3-e9ec-59e7-7f08-50d44fa5903c@tsundere.moe>
 <87zhomg44u.fsf@iwagami.gniibe.org>
 <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe>
 <87pnpeodk1.fsf@iwagami.gniibe.org> <87imur4nsg.fsf@wheatstone.g10code.de>
 <871s1bnjoa.fsf@iwagami.gniibe.org>
Message-ID: <87sgtf1d9c.fsf@iwagami.gniibe.org>

Hello,

Before changing the output of KEYINFO command of gpg-agent (for T4244),
I modified gpg-agent to relax the assumption/requirment of the map
between serialno and keys.  In GnuPG, so far, there used to be an
assumption that serialno determines.

Now, by the master commit of 1091f22511e1a8259eb5c998f5c207ee95723a4a ,
we can use a token for backup which has different serialno.

I think that T4301 (using backup key in a different token) is now
handled.

I think that a bit more changes will be needed for better UI.  For now,
it is only possible to use back up token, when the token is active
(after gpg --card-status [all]).  Perhaps, it is better if KEYINFO
command of scdaemon initiates card/token scanning at first.  Let us
consider more.

T3416 would include other use cases.  For using signing backup key in a
different token, it should work well.  For something like selecting key
in an active token, gpg-frontend changes are needed as well.  I keep
considering about that.  If any suggestion for a good solution, please
let me know.
-- 


From look at my.amazin.horse  Tue May 21 20:03:08 2019
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 21 May 2019 20:03:08 +0200
Subject: [PATCH v2 GnuPG] allow import without user ids
In-Reply-To: <20190512103655.25693-1-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
Message-ID: <20190521180310.32443-1-look@my.amazin.horse>

I included dkg's testing series, as expected the test only passes once the
second patch is applied.

Only three out of five of dkg's files are currently used: import of subkey
revocations that have no binding signature, as well as out-of-place user id
signatures,  is out of scope for this patch. I included the others anyways,
since may be userful later on (without regenerating the whole series).

I also noticed that the way I handled invalid uids before didn't make much
sense: just because there is some invalid uid in a key, doesn't mean
cryptographically valid new packets can't be imported. I changed the patch to
reflect that.

Signed-Off-By: Vincent Breitmoser <look at my.amazin.horse>




From look at my.amazin.horse  Tue May 21 20:03:09 2019
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 21 May 2019 20:03:09 +0200
Subject: [PATCH GnuPG 1/2] tests: Add test case for import without uid
In-Reply-To: <20190521180310.32443-1-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
 <20190521180310.32443-1-look@my.amazin.horse>
Message-ID: <20190521180310.32443-2-look@my.amazin.horse>

---
 tests/openpgp/Makefile.am                     |  1 +
 tests/openpgp/import-incomplete.scm           | 53 +++++++++++++++++++
 .../import-incomplete/primary+revocation.asc  |  9 ++++
 .../primary+subkey+sub-revocation.asc         | 10 ++++
 .../import-incomplete/primary+subkey.asc      | 10 ++++
 .../import-incomplete/primary+uid-sig.asc     | 10 ++++
 .../openpgp/import-incomplete/primary+uid.asc | 10 ++++
 7 files changed, 103 insertions(+)
 create mode 100755 tests/openpgp/import-incomplete.scm
 create mode 100644 tests/openpgp/import-incomplete/primary+revocation.asc
 create mode 100644 tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc
 create mode 100644 tests/openpgp/import-incomplete/primary+subkey.asc
 create mode 100644 tests/openpgp/import-incomplete/primary+uid-sig.asc
 create mode 100644 tests/openpgp/import-incomplete/primary+uid.asc

diff --git a/tests/openpgp/Makefile.am b/tests/openpgp/Makefile.am
index e5be42b41..d886bc8f7 100644
--- a/tests/openpgp/Makefile.am
+++ b/tests/openpgp/Makefile.am
@@ -78,6 +78,7 @@ XTESTS = \
 	gpgv-forged-keyring.scm \
 	armor.scm \
 	import.scm \
+	import-incomplete.scm \
 	import-revocation-certificate.scm \
 	ecc.scm \
 	4gb-packet.scm \
diff --git a/tests/openpgp/import-incomplete.scm b/tests/openpgp/import-incomplete.scm
new file mode 100755
index 000000000..d40229362
--- /dev/null
+++ b/tests/openpgp/import-incomplete.scm
@@ -0,0 +1,53 @@
+#!/usr/bin/env gpgscm
+
+;; Copyright (C) 2016 g10 Code GmbH
+;;
+;; This file is part of GnuPG.
+;;
+;; GnuPG is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; GnuPG is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with this program; if not, see <http://www.gnu.org/licenses/>.
+
+(load (in-srcdir "tests" "openpgp" "defs.scm"))
+(setup-environment)
+
+(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+uid.asc")))
+
+(info "Test import of new subkey, from a certificate without uid")
+(define keyid "573EA710367356BB")
+(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+subkey.asc")))
+(tr:do
+ (tr:pipe-do
+  (pipe:gpg `(--list-keys --with-colons ,keyid)))
+ (tr:call-with-content
+  (lambda (c)
+    ;; XXX we do not have a regexp library
+    (unless (any (lambda (line)
+		   (and (string-prefix? line "sub:")
+			(string-contains? line "573EA710367356BB")))
+		 (string-split-newlines c))
+	    (exit 1)))))
+
+(info "Test import of revocation, from a certificate without uid")
+(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+revocation.asc")))
+(tr:do
+ (tr:pipe-do
+  (pipe:gpg `(--list-keys --with-colons ,keyid)))
+ (tr:call-with-content
+  (lambda (c)
+    ;; XXX we do not have a regexp library
+    (unless (any (lambda (line)
+		   (and (string-prefix? line "pub:r:")
+			(string-contains? line "0843DA969AA8DAFB")))
+		 (string-split-newlines c))
+	    (exit 1)))))
+
diff --git a/tests/openpgp/import-incomplete/primary+revocation.asc b/tests/openpgp/import-incomplete/primary+revocation.asc
new file mode 100644
index 000000000..6b7b60802
--- /dev/null
+++ b/tests/openpgp/import-incomplete/primary+revocation.asc
@@ -0,0 +1,9 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Comment: [E] primary key, revocation signature over primary (no user ID)
+
+mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
+631VAN2IeAQgFggAIBYhBLRpj5W82H/gSMzKKQhD2paaqNr7BQJc2ZQZAh0AAAoJ
+EAhD2paaqNr7qAwA/2jBUpnN0BxwRO/4CrxvrLIsL+C9aSXJUOTv8XkP4lvtAQD3
+XsDFfFNgEueiTfF7HtOGt5LPmRqVvUpQSMVgJJW6CQ==
+=tM90
+-----END PGP PUBLIC KEY BLOCK-----
diff --git a/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc b/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc
new file mode 100644
index 000000000..83a51a549
--- /dev/null
+++ b/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc
@@ -0,0 +1,10 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Comment: [D] primary key, subkey, subkey revocation (no user ID)
+
+mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
+631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK
+j++lwwWDAOlkVicDAQgHiHgEKBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC
+XNmnkAIdAgAKCRAIQ9qWmqja+ylaAQDmIKf86BJEq4OpDqU+V9D+wn2cyuxbyWVQ
+3r9LiL9qNwD/QAjyrhSN8L3Mfq+wdTHo5i0yB9ZCCpHLXSbhCqfWZwQ=
+=dwx2
+-----END PGP PUBLIC KEY BLOCK-----
diff --git a/tests/openpgp/import-incomplete/primary+subkey.asc b/tests/openpgp/import-incomplete/primary+subkey.asc
new file mode 100644
index 000000000..dc47a02d8
--- /dev/null
+++ b/tests/openpgp/import-incomplete/primary+subkey.asc
@@ -0,0 +1,10 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Comment: [B] primary key, subkey, subkey binding sig (no user ID)
+
+mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
+631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK
+j++lwwWDAOlkVicDAQgHiHgEGBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC
+XNmUIQIbDAAKCRAIQ9qWmqja++vFAP98G1L+1/rWTGbsnxOAV2RocBYIroAvsbkR
+Ly6FdP8YNwEA7jOgT05CoKIe37MstpOz23mM80AK369Ca3JMmKKCQgg=
+=xuDu
+-----END PGP PUBLIC KEY BLOCK-----
diff --git a/tests/openpgp/import-incomplete/primary+uid-sig.asc b/tests/openpgp/import-incomplete/primary+uid-sig.asc
new file mode 100644
index 000000000..134607d0e
--- /dev/null
+++ b/tests/openpgp/import-incomplete/primary+uid-sig.asc
@@ -0,0 +1,10 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Comment: [C] primary key and self-sig expiring in 2024 (no user ID)
+
+mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
+631VAN2IlgQTFggAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBLRpj5W8
+2H/gSMzKKQhD2paaqNr7BQJc2ZR1BQkJZgHcAAoJEAhD2paaqNr79soA/0lWkUsu
+3NLwgbni6EzJxnTzgeNMpljqNpipHAwfix9hAP93AVtFdC8g7hdUZxawobl9lnSN
+9ohXOEBWvdJgVv2YAg==
+=KWIK
+-----END PGP PUBLIC KEY BLOCK-----
diff --git a/tests/openpgp/import-incomplete/primary+uid.asc b/tests/openpgp/import-incomplete/primary+uid.asc
new file mode 100644
index 000000000..055f30086
--- /dev/null
+++ b/tests/openpgp/import-incomplete/primary+uid.asc
@@ -0,0 +1,10 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Comment: [A] primary key, user ID, and self-sig expiring in 2021
+
+mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
+631VAN20CHRlc3Qga2V5iJYEExYIAD4WIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC
+XNmUGQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAIQ9qWmqja
++0G1AQDdQiwhXxjXLMqoth+D4SigVHTJK8ORwifzsy3UE7mPGwD/aZ67XbAF/lgI
+kv2O1Jo0u9BL9RNNF+L0DM7rAFbfMAs=
+=1eII
+-----END PGP PUBLIC KEY BLOCK-----
-- 
2.20.1



From look at my.amazin.horse  Tue May 21 20:03:10 2019
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 21 May 2019 20:03:10 +0200
Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys,
 even without UIDs
In-Reply-To: <20190521180310.32443-1-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
 <20190521180310.32443-1-look@my.amazin.horse>
Message-ID: <20190521180310.32443-3-look@my.amazin.horse>

* g10/import.c (import_one): Accept an incoming OpenPGP certificate that
has no user id, as long as we already have a local variant of the cert
that matches the primary key.
---
 g10/import.c | 49 +++++++++++--------------------------------------
 1 file changed, 11 insertions(+), 38 deletions(-)

diff --git a/g10/import.c b/g10/import.c
index 00bc47cc1..2be214e63 100644
--- a/g10/import.c
+++ b/g10/import.c
@@ -1769,7 +1769,6 @@ import_one (ctrl_t ctrl,
   size_t an;
   char pkstrbuf[PUBKEY_STRING_SIZE];
   int merge_keys_done = 0;
-  int any_filter = 0;
   KEYDB_HANDLE hd = NULL;
 
   if (r_valid)
@@ -1806,16 +1805,6 @@ import_one (ctrl_t ctrl,
       log_printf ("\n");
     }
 
-
-  /* Unless import-drop-uids has been requested we don't allow import
-   * of a key without UIDs.  */
-  if (!uidnode && !(options & IMPORT_DROP_UIDS))
-    {
-      if (!silent)
-        log_error( _("key %s: no user ID\n"), keystr_from_pk(pk));
-      return 0;
-    }
-
   if (screener && screener (keyblock, screener_arg))
     {
       log_error (_("key %s: %s\n"), keystr_from_pk (pk),
@@ -1887,20 +1876,10 @@ import_one (ctrl_t ctrl,
 	  }
     }
 
-  /* Delete invalid parts and without the drop option bail out if
-   * there are no user ids.  */
-  if (!delete_inv_parts (ctrl, keyblock, keyid, options)
-      && !(options & IMPORT_DROP_UIDS) )
-    {
-      if (!silent)
-        {
-          log_error( _("key %s: no valid user IDs\n"), keystr_from_pk(pk));
-          if (!opt.quiet )
-            log_info(_("this may be caused by a missing self-signature\n"));
-        }
-      stats->no_user_id++;
-      return 0;
-    }
+  /* Delete invalid parts, and note if we have any valid ones left.
+   * We will later abort import if this key is new but contains
+   * no valid uids.  */
+  delete_inv_parts (ctrl, keyblock, keyid, options);
 
   /* Get rid of deleted nodes.  */
   commit_kbnode (&keyblock);
@@ -1910,24 +1889,11 @@ import_one (ctrl_t ctrl,
     {
       apply_keep_uid_filter (ctrl, keyblock, import_filter.keep_uid);
       commit_kbnode (&keyblock);
-      any_filter = 1;
     }
   if (import_filter.drop_sig)
     {
       apply_drop_sig_filter (ctrl, keyblock, import_filter.drop_sig);
       commit_kbnode (&keyblock);
-      any_filter = 1;
-    }
-
-  /* If we ran any filter we need to check that at least one user id
-   * is left in the keyring.  Note that we do not use log_error in
-   * this case. */
-  if (any_filter && !any_uid_left (keyblock))
-    {
-      if (!opt.quiet )
-        log_info ( _("key %s: no valid user IDs\n"), keystr_from_pk (pk));
-      stats->no_user_id++;
-      return 0;
     }
 
   /* The keyblock is valid and ready for real import.  */
@@ -1985,6 +1951,13 @@ import_one (ctrl_t ctrl,
       err = 0;
       stats->skipped_new_keys++;
     }
+  else if (err && !any_uid_left (keyblock) && !(options & IMPORT_DROP_UIDS) )
+    {
+      if (!silent)
+        log_info( _("key %s: new key but contains no user ID - skipped\n"), keystr(keyid));
+      err = 0;
+      stats->no_user_id++;
+    }
   else if (err)  /* Insert this key. */
     {
       /* Note: ERR can only be NO_PUBKEY or UNUSABLE_PUBKEY.  */
-- 
2.20.1



From dkg at fifthhorseman.net  Wed May 22 03:41:06 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 21 May 2019 21:41:06 -0400
Subject: [PATCH v2 GnuPG] allow import without user ids
In-Reply-To: <20190521180310.32443-1-look@my.amazin.horse>
References: <20190512103655.25693-1-look@my.amazin.horse>
 <20190521180310.32443-1-look@my.amazin.horse>
Message-ID: <87k1ej8dvx.fsf@fifthhorseman.net>

On Tue 2019-05-21 20:03:08 +0200, Vincent Breitmoser wrote:
> I included dkg's testing series, as expected the test only passes once the
> second patch is applied.

thanks for this, Vincent!

> Only three out of five of dkg's files are currently used: import of subkey
> revocations that have no binding signature, as well as out-of-place user id
> signatures,  is out of scope for this patch.

I think i understand why you think user ID self-sigs are out of scope
for this series -- they don't follow the user ID they're supposed to
follow, and they're not necessarily a security concern.

I don't understand why you think subkey revocation is out of scope for
this patch.

If i import primary+uid.asc followed by primary+subkey.asc after your
patch applies, then i should have a certificate with a functioning
subkey on it.  That's your first test, which is good.

But if i then import primary+subkey+sub-revocation.asc, the subkey
should show as revoked, no?  Otherwise, the user will believe that the
subkey is still valid.  That's a significant security issue, comparable
in some ways to the failed import of the revocation certificate in your
final test.

Could you add this subkey revocation test between the two tests?  You'd
be looking for a revoked subkey, i think.

> I also noticed that the way I handled invalid uids before didn't make much
> sense: just because there is some invalid uid in a key, doesn't mean
> cryptographically valid new packets can't be imported. I changed the patch to
> reflect that.

i think the changes you've made look good, but i confess that the logic
in the existing codebase is complex enough that i am not confident in my
ability to understand it, let alone these modifications.  Having the
test suite is super helpful here to reason about it.

     --dkg
-------------- 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-devel/attachments/20190521/2a02607a/attachment.sig>

From laurent.feron at free.fr  Wed May 22 13:21:45 2019
From: laurent.feron at free.fr (laurent.feron at free.fr)
Date: Wed, 22 May 2019 13:21:45 +0200 (CEST)
Subject: python + pgpme + openpgp card
In-Reply-To: <1165648916.210338268.1558524016984.JavaMail.root@spooler3-g27.priv.proxad.net>
Message-ID: <301808503.210340427.1558524105498.JavaMail.root@spooler3-g27.priv.proxad.net>

Hello,
It seems that I cannot manage keys on a card in Python language. Someone can confirm?
Regards
Laurent


From ilf at zeromail.org  Sat May 25 14:53:08 2019
From: ilf at zeromail.org (ilf)
Date: Sat, 25 May 2019 14:53:08 +0200
Subject: Keyservers and GDPR
In-Reply-To: <20190513173510.GA24471@zeromail.org>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
 <20190513173510.GA24471@zeromail.org>
Message-ID: <20190525125307.GA13759@zeromail.org>

FTR: I have not received a single reply. Happy GDPR day :)

ilf:
> Now I would like to know: Did any keyserver admin(s) receive any 
> (serious) GDPR-related complaint? Or even an official complaint by a 
> data protection authority? Or even a penalty like a fine?

-- 
ilf

If you upload your address book to "the cloud", I don't want to be in it.
-------------- 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-devel/attachments/20190525/9c31b42c/attachment.sig>

From wk at gnupg.org  Sun May 26 10:43:11 2019
From: wk at gnupg.org (Werner Koch)
Date: Sun, 26 May 2019 10:43:11 +0200
Subject: Keyservers and GDPR
In-Reply-To: <20190525125307.GA13759@zeromail.org> (ilf's message of "Sat, 25
 May 2019 14:53:08 +0200")
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
 <20190513173510.GA24471@zeromail.org>
 <20190525125307.GA13759@zeromail.org>
Message-ID: <87y32tmwrk.fsf@wheatstone.g10code.de>

On Sat, 25 May 2019 14:53, ilf at zeromail.org said:

> ilf:
>> Now I would like to know: Did any keyserver admin(s) receive any
>> (serious) GDPR-related complaint? Or even an official complaint by a
>> data protection authority? Or even a penalty like a fine?

You mean from the left over 5 servers in the default hkps pool:

 pgpkeys.eu       51.38.91.189    AS16276 (UK)
 pgpkeys.uk       192.146.137.98  AS57672 (UK)
 pgpkeys.co.uk    192.146.137.99  AS57672 (UK)
 fks.pgpkeys.eu   46.4.246.179    AS24940 (DE, Hetzner)
 keys2.kfwebs.net 37.191.231.105  AS57963 (NO) 

which according to rumours have only two or three different operators?


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-devel/attachments/20190526/526a2acf/attachment.sig>

From gnupg-devel at spodhuis.org  Mon May 27 04:39:09 2019
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Sun, 26 May 2019 22:39:09 -0400
Subject: Keyservers and GDPR
In-Reply-To: <87y32tmwrk.fsf@wheatstone.g10code.de>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
 <20190513173510.GA24471@zeromail.org>
 <20190525125307.GA13759@zeromail.org>
 <87y32tmwrk.fsf@wheatstone.g10code.de>
Message-ID: <20190527023908.GA20175@phil-pennock>

On 2019-05-26 at 10:43 +0200, Werner Koch wrote:
> On Sat, 25 May 2019 14:53, ilf at zeromail.org said:
> You mean from the left over 5 servers in the default hkps pool:
> 
>  pgpkeys.eu       51.38.91.189    AS16276 (UK)
>  pgpkeys.uk       192.146.137.98  AS57672 (UK)
>  pgpkeys.co.uk    192.146.137.99  AS57672 (UK)
>  fks.pgpkeys.eu   46.4.246.179    AS24940 (DE, Hetzner)
>  keys2.kfwebs.net 37.191.231.105  AS57963 (NO) 
> 
> which according to rumours have only two or three different operators?

My old SKS membership file had both pgpkeys.co.uk and pgpkeys.eu
maintained by Daniel Austin; the off-by-one for pgpkeys.uk suggests
Daniel runs that one too.  That covers the first four.

kfwebs.net is Kristian Fiskerstrand, who runs the pool tracking system
and sks-keyservers.net.

hkps is limited because Kristian doesn't hand out certs to anyone who
shows up with a new keyserver and asks; he tends to do so with people
who've been around and part of the community, because of the fairly
obvious problems with assuming TLS is buying you anything when entirely
unknown-to-others folks run the servers.  Kristian takes a lot of flak
for not giving people the power they want just because they ask for it.

With the various problems of SKS today, I tentatively suggest that not
defaulting to the HKPS pool and choosing a different target for the
keys.gnupg.net CNAME might be beneficial.

<https://sks-keyservers.net/overview-of-pools.php> has the criteria; I
suspect that >> subset.pool.sks-keyservers.net << is likely to be the
best choice for GnuPG; the meaning of "subset" changes over time,
picking newer servers, but for a while now that's been "updated SKS
software able to handle Curve25519 keys".

Spitballing crazy design now:

The only way to get back HKPS while still having diversity and yet still
some accountability is likely to be by requiring DNSSEC-signed
reverse-DNS which points to matching DNSSEC-signed forward DNS to prove
domain matching, and a trigger record in DNS indicating to use TLS; once
there's a forward-name which doesn't require central coordination, you
can verify normally and "anyone" can run a keyserver again.  With all
the pros and cons that entails.

GnuPG can pretty much define what it wants here.  Including changing the
URL scheme name if needed to avoid confusion.  TLSA records are
available for opportunistic TLS.  Effectively, "DANE for HKP with
work-arounds to handle the pool nature and bounce into a verifiable name
for arbitrary pool names".  Shove a TLSA record in reverse DNS to
indicate it's supported and you're good.  Hrm, probably don't strictly
need the reverse DNS to be DNSSEC-signed, as long as the
TLSA-or-other-marker is present and the forward DNS is still signed.

There's ways around it, but none of it will make folks who object to
DNSSEC happy.  Tough.

-Phil


From ilf at zeromail.org  Mon May 27 10:59:28 2019
From: ilf at zeromail.org (ilf)
Date: Mon, 27 May 2019 10:59:28 +0200
Subject: Keyservers and GDPR
In-Reply-To: <feba25b429240a9f2d2cb43f370f53351b80958d.camel@cryptobitch.de>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
 <20190513173510.GA24471@zeromail.org>
 <feba25b429240a9f2d2cb43f370f53351b80958d.camel@cryptobitch.de>
Message-ID: <20190527085928.GD882@zeromail.org>

Tobias Mueller:
>> So far, I stand by last year's statement:
>>> tl;dr: Keep calm and keep running keyservers.
> Are you standing by your statement because you believe that processing 
> that data is lawful or because you don't fear the consequences of a 
> potentially unlawful processing of data?

I stand by my statement because of the reasons I explained last year. 
https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html

-- 
ilf

If you upload your address book to "the cloud", I don't want to be in it.
-------------- 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-devel/attachments/20190527/92941f16/attachment-0001.sig>

From muelli at cryptobitch.de  Mon May 27 09:45:05 2019
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Mon, 27 May 2019 09:45:05 +0200
Subject: Keyservers and GDPR
In-Reply-To: <20190513173510.GA24471@zeromail.org>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org>
Message-ID: <feba25b429240a9f2d2cb43f370f53351b80958d.camel@cryptobitch.de>

Hi,


On Mon, 2019-05-13 at 19:35 +0200, ilf wrote:
> So far, I stand by last year's statement:
> 
> > tl;dr: Keep calm and keep running keyservers.
> 
Are you standing by your statement because you believe that processing
that data is lawful or because you don't fear the consequences of a
potentially unlawful processing of data?

Cheers,
  Tobi



From deloptes at gmail.com  Mon May 27 13:47:19 2019
From: deloptes at gmail.com (deloptes)
Date: Mon, 27 May 2019 13:47:19 +0200
Subject: Keyservers and GDPR
In-Reply-To: <20190527085928.GD882@zeromail.org>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
 <20190513173510.GA24471@zeromail.org>
 <feba25b429240a9f2d2cb43f370f53351b80958d.camel@cryptobitch.de>
 <20190527085928.GD882@zeromail.org>
Message-ID: <CAJJ4Ra+S+dVHpDh0UCQ__ovuqjrgd_=CgN5A+SN-C8zObv6=VA@mail.gmail.com>

Hi all,
sorry for stepping in as I am not working on this topic, but following the
GDPA story for longer time I never read that we could simply prompt and
agree with the terms of  the authority hosting the information of the
public key. The date and signature and probably reference to a version of
the agreement can be added to the key and it won't be much of overhead.
Isn't it more simple? Of course one should take care how the key servers
exchange information in a secure way, but IMO on the surface it is a matter
of an agreement between the person and the authority hosting the
information of the public key. As Tobias Mueller was writing, it is all
about handling personal information with care and not about fines. Of
course all of this should stand in court as well, because there are many
lawyers and companies that make money by legally blackmailing business
entities that down not comply to GDPA.

regards



On Mon, May 27, 2019 at 11:02 AM ilf <ilf at zeromail.org> wrote:

> Tobias Mueller:
> >> So far, I stand by last year's statement:
> >>> tl;dr: Keep calm and keep running keyservers.
> > Are you standing by your statement because you believe that processing
> > that data is lawful or because you don't fear the consequences of a
> > potentially unlawful processing of data?
>
> I stand by my statement because of the reasons I explained last year.
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html
>
> --
> ilf
>
> If you upload your address book to "the cloud", I don't want to be in it.
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190527/810e86f1/attachment.html>

From kristian.fiskerstrand at sumptuouscapital.com  Mon May 27 13:30:42 2019
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Mon, 27 May 2019 13:30:42 +0200
Subject: [Sks-devel] Keyservers and GDPR
In-Reply-To: <20190527023908.GA20175@phil-pennock>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org>
 <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de>
 <20190527023908.GA20175@phil-pennock>
Message-ID: <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com>

On 5/27/19 4:39 AM, Phil Pennock wrote:
> hkps is limited because Kristian doesn't hand out certs to anyone who
> shows up with a new keyserver and asks; he tends to do so with people
> who've been around and part of the community, because of the fairly
> obvious problems with assuming TLS is buying you anything when entirely
> unknown-to-others folks run the servers.  Kristian takes a lot of flak
> for not giving people the power they want just because they ask for it.
> 
> With the various problems of SKS today, I tentatively suggest that not
> defaulting to the HKPS pool and choosing a different target for the
> keys.gnupg.net CNAME might be beneficial.

Adding some meta-info to this one. In addition to the above-mentioned
concerns about new actors (in particular those not part of strong-set),
it is also a question of capacity of the keyservers, so hkps pool is
requiring load-balanced setup with minimum of 3 nodes on modern hardware
(e.g a node today requires a minimum of 8 GiB of RAM to be responsive
during merge of certain keys). The propagation time between the servers
in the broader pool became quite big and servers dropping in-out
sporadically due to merges.

Now, this is somewhat better for the general pool since
https://dev.gnupg.org/T4175 results in retry on failover for 5xx codes,
but has caused a lot of problem reports in the past and not all distros
ship this in stable versions.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurim? leges
The greater the degeneration of the republic, the more of its laws

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

From wk at gnupg.org  Tue May 28 17:53:44 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 28 May 2019 17:53:44 +0200
Subject: [Announce] GnuPG 2.2.16 released
Message-ID: <87sgsyk22f.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.16.  This is a maintenance release; see below for a list
changes.


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.16
====================================

  * gpg,gpgsm: Fix deadlock on Windows due to a keybox sharing
    violation.  [#4505]

  * gpg: Allow deletion of subkeys with --delete-key.  This finally
    makes the bang-suffix work as expected for that command.  [#4457]

  * gpg: Replace SHA-1 by SHA-256 in self-signatures when updating
    them with --quick-set-expire or --quick-set-primary-uid. [#4508]

  * gpg: Improve the photo image viewer selection.  [#4334]

  * gpg: Fix decryption with --use-embedded-filename.  [#4500]

  * gpg: Remove hints on using the --keyserver option.  [#4512]

  * gpg: Fix export of certain secret keys with comments.  [#4490]

  * gpg: Reject too long user-ids in --quick-gen-key.  [#4532]

  * gpg: Fix a double free in the best key selection code.  [#4462]

  * gpg: Fix the key generation dialog for switching back from EdDSA
    to ECDSA.

  * gpg: Use AES-192 with SHA-384 to comply with RFC-6637.

  * gpg: Use only the addrspec from the Signer's UID subpacket to
    mitigate a problem with another implementation.

  * gpg: Skip invalid packets during a keyring listing and sync
    diagnostics with the output.

  * gpgsm: Avoid confusing diagnostic when signing with the default
    key.  [#4535]

  * agent: Do not delete any secret key in --dry-run mode.

  * agent: Fix failures on 64 bit big-endian boxes related to URIs in
    a keyfile.  [#4501]

  * agent: Stop scdaemon after a reload with disable-scdaemon newly
    configured.  [#4326]

  * dirmngr: Improve caching algorithm for WKD domains.

  * dirmngr: Support other hash algorithms than SHA-1 for OCSP.  [#3966]

  * gpgconf: Make --homedir work for --launch.  [#4496]

  * gpgconf: Before --launch check for a valid config file.  [#4497]

  * wkd: Do not import more than 5 keys from one WKD address.

  * wkd: Accept keys which are stored in armored format in the
    directory.

  * The installer for Windows now comes with signed binaries.

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


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

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

GnuPG 2.2.16 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.16.tar.bz2 (6542k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.16.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.16_20190528.exe (4183k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.16_20190528.exe.sig

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


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

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

     sha1sum gnupg-2.2.16.tar.bz2

   and check that the output matches the next line:

f956c8cebee3a6ddb2ce6e6e058d474d056dd9e0  gnupg-2.2.16.tar.bz2
8d2214dc3dd4a34c69953b1c9254520fd07033f1  gnupg-w32-2.2.16_20190528.tar.xz
caf09d6e0e47d87675f1805409a503ce0cf93a4e  gnupg-w32-2.2.16_20190528.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/T4509 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 check out <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 four keys:

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

  rsa2048 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  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: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190528/f60e81e8/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Wed May 29 08:56:10 2019
From: wk at gnupg.org (Werner Koch)
Date: Wed, 29 May 2019 08:56:10 +0200
Subject: Keyservers and GDPR
In-Reply-To: <20190527023908.GA20175@phil-pennock> (Phil Pennock's message of
 "Sun, 26 May 2019 22:39:09 -0400")
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
 <20190513173510.GA24471@zeromail.org>
 <20190525125307.GA13759@zeromail.org>
 <87y32tmwrk.fsf@wheatstone.g10code.de>
 <20190527023908.GA20175@phil-pennock>
Message-ID: <877ea921h1.fsf@wheatstone.g10code.de>

On Sun, 26 May 2019 22:39, gnupg-devel at spodhuis.org said:

> With the various problems of SKS today, I tentatively suggest that not
> defaulting to the HKPS pool and choosing a different target for the
> keys.gnupg.net CNAME might be beneficial.

FWIW, keys.gnupg.net is since gnupg 2.2.7 not a CNAME name but aliased
by dirmngr in this way:

  hkps://keys.gnupg.net       -> hkps://hkps.pool.sks-keyservers.net
  https://keys.gnupg.net      -> https://hkps.pool.sks-keyservers.net
  hkp://keys.gnupg.net        -> hkp://hkps.pool.sks-keyservers.net
  http://keys.gnupg.net       -> http://hkps.pool.sks-keyservers.net
  hkps://http-keys.gnupg.net  -> hkps://ha.pool.sks-keyservers.net
  https://http-keys.gnupg.net -> https://ha.pool.sks-keyservers.net
  hkp://http-keys.gnupg.net   -> hkp://ha.pool.sks-keyservers.net
  http://http-keys.gnupg.net  -> http://ha.pool.sks-keyservers.net

  keys.gnupg.net              -> hkps://hkps.pool.sks-keyservers.net
  http-keys.gnupg.net         -> hkps://ha.pool.sks-keyservers.net

this was needed to void problems with server name matching.  Thus we
can't change that easily.  Anyway, it is suggested tha the default
keyserver is used which is  hkps://hkps.pool.sks-keyservers.net  To
change this the keyserver option in dirmngr.conf needs to be used.

> suspect that >> subset.pool.sks-keyservers.net << is likely to be the
> best choice for GnuPG; the meaning of "subset" changes over time,

I am pretty sure that changing to this as the default will raise a lot
of concerns from the folks who want to elimiated the use of the string
"http://".



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-devel/attachments/20190529/46be5fb3/attachment.sig>

From wk at gnupg.org  Wed May 29 09:07:26 2019
From: wk at gnupg.org (Werner Koch)
Date: Wed, 29 May 2019 09:07:26 +0200
Subject: [Sks-devel] Keyservers and GDPR
In-Reply-To: <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com>
 (Kristian Fiskerstrand's message of "Mon, 27 May 2019 13:30:42 +0200")
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org>
 <20190513173510.GA24471@zeromail.org>
 <20190525125307.GA13759@zeromail.org>
 <87y32tmwrk.fsf@wheatstone.g10code.de>
 <20190527023908.GA20175@phil-pennock>
 <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com>
Message-ID: <8736kx20y9.fsf@wheatstone.g10code.de>

On Mon, 27 May 2019 13:30, kristian.fiskerstrand at sumptuouscapital.com
said:

> requiring load-balanced setup with minimum of 3 nodes on modern hardware
> (e.g a node today requires a minimum of 8 GiB of RAM to be responsive
> during merge of certain keys). The propagation time between the servers

Which would support my point to redesign the keyservers to

 - Inhibit searches by user id.
 
 - Drop all key signatures except for self-signatures and designated
   revocations.

The first change will make Gnupg --search-keys useless and that command
could thus be changed to do a --locate-key with disabled local keyring.

The second requires that key-signatures must be send to the key owner
directly, which is anyway what most people do.  And obviously the key
owner needs to distribute them by other means than the keyservers to
make the few WoT users happy.

Right, this requires that self-signatures are verified on upload.


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-devel/attachments/20190529/35a67379/attachment.sig>

From andrewg at andrewg.com  Wed May 29 09:33:00 2019
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 29 May 2019 08:33:00 +0100
Subject: [Sks-devel] Keyservers and GDPR
In-Reply-To: <8736kx20y9.fsf@wheatstone.g10code.de>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org>
 <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de>
 <20190527023908.GA20175@phil-pennock>
 <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com>
 <8736kx20y9.fsf@wheatstone.g10code.de>
Message-ID: <A23C2A12-B626-46C8-9794-48E864D7FD76@andrewg.com>


> On 29 May 2019, at 08:07, Werner Koch <wk at gnupg.org> wrote:
> 
> Right, this requires that self-signatures are verified on upload.

...and on reconciliation?

A


From dirkx at webweaving.org  Wed May 29 09:42:56 2019
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Wed, 29 May 2019 09:42:56 +0200
Subject: [Sks-devel] Keyservers and GDPR
In-Reply-To: <8736kx20y9.fsf@wheatstone.g10code.de>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org>
 <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de>
 <20190527023908.GA20175@phil-pennock>
 <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com>
 <8736kx20y9.fsf@wheatstone.g10code.de>
Message-ID: <038536C5-0F94-4280-82E3-CA7772C8BF31@webweaving.org>

On 29 May 2019, at 09:07, Werner Koch <wk at gnupg.org> wrote:

> Which would support my point to redesign the keyservers to
> 
> - Inhibit searches by user id.

What is the reasoning behind this (as signing keys just are on the uploaded key with a keyid ? so we are talking about the key its own data) ?

And pair this if needed with a submission protocol that insists on having the private key.

That would also openup, from a GDPR perspective, allowing the signing key ids back in.

Dw.



From alex at nitrokey.com  Wed May 29 10:50:12 2019
From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey)
Date: Wed, 29 May 2019 10:50:12 +0200
Subject: python + pgpme + openpgp card
In-Reply-To: <301808503.210340427.1558524105498.JavaMail.root@spooler3-g27.priv.proxad.net>
References: <301808503.210340427.1558524105498.JavaMail.root@spooler3-g27.priv.proxad.net>
Message-ID: <1b53c775-a2df-4fcb-fc57-ceb0ee4aae53@nitrokey.com>

Hi Laurent,

yes, as far as I know pgpme has no smart card functionality at all
(yet). You need to use other python libraries for OpenPGP Card usage.
Though there is no full-featured pyhthon library for OpenPGP Cards
either. At least none I know of. There are rudimentary ones though.
Sorry, but I am too lazy to provide links right know, but they are
easily found :)

Kind regards
Alex

On 22.05.19 13:21, laurent.feron at free.fr wrote:
> Hello,
> It seems that I cannot manage keys on a card in Python language. Someone can confirm?
> Regards
> Laurent
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>