From xry111 at mengyan1223.wang  Sun Aug  1 03:51:18 2021
From: xry111 at mengyan1223.wang (Xi Ruoyao)
Date: Sun, 01 Aug 2021 09:51:18 +0800
Subject: [blfs-support] --search-keys: "gpg: error searching keyserver:
 No inquire callback in IPC"
In-Reply-To: <c619988d-50e4-846e-9218-8d33688582d0@mailbox.org>
References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org>
 <c9e23105-2fd3-5c31-ccab-4d96a79cb8bc@andrewg.com>
 <ddaa17a6-fc1c-dbbe-a68f-de706fd884bf@mailbox.org>
 <14955896.LIEdVQZUKm@daneel>
 <ba750cfa-903d-bcc8-02a1-b9c329401867@mailbox.org>
 <da4e1fcc-86d9-e92a-b0dc-36649ad4c43f@andrewg.com>
 <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org>
 <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com>
 <b72911aa-615b-13a6-3222-ebd8192c0ee3@mailbox.org>
 <ab113ad0-0051-6540-d5b1-a68d7bbb8769@andrewg.com>
 <87bl6i7aqt.fsf@wheatstone.g10code.de>
 <7ed91f41-41fe-f483-9687-39291d019e0b@mailbox.org>
 <466ca329827d1b88e3e3f3d9c7e9a82e99d9de77.camel@mengyan1223.wang>
 <c619988d-50e4-846e-9218-8d33688582d0@mailbox.org>
Message-ID: <101b20529d341b4030e278177cdf88506ad2d5cc.camel@mengyan1223.wang>

On Sat, 2021-07-31 at 22:16 +0200, Rainer Fiebig wrote:
> Am 31.07.21 um 21:00 schrieb Xi Ruoyao:
> > On Sat, 2021-07-31 at 19:56 +0200, Rainer Fiebig wrote:
> > > Am 31.07.21 um 17:40 schrieb Werner Koch:
> > > > On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
> > > > 
> > > > > If you built gnupg from its default configuration, it does not
> > > > > automatically look in /etc/ssl/certs for CA certificates. You
> > > > > may
> > > > > want
> > > > 
> > > > On Unix and unless gnupg was build with --with-default-trust-
> > > > store-
> > > > file
> > > > the following collections of certificates are used for TLS:
> > > > 
> > > > ??? { "/etc/ssl/ca-bundle.pem" },
> > > > ??? { "/etc/ssl/certs/ca-certificates.crt" },
> > > > ??? { "/etc/pki/tls/cert.pem" },
> > > > ??? { "/usr/local/share/certs/ca-root-nss.crt" },
> > > > ??? { "/etc/ssl/cert.pem" }
> > > > 
> > 
> > Hi Werner,
> > 
> > Our "recommended" configuration in BLFS is: gnutls is built with
> > p11-kit
> > and --with-default-trust-store-pkcs11="pkcs11:", and gnupg is built
> > with
> > gnutls.? So gnupg "should" use certificates from p11-kit trust store
> > I
> > think?? And it works for me.
> > 
> > I saw your discussion with "curl".? In BLFS curl uses OpenSSL
> > instead of
> > GnuTLS, so they actually have different trust stores.? GnuTLS (using
> > p11-kit) uses /etc/pki/anchors, OpenSSL uses /etc/ssl/certs.
> > 
> > I remember once an unclean shutdown caused a similar issue on my
> > system
> > (/etc/pki/anchors is disrupted, and every program using GnuTLS just
> > started to distrust every certificate).
> > 
> > Hi Rainer,
> > 
> > Try "gnutls-cli keys.openpgp.org".? If it does not get into "Simple
> > Client Mode" as expected, it means p11-kit trust store may be
> > disrupted.
> > Try "make-ca -f -g" to rebuild it.
> > 
> > And check if your p11-kit was built with
> > -Dtrust_paths=/etc/pki/anchors as the BLFS book says.? If not sure,
> > rebuild it.? (I can also remember once I've mistyped the path, this
> > also
> > caused every program using GnuTLS started to distrust every
> > certificate.)
> > 
> OK, issued "make-ca -f -g" and re-built gnupg *without* path_to_file.
> But the result then was again
> 
> ~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568
> gpg: error searching keyserver: No inquire callback in IPC
> 
> So the only way to get this reliably working on my system seems to be
> building gnupg *with* path_to_file.

So gnutls-cli works but gpg (which should uses GnuTLS) does not?  I'm
now puzzled as I can't reproduce it on my system at all.

As a last resort: which GPG version did you installed?  And was GnuTLS
installed when you built it?
-- 
Xi Ruoyao <xry111 at mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University



From jrf at mailbox.org  Sun Aug  1 16:27:21 2021
From: jrf at mailbox.org (Rainer Fiebig)
Date: Sun, 1 Aug 2021 16:27:21 +0200
Subject: SOLVED: --search-keys: "gpg: error searching keyserver: No inquire
 callback in IPC"
In-Reply-To: <202107281545.54237.bernhard@intevation.de>
References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org>
 <202107281545.54237.bernhard@intevation.de>
Message-ID: <802593f8-d1a4-de4a-a1dc-e84ee8420a4d@mailbox.org>

Am 28.07.21 um 15:45 schrieb Bernhard Reiter:
> Hi Rainer,
> 
> Am Mittwoch 28 Juli 2021 11:22:18 schrieb Rainer Fiebig via Gnupg-users:
>> Hi! I'm having a problem when searching for keys on keyservers when
>> using "gpg --search-keys".
>>
>> The only line in dirmngr.conf (except for comments) is:
>> keyserver hkps://keys.openpgp.org

OK, I could figure it out, finally:

Beyond Linux From Scratch (BLFS) do not use ntbTLS for TLS, they use gnuTLS.

But in connection with an update of gnupg I had installed ntbTLS in my
former system because it was listed on
https://gnupg.org/download/index.html.

So I had it in my build list for my latest BLFS as well. Obviously,
gnupg prefers ntbTLS over gnuTLS. And so gnupg was built with ntbTLS
instead of gnuTLS. From the build log:
[...]
GnuPG v2.2.29 has been configured as follows:
        [...]
        TLS support:         ntbTLS
        [...]


ntbTLS was built after p11-kit but it doesn't seem to cooperate with
p11-kit in the same way that gnuTLS does and so expects the certificates
in those places that Werner has mentioned but which differ from the
setup in BLFS.

By configuring gnupg with

	--disable-ntbTLS
	
it uses gnuTLS for TLS support.

And now gpg --search-keys works as expected in my BLFS.
My bad! Thanks to everybody involved! Sorry for having wasted your time!


From yuri.kanivetsky at gmail.com  Mon Aug  2 23:14:02 2021
From: yuri.kanivetsky at gmail.com (Yuri Kanivetsky)
Date: Tue, 3 Aug 2021 00:14:02 +0300
Subject: Socket activation doesn't seem to work
Message-ID: <CAMhVC3aSPmdxKhHgcOQXYO=70wD8eqkk5DjTYu41tiLNVKO4vg@mail.gmail.com>

Hi,

>From what I can see socket activation doesn't work:

```
$ strace -s 1000 -fe execve,clone,connect gpg --search-key DF6FD971306037D9
execve("/usr/bin/gpg", ["gpg", "--search-key", "DF6FD971306037D9"],
0x7ffd5a2ff020 /* 66 vars */) = 0
connect(3, {sa_family=AF_UNIX,
sun_path="/run/user/1000/gnupg/d.8fzkopk8kpkda6radgaom1gz/S.dirmngr"},
59) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_UNIX,
sun_path="/run/user/1000/gnupg/d.8fzkopk8kpkda6radgaom1gz/S.dirmngr"},
59) = -1 ENOENT (No such file or directory)
clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLDstrace: Process
3066 attached
, child_tidptr=0x7fa4ba696a10) = 3066
[pid  3066] clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLDstrace: Process
3067 attached
, child_tidptr=0x7fa4ba696a10) = 3067
[pid  3066] +++ exited with 0 +++
[pid  3065] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED,
si_pid=3066, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[pid  3067] execve("/usr/bin/dirmngr", ["dirmngr", "--daemon",
"--homedir", "/home/yuri/dir/.gnupg"], 0x7fff864777f8 /* 66 vars */
<unfinished ...>
...
```

And in dirmngr.socket we have:

ListenStream=%t/gnupg/S.dirmngr

https://github.com/gpg/gnupg/blob/master/doc/examples/systemd-user/dirmngr.socket#L6

So supposedly, gpg fails to connect to dirmngr and starts its own
copy, which might run alongside a systemd-controlled one. Which is
confusing.

More on it here:

https://bbs.archlinux.org/viewtopic.php?id=258995

Regards,
Yuri


From yuri.kanivetsky at gmail.com  Mon Aug  2 23:02:14 2021
From: yuri.kanivetsky at gmail.com (Yuri Kanivetsky)
Date: Tue, 3 Aug 2021 00:02:14 +0300
Subject: gpg --delete-keys --yes asks for confirmation
Message-ID: <CAMhVC3a==-6J1VAwNt6kzBQHf2GjzntnjHnnWf0RGBmf6mxz6g@mail.gmail.com>

Hi,

```
$ gpg --delete-keys --yes 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
gpg (GnuPG) 2.2.29; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  rsa4096/105BD0E739499BDB 2016-11-11 Piotr Kuczynski
<piotr.kuczynski at gmail.com>

Delete this key from the keyring? (y/N)
```

Is this a bug or a feature? If the latter, why? How do I delete a key
from a script?


From johndoe65534 at mail.com  Tue Aug  3 08:56:45 2021
From: johndoe65534 at mail.com (john doe)
Date: Tue, 3 Aug 2021 08:56:45 +0200
Subject: gpg --delete-keys --yes asks for confirmation
In-Reply-To: <CAMhVC3a==-6J1VAwNt6kzBQHf2GjzntnjHnnWf0RGBmf6mxz6g@mail.gmail.com>
References: <CAMhVC3a==-6J1VAwNt6kzBQHf2GjzntnjHnnWf0RGBmf6mxz6g@mail.gmail.com>
Message-ID: <7b7a053c-6235-9045-7188-d301ea33d1c8@mail.com>

On 8/2/2021 11:02 PM, Yuri Kanivetsky via Gnupg-users wrote:
> Hi,
>
> ```
> $ gpg --delete-keys --yes 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
> gpg (GnuPG) 2.2.29; Copyright (C) 2021 Free Software Foundation, Inc.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
>
> pub  rsa4096/105BD0E739499BDB 2016-11-11 Piotr Kuczynski
> <piotr.kuczynski at gmail.com>
>
> Delete this key from the keyring? (y/N)
> ```
>
> Is this a bug or a feature? If the latter, why? How do I delete a key
> from a script?
>

By using the '--batch' option:

$ gpg --dry-run --batch --delete-keys --yes
7D2BAF1CF37B13E2069D6956105BD0E739499BDB


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

--
John Doe


From yuri.kanivetsky at gmail.com  Tue Aug  3 10:34:13 2021
From: yuri.kanivetsky at gmail.com (Yuri Kanivetsky)
Date: Tue, 3 Aug 2021 11:34:13 +0300
Subject: A key doesn't get imported from one of the keyservers
Message-ID: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>

Hi,

The following two commands succeed:

$ gpg --keyserver keyserver.ubuntu.com --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3
$ gpg --keyserver hkp://pgp.mit.edu --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3  # sometimes

But this one doesn't:

$ gpg --keyserver keys.openpgp.org --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3
gpg: key 3804BB82D39DC0E3: no user ID
gpg: Total number processed: 1

Is something wrong with the key that resides on keys.openpgp.org? Are
the keys that are one these 3 keyservers the same?

Regards,
Yuri


From yuri.kanivetsky at gmail.com  Tue Aug  3 11:52:06 2021
From: yuri.kanivetsky at gmail.com (Yuri Kanivetsky)
Date: Tue, 3 Aug 2021 12:52:06 +0300
Subject: A key doesn't get imported from one of the keyservers
In-Reply-To: <8735rqvpfn.fsf@iki.fi>
References: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>
 <8735rqvpfn.fsf@iki.fi>
Message-ID: <CAMhVC3Ym4Qfz7AS4pTqkWb7_n+60kn+Q1nsB65MM9zx+eK28ew@mail.gmail.com>

Okay, then... All the keyservers have the key. But keys.openpgp.org
doesn't let it get imported because the owner didn't consent to making
his email address publicly known by verifying his email address.

Which means that the owner doesn't care much about this, otherwise he
would not publish the key to the other servers.

Also, how do I as an owner... apply for verification?

gpg --export your_address at example.net | curl -T - https://keys.openpgp.org

And then follow the instructions at the outputted URL?

Will it invalidate my key (previous version of the key)?

Regards,
Yuri


From look at my.amazin.horse  Tue Aug  3 12:09:27 2021
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 03 Aug 2021 12:09:27 +0200
Subject: A key doesn't get imported from one of the keyservers
In-Reply-To: <CAMhVC3Ym4Qfz7AS4pTqkWb7_n+60kn+Q1nsB65MM9zx+eK28ew@mail.gmail.com>
References: <CAMhVC3Ym4Qfz7AS4pTqkWb7_n+60kn+Q1nsB65MM9zx+eK28ew@mail.gmail.com>
 <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>
 <8735rqvpfn.fsf@iki.fi>
Message-ID: <2P2YIHCZDTW82.2DP8N3GPQTTPO@my.amazin.horse>


> Okay, then... All the keyservers have the key. But keys.openpgp.org
> doesn't let it get imported because the owner didn't consent to making
> his email address publicly known by verifying his email address.
> 
> Which means that the owner doesn't care much about this, otherwise he
> would not publish the key to the other servers.

Either that, or they don't know about it, or the key was published by someone
else since there are no checks on the other servers. There are currently ~250k
verified addresses, typically it depends on the user's client software (e.g.
GPGTools for macOS has great support for keys.o.o verification, GPG4win has
none).

> Also, how do I as an owner... apply for verification?
> 
> gpg --export your_address at example.net | curl -T - https://keys.openpgp.org
> 
> And then follow the instructions at the outputted URL?

Yep, that is one way.

> Will it invalidate my key (previous version of the key)?

Only one key can be verified for any email address at one time, so it's possible
to replace keys for an email address, or remove them. As long as it's the same
key, all updates to that key will be merged as usual.

Cheers

 - V



From gnupgpacker at on.yourweb.de  Tue Aug  3 11:02:35 2021
From: gnupgpacker at on.yourweb.de (gnupgpacker)
Date: Tue, 3 Aug 2021 11:02:35 +0200
Subject: WKD: how to remove expired key verification
Message-ID: <000001d78846$4d1e5240$e75af6c0$@on.yourweb.de>

Hello,

a key contains an old, expired verification.

If searching this key by WKD, it shows:

$ gpg --locate-key xy at xyxy.de
pub   rsa2048 2013-10-21 [SCEA] [verfallen: 2019-03-26]
      6EB139DA63B4D15xyxyB970F435Fxy3FB0Dxyxy
uid        [ verfallen ] Pre Name <xy at xyxy.de>

Valid keys included are not shown.

How to fix this, how to deactivate/ remove expired verification?

Kleopatra screenshot attached too => Key 7217... must be removed.

Thanks for help, best regards!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beglaubigung.png
Type: image/png
Size: 13892 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210803/a521808d/attachment-0001.png>

From look at my.amazin.horse  Tue Aug  3 11:19:56 2021
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 03 Aug 2021 11:19:56 +0200
Subject: A key doesn't get imported from one of the keyservers
In-Reply-To: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>
References: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com> 
Message-ID: <3LJM8RMFD3EZ8.2HOVESRITND33@my.amazin.horse>


Hi Yuri,

> Is something wrong with the key that resides on keys.openpgp.org? Are
> the keys that are one these 3 keyservers the same?

Unlike the other keyservers, keys.openpgp.org has a [privacy policy] that
doesn't permit distributing email addresses without consent. The key in question
has no verified user ids, and thus can't be imported, it can only be used to
retrieve updates when you already have the key (I should really add a FAQ entry
about this).

Worth mentioning that pool.sks-keyservers.net closed down a few weeks ago
precisely because most keyservers have no privacy policy at all (aka "anything
goes"), which caused too many conflicts with GDPR.

Cheers

 - V

[privacy policy]: https://keys.openpgp.org/about/privacy


From tlikonen at iki.fi  Tue Aug  3 11:38:04 2021
From: tlikonen at iki.fi (Teemu Likonen)
Date: Tue, 03 Aug 2021 12:38:04 +0300
Subject: A key doesn't get imported from one of the keyservers
In-Reply-To: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>
References: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>
Message-ID: <8735rqvpfn.fsf@iki.fi>

* 2021-08-03 11:34:13+0300, Yuri Kanivetsky via Gnupg-users wrote:

> $ gpg --keyserver keys.openpgp.org --recv-keys
> 409B6B1796C275462A1703113804BB82D39DC0E3
> gpg: key 3804BB82D39DC0E3: no user ID
> gpg: Total number processed: 1
>
> Is something wrong with the key that resides on keys.openpgp.org? Are
> the keys that are one these 3 keyservers the same?

Server keys.openpgp.org is different from SKS keyservers. Read more
about it here:

    https://keys.openpgp.org/about

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

From kloecker at kde.org  Tue Aug  3 17:15:17 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Tue, 03 Aug 2021 17:15:17 +0200
Subject: WKD: how to remove expired key verification
In-Reply-To: <000001d78846$4d1e5240$e75af6c0$@on.yourweb.de>
References: <000001d78846$4d1e5240$e75af6c0$@on.yourweb.de>
Message-ID: <2184008.L6xfOmqbs0@daneel>

On Dienstag, 3. August 2021 11:02:35 CEST gnupgpacker wrote:
> Hello,
> 
> a key contains an old, expired verification.
> 
> If searching this key by WKD, it shows:
> 
> $ gpg --locate-key xy at xyxy.de
> pub   rsa2048 2013-10-21 [SCEA] [verfallen: 2019-03-26]
>       6EB139DA63B4D15xyxyB970F435Fxy3FB0Dxyxy
> uid        [ verfallen ] Pre Name <xy at xyxy.de>
> 
> Valid keys included are not shown.

If I run this I get a "Connection refused" error:

$ gpg -v --locate-key xy at xyxy.de
gpg: using pgp trust model
gpg: error retrieving 'xy at xyxy.de' via Local: No public key
gpg: error retrieving 'xy at xyxy.de' via WKD: Connection refused
gpg: error reading key: Connection refused

> How to fix this, how to deactivate/ remove expired verification?

You may have to fix the "Connection refused" error unless connections from 
your computer are not refused. In any case, requesting more verbose output 
will help diagnose the problem, i.e. run
$ gpg -v --locate-key xy at xyxy.de

Moreover, you can add
--auto-key-locate "clear,wkd,nodefault"
to make --locate-key ignore the local storage and try WKD only.

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

From wk at gnupg.org  Wed Aug  4 10:35:28 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 04 Aug 2021 10:35:28 +0200
Subject: A key doesn't get imported from one of the keyservers
In-Reply-To: <3LJM8RMFD3EZ8.2HOVESRITND33@my.amazin.horse> (Vincent Breitmoser
 via Gnupg-users's message of "Tue, 03 Aug 2021 11:19:56 +0200")
References: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>
 <3LJM8RMFD3EZ8.2HOVESRITND33@my.amazin.horse>
Message-ID: <87fsvp4nfz.fsf@wheatstone.g10code.de>

On Tue,  3 Aug 2021 11:19, Vincent Breitmoser said:

> Unlike the other keyservers, keys.openpgp.org has a [privacy policy] that
> doesn't permit distributing email addresses without consent. The key

It is not a privacy policy but a serious misconception much like what
keyserver.com and PGP Universal Server did a long time ago.

The OpenPGP spec requires a User ID for the on-wire format of a public
key.  Any implementation which violates this rule is not OpenPGP
compliant.

The privacy argument on the a user id is layman's idea of the GDPR.  In
fact the key itself is not different than an IP address or mail address
and in fact more stronger personal data or a natural person than the
latter.

Note that out of reasons of data minimization I would suggest to create
new keys only with a mail address and not with any other data.  For
example posteo.de has such a rule for keys used on their platform;
gpg-wks-client even has direct support for such a requirement.


Salam-Shalom,

   Werner

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

From johndoe65534 at mail.com  Wed Aug  4 12:32:38 2021
From: johndoe65534 at mail.com (john doe)
Date: Wed, 4 Aug 2021 12:32:38 +0200
Subject: A key doesn't get imported from one of the keyservers
In-Reply-To: <87fsvp4nfz.fsf@wheatstone.g10code.de>
References: <CAMhVC3bLnKK5ad1DqJHHbGhLpEaMp8D5eA60m7-hvUOuVwHSnA@mail.gmail.com>
 <3LJM8RMFD3EZ8.2HOVESRITND33@my.amazin.horse>
 <87fsvp4nfz.fsf@wheatstone.g10code.de>
Message-ID: <1f97fd63-3b36-0c28-cedc-81e5d8d2ef10@mail.com>

On 8/4/2021 10:35 AM, Werner Koch via Gnupg-users wrote:
> On Tue,  3 Aug 2021 11:19, Vincent Breitmoser said:
>
>> Unlike the other keyservers, keys.openpgp.org has a [privacy policy] that
>> doesn't permit distributing email addresses without consent. The key
>
> It is not a privacy policy but a serious misconception much like what
> keyserver.com and PGP Universal Server did a long time ago.
>
> The OpenPGP spec requires a User ID for the on-wire format of a public
> key.  Any implementation which violates this rule is not OpenPGP
> compliant.
>
> The privacy argument on the a user id is layman's idea of the GDPR.  In
> fact the key itself is not different than an IP address or mail address
> and in fact more stronger personal data or a natural person than the
> latter.
>
> Note that out of reasons of data minimization I would suggest to create
> new keys only with a mail address and not with any other data.  For
> example posteo.de has such a rule for keys used on their platform;

If I understand correctly, the 'real name' and 'comment' should be left out.

1)  https://posteo.de/en/help/policies-for-public-keys#names

--
John Doe


From wk at gnupg.org  Wed Aug  4 13:01:08 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 04 Aug 2021 13:01:08 +0200
Subject: keys retrieved from keyserver (keys.openpgp.org) are unusable
In-Reply-To: <20210727181214.GA12505@springbeautygroup.com> (root's message of
 "Tue, 27 Jul 2021 11:12:14 -0700")
References: <20210726233253.GB52741@springbeautygroup.com>
 <1859524.8Rs5kX7egn@daneel>
 <20210727181214.GA12505@springbeautygroup.com>
Message-ID: <87y29h324r.fsf@wheatstone.g10code.de>

On Tue, 27 Jul 2021 11:12, root said:

> I am new to GnuPG and this is a great tool in programming. I am not sure how to
> use gpg commands directly in C/C++ codes though. I thought gpgme is
> providing the
> interface to use gpg ? 

Yes, please use GPGME or the GPGME C++ bindings


Salam-Shalom,

   Werner

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

From ericlin at ericyclin.net  Wed Aug  4 19:58:49 2021
From: ericlin at ericyclin.net (Eric Y. Lin)
Date: Wed, 4 Aug 2021 10:58:49 -0700
Subject: Unable to load dll
Message-ID: <20210804175849.GA10236@springbeautygroup.com>

Hi, there

I've built up a win32 application to remotely import a public key to verify a digital signature. Everything works fine in a Windows 10 machine. Yet, as I was trying this win32 app when the gpg4win-3.1.16 was uninstalled, it didn't work. The error message is "Unable to load DLL '.....'" The specified module could not be found. I got the same error message even if I copied the libgpgme.imp and libgpgme-11.dll to be in the same folder as the win32 app. 

I've downloaded the depends.exe and found out that there are hundreds of API-MS_WIN dll, and another 50 various other dlls missing for my win32 app. 

Has anybody experienced similar thing ? How do I fix this ?

Another small issue is that the remotely listing and importing public key is a very slow process. It usually takes about one minute or so to complete. Is this a normal thing ? 

Thanks.

Regards,
Eric


From gnupgpacker at on.yourweb.de  Fri Aug  6 09:33:45 2021
From: gnupgpacker at on.yourweb.de (gnupgpacker)
Date: Fri, 6 Aug 2021 09:33:45 +0200
Subject: gnupg-users@gnupg.org
Message-ID: <000001d78a95$6a2be220$3e83a660$@on.yourweb.de>

Hello
and thanks for this hints.

If using:
$ gpg -v --auto-key-locate clear,wkd,nodefault --locate-key xy at xyxy.de
gpg: verwende Vertrauensmodell pgp
gpg: pub  rsa4096/F507E7850xxxxxxC 2015-01-05  Vorname Name <xy at xyxy.de>
gpg: Schl?ssel F507E785xxxxxxC: "Vorname Name <xy at xyxy.de>" nicht ge?ndert
gpg: pub  rsa2048/435F423FxxxxxxD4 2013-10-21  Vorname Name <xy at xyxy.de>
gpg: Hinweis: Signaturschl?ssel 435F423FxxxxxxD4 ist am 26.03.2019 12:00:00 Mitteleurop?ische Zeit verfallen
gpg: Schl?ssel 435F423FxxxxxxD4: "Vorname Name <xy at xyxy.de>" nicht ge?ndert
gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 2
gpg:                             unver?ndert: 2
gpg: auto-key-locate found fingerprint DDC9F7A53xxxxxxxxDAAD53F507E785xxxxxxC
gpg: `xy at xyxy.de' automatisch via WKD geholt
pub   rsa4096 2015-01-05 [C] [verf?llt: 2021-12-31]
      DDC9F7A53xxxxxxxxDAAD53F507E785xxxxxxC
uid        [ ultimativ ] Vorname Name <xy at xyxy.de>
sub   rsa4096 2015-01-05 [A] [verf?llt: 2021-12-31]
sub   rsa4096 2015-01-05 [S] [verf?llt: 2021-12-31]
sub   rsa4096 2015-01-05 [E] [verf?llt: 2021-12-31]


Signaturschl?ssel 435F423FxxxxxxD4 has been expired on 26.03.2019, but is still attached to published and still valid public WKD key.

It's my own key, actual one and old expired signature key ;)
It has been used while changing my own pgp key to a stronger one for signing it with my old valid key. Now it is not more needed, new key has been spreaded.

How to remove this old and expired signature from my key contruct?

Thanks and best regards.





From joeyberkovitz at gmail.com  Sat Aug  7 00:36:18 2021
From: joeyberkovitz at gmail.com (Joey Berkovitz)
Date: Fri, 6 Aug 2021 18:36:18 -0400
Subject: Smartcard Status Message Inconsistency
Message-ID: <CAKz+fXNvYNJxdCQNqK+_UP7cW+FMUzvS_6tw00miJRcF=UZ+qA@mail.gmail.com>

Hi,

I was looking through the Smartcard commands and found that while most
commands related to attribute changes output an SC_OP_SUCCESS, except for
the name change command which doesn't output a success message on the
status-fd.

The relevant code for each of the attribute commands is listed below:
name - no success message (
https://github.com/gpg/gnupg/blob/master/g10/card-util.c#L787)
url - https://github.com/gpg/gnupg/blob/master/g10/card-util.c#L845
login - https://github.com/gpg/gnupg/blob/master/g10/card-util.c#L1003
lang - https://github.com/gpg/gnupg/blob/master/g10/card-util.c#L1140
salutation - https://github.com/gpg/gnupg/blob/master/g10/card-util.c#L1176

Is there any reason why name changes don't output a status message?

Best,
Joey Berkovitz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210806/12b30a70/attachment.html>

From gnupgpacker at on.yourweb.de  Sun Aug  8 10:57:00 2021
From: gnupgpacker at on.yourweb.de (gnupgpacker)
Date: Sun, 8 Aug 2021 10:57:00 +0200
Subject: WKD: how to remove expired key verification
Message-ID: <001101d78c33$59cbfb00$0d63f100$@on.yourweb.de>

Hello
and thanks for this hints.

If using:
$ gpg -v --auto-key-locate clear,wkd,nodefault --locate-key xy at xyxy.de
gpg: verwende Vertrauensmodell pgp
gpg: pub  rsa4096/F507E7850xxxxxxC 2015-01-05  Vorname Name <xy at xyxy.de>
gpg: Schl?ssel F507E785xxxxxxC: "Vorname Name <xy at xyxy.de>" nicht ge?ndert
gpg: pub  rsa2048/435F423FxxxxxxD4 2013-10-21  Vorname Name <xy at xyxy.de>
gpg: Hinweis: Signaturschl?ssel 435F423FxxxxxxD4 ist am 26.03.2019 12:00:00 Mitteleurop?ische Zeit verfallen
gpg: Schl?ssel 435F423FxxxxxxD4: "Vorname Name <xy at xyxy.de>" nicht ge?ndert
gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 2
gpg:                             unver?ndert: 2
gpg: auto-key-locate found fingerprint DDC9F7A53xxxxxxxxDAAD53F507E785xxxxxxC
gpg: `xy at xyxy.de' automatisch via WKD geholt
pub   rsa4096 2015-01-05 [C] [verf?llt: 2021-12-31]
      DDC9F7A53xxxxxxxxDAAD53F507E785xxxxxxC
uid        [ ultimativ ] Vorname Name <xy at xyxy.de>
sub   rsa4096 2015-01-05 [A] [verf?llt: 2021-12-31]
sub   rsa4096 2015-01-05 [S] [verf?llt: 2021-12-31]
sub   rsa4096 2015-01-05 [E] [verf?llt: 2021-12-31]


Signaturschl?ssel 435F423FxxxxxxD4 has been expired on 26.03.2019, but is still attached to published and still valid public WKD key.

It's my own key, actual one and old expired signature key ;)
It has been used while changing my own pgp key to a stronger one for signing it with my old valid key. Now it is not more needed, new key has been spreaded.

How to remove this old and expired signature from my key contruct?

Thanks and best regards.





From philcerf at gmail.com  Fri Aug 13 19:10:21 2021
From: philcerf at gmail.com (Philippe Cerfon)
Date: Fri, 13 Aug 2021 19:10:21 +0200
Subject: Does it make sense to pipe yescrypt/Argon2id as passphrase for gpg?
Message-ID: <CAN+za=MYSfvmPwkOV6vZAToyZJKZOMFNFSbCouWCK=gBGjDKQg@mail.gmail.com>

Dear list members.


I would like to use gpg's symmetric encryption feature but with
passphrase hashing from either yescrypt or Argon2id.

Neither of them seem to be natively supported, so I wondered whether
the following would actually work out as I have it in mind.


To my understanding a KDF like yescrypt or what gpg uses
("String-to-Key") has these purposes:

1. obtain a key in a format that can be used for the cipher (like
having the proper length or so)
2. protect against certain attacks like dictionary-attacks by adding
e.g. a salt
3. give some protection of low-entropy passphrases by making the
derivation more expensive to an attacker (e.g. CPU or memory-wise)


So as far as I understand, if I'd have a high-entropy passphrase, e.g.
something gained from:
dd if=/dev/random of=key bs=1 count=512
I wouldn't need the KDF at all, at least not with respect to point 3
above, right?



I tried to find out what gpg does here and it seems it's one of the following:
A. When doing just --symmetric, it applies that String-to-Key function
to the passphrase and uses the result directly as symmetric key for
the file.
B. When doing --symmetric and --encrypt, it somehow creates a key
for the file (/dev/random?), and encrypts that with the KDF derived
key and with the pubkey.

And for the KDF it seems to allow specifying the iterations
(--s2k-count), and cipher (--s2k-cipher-algo) and hash
(--s2k-digest-algo).


Is --s2k-cipher-algo even used in (A)? And --s2k-digest-algo in (B)?




Now for my original goal of using yescrypt or Argon2id with gpg, would
the following work out and improve security?

read -rs -p 'Enter passphrase: ' PASSPHRASE

printf '%s' "${PASSPHRASE}"  |  argon2 mysaltvalue -id -r  |  gpg
--passphrase-fd 0 --symmetric ...


unset PASSPHRASE


While this works, I'm not so sure whether it actually gives a security
benefit in the cases (A) and (B) above, because there's still
String-to-key in between with whatever cipher, digest and iteration
count.

Wouldn't an attacker simply focus on that element of the chain?
Or do I actually win something, cause the derivation from the
passphrase is now pretty strong with Argon2id or yescrypt and all gpg
does is another round of 1-n hashings with some algorithm?

It kinda feels as if it might work for (A) but not for (B).

Or should one use --s2k-count 0 here (no salt no iterations) because
this is already done by e.g. Argon2id?


Thanks for any help,
Philippe

PS: Please keep me CC'ed. Thanks!


From wk at gnupg.org  Thu Aug 19 14:12:55 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Aug 2021 14:12:55 +0200
Subject: Smartcard Status Message Inconsistency
In-Reply-To: <CAKz+fXNvYNJxdCQNqK+_UP7cW+FMUzvS_6tw00miJRcF=UZ+qA@mail.gmail.com>
 (Joey Berkovitz via Gnupg-users's message of "Fri, 6 Aug 2021 18:36:18
 -0400")
References: <CAKz+fXNvYNJxdCQNqK+_UP7cW+FMUzvS_6tw00miJRcF=UZ+qA@mail.gmail.com>
Message-ID: <878s0xws3c.fsf@wheatstone.g10code.de>

Hi!

On Fri,  6 Aug 2021 18:36, Joey Berkovitz said:
> I was looking through the Smartcard commands and found that while most
> commands related to attribute changes output an SC_OP_SUCCESS, except for
> the name change command which doesn't output a success message on the
> status-fd.

Probably an overview or lazyness in 2009.  I just added this to master.
Thanks for reporting.


Shalom-Salam,

   Werner

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

From wk at gnupg.org  Thu Aug 19 15:22:36 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Aug 2021 15:22:36 +0200
Subject: gpg-wks-client generates empty files
In-Reply-To: <20210731210542.pfftewek7umzhwos@jotoho.de> (Jonas Tobias Hopusch
 via Gnupg-users's message of "Sat, 31 Jul 2021 23:05:42 +0200")
References: <20210731210542.pfftewek7umzhwos@jotoho.de>
Message-ID: <874kblwov7.fsf@wheatstone.g10code.de>

Hi!

On Sat, 31 Jul 2021 23:05, Jonas Tobias Hopusch said:

> Does anyone know what may have gone wrong? Is there any additional information I
> can provide to help with tracking down what I presume to be a bug?

It took me a while to track this down.  If you look closely at the
listing:

pub   rsa4096/612F3350DB59D359 2021-01-27 [C] [verf?llt: 2024-01-27]
  Schl.-Fingerabdruck = 1F42 EF02 BE3E 6FE8 F624  C8BC 612F 3350 DB59 D359
uid              [vollst?ndig]  (Domain owner of jotoho.de) <hostm[...]
                               ^- Here is leading blank.

gpg --list-packets makes it easier to see:

:user ID packet: " (Domain owner of jotoho.de) <hostmaster at jotoho.de>"
                  ^
Although that is somewhat peculiar it does not harm.  But,
gpg-wks-client does some processing of the key:

1. It list all mail addresses from the key and matches them to the
   requested mail address.  (in your example hostmaster at ...)

2. Now it may happen tha there are several user-ids all with the same
   mail address.  gpg-wks-tools picks one of them and then extracts
   exactly that user id - however in this case it does not match by the
   mail address but by the full user-id so that there will be only one
   user-id in the final key.

3. The filter built expression unfortunately strips leading blanks but
   requires a verbatim match.  Thus it won't find the user id again and
   errors out.

Right there is a second error that the empty file should not have been
written.  But after all that error should never happen.

I need to see how I can avoid to trim the leading space from the filter
expression.


Salam-Shalom,

   Werner


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

From derek.hoffmann at gmail.com  Thu Aug 19 18:40:09 2021
From: derek.hoffmann at gmail.com (Derek C Hoffmann)
Date: Thu, 19 Aug 2021 12:40:09 -0400
Subject: MS Surface Go Sim Card appears to cause scdaemon crash
Message-ID: <CA+_4pB9JE65HsuecrmT8wTAoVT4n1_h88ctv=pRWG_uivfjNhw@mail.gmail.com>

It looks like scdaemon is crashing when attempting to access a sim card
slot/sim card itself on my Surface Go.  When looking at the scdaemon.conf
file there is the option to define a specific reader-port, but I couldn't
find a way to ignore specific readers.  Am I missing something, or is this
not an option currently?  Any other suggestions as to prevent this crash
without disabling the Mobile Broadband card?

*With the device enabled:*

PS C:\Users\derek> gpg --card-status
gpg: selecting card failed: End of file
gpg: OpenPGP card not available: End of file
---
2021-08-19 12:02:19 scdaemon[9544.1] DBG: chdir to '/tmp' failed: No such
file or directory
2021-08-19 12:02:19 scdaemon[9544.1] listening on socket
'C:\\Users\\derek\\AppData\\Roaming\\gnupg\\S.scdaemon'
2021-08-19 12:02:19 scdaemon[9544.2] handler for fd -1 started
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 -> OK GNU Privacy
Guard's Smartcard server ready
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 <- GETINFO
socket_name
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 -> D
C:\Users\derek\AppData\Roaming\gnupg\S.scdaemon
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 -> OK
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 <- OPTION
event-signal=290
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 -> OK
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 <- GETINFO version
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 -> D 2.3.1
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 -> OK
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 <- SERIALNO
2021-08-19 12:02:19 scdaemon[9544.2] detected reader 'Microsoft IFD 0'
*2021-08-19 12:02:19 scdaemon[9544.2] detected reader 'Microsoft UICC ISO
Reader 4fc9c139 0'*
2021-08-19 12:02:19 scdaemon[9544.2] DBG: apdu_open_reader: Microsoft IFD 0
2021-08-19 12:02:19 scdaemon[9544.2] DBG: apdu_open_reader: new
device=Microsoft IFD 0
2021-08-19 12:02:19 scdaemon[9544.2] reader slot 0: not connected
2021-08-19 12:02:19 scdaemon[9544.2] DBG: enter: apdu_connect: slot=0
2021-08-19 12:02:19 scdaemon[9544.2] pcsc_connect failed: removed card
(0x80100069)
2021-08-19 12:02:19 scdaemon[9544.2] reader slot 0: not connected
2021-08-19 12:02:19 scdaemon[9544.2] DBG: leave: apdu_connect => sw=0x10008
2021-08-19 12:02:19 scdaemon[9544.2] DBG: chan_0x000002d4 -> S PINCACHE_PUT
0//
2021-08-19 12:02:19 scdaemon[9544.2] DBG: enter: apdu_close_reader: slot=0
2021-08-19 12:02:19 scdaemon[9544.2] DBG: enter: apdu_disconnect: slot=0
2021-08-19 12:02:19 scdaemon[9544.2] DBG: leave: apdu_disconnect => sw=0x0
2021-08-19 12:02:19 scdaemon[9544.2] DBG: leave: apdu_close_reader => 0x0
(close_reader)


*2021-08-19 12:02:19 scdaemon[9544.2] DBG: apdu_open_reader:
(null)2021-08-19 12:02:19 scdaemon[9544.2] DBG: apdu_open_reader: new
device=(null)*
-------

*With the device disabled in device manager:*

PS C:\Users\derek> gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
---
2021-08-19 12:14:20 scdaemon[7468.1] DBG: chdir to '/tmp' failed: No such
file or directory
2021-08-19 12:14:20 scdaemon[7468.1] listening on socket
'C:\\Users\\derek\\AppData\\Roaming\\gnupg\\S.scdaemon'
2021-08-19 12:14:20 scdaemon[7468.2] handler for fd -1 started
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> OK GNU Privacy
Guard's Smartcard server ready
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 <- GETINFO
socket_name
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> D
C:\Users\derek\AppData\Roaming\gnupg\S.scdaemon
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> OK
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 <- OPTION
event-signal=290
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> OK
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 <- GETINFO version
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> D 2.3.1
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> OK
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 <- SERIALNO
2021-08-19 12:14:20 scdaemon[7468.2] detected reader 'Microsoft IFD 0'
2021-08-19 12:14:20 scdaemon[7468.2] DBG: apdu_open_reader: Microsoft IFD 0
2021-08-19 12:14:20 scdaemon[7468.2] DBG: apdu_open_reader: new
device=Microsoft IFD 0
2021-08-19 12:14:20 scdaemon[7468.2] reader slot 0: not connected
2021-08-19 12:14:20 scdaemon[7468.2] DBG: enter: apdu_connect: slot=0
2021-08-19 12:14:20 scdaemon[7468.2] pcsc_connect failed: removed card
(0x80100069)
2021-08-19 12:14:20 scdaemon[7468.2] reader slot 0: not connected
2021-08-19 12:14:20 scdaemon[7468.2] DBG: leave: apdu_connect => sw=0x10008
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> S PINCACHE_PUT
0//
2021-08-19 12:14:20 scdaemon[7468.2] DBG: enter: apdu_close_reader: slot=0
2021-08-19 12:14:20 scdaemon[7468.2] DBG: enter: apdu_disconnect: slot=0
2021-08-19 12:14:20 scdaemon[7468.2] DBG: leave: apdu_disconnect => sw=0x0
2021-08-19 12:14:20 scdaemon[7468.2] DBG: leave: apdu_close_reader => 0x0
(close_reader)
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> ERR 100696144
No such device <SCD>
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 <- RESTART
2021-08-19 12:14:20 scdaemon[7468.2] DBG: chan_0x000002d0 -> OK


*Version info:*
gpg --version
gpg (GnuPG) 2.3.1
libgcrypt 1.9.3

scdaemon --version
scdaemon (GnuPG) 2.3.1
libgcrypt 1.9.3
libksba 1.5.1

--
- Derek C Hoffmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210819/688b9049/attachment-0001.html>

From jotoho+mailinglist at mailbox.org  Thu Aug 19 17:14:02 2021
From: jotoho+mailinglist at mailbox.org (Jonas Tobias Hopusch)
Date: Thu, 19 Aug 2021 17:14:02 +0200
Subject: gpg-wks-client generates empty files
In-Reply-To: <874kblwov7.fsf@wheatstone.g10code.de>
References: <20210731210542.pfftewek7umzhwos@jotoho.de>
 <874kblwov7.fsf@wheatstone.g10code.de>
Message-ID: <20210819151402.rnpeedwnmk5il23s@jotoho.de>

Hello Werner.

> It took me a while to track this down.

It's good to see one of you respond to my mail. I was worried that maybe the
mailinglist broke both the SPF and DKIM checks and prevented it from being
delivered to the subscriber's mailboxes. To avoid that this time, I'm sending
this mail from another domain with less strict settings.

> pub   rsa4096/612F3350DB59D359 2021-01-27 [C] [verf?llt: 2024-01-27]
>   Schl.-Fingerabdruck = 1F42 EF02 BE3E 6FE8 F624  C8BC 612F 3350 DB59 D359
> uid              [vollst?ndig]  (Domain owner of jotoho.de) <hostm[...]
>                                ^- Here is leading blank.
> 
> gpg --list-packets makes it easier to see:
> 
> :user ID packet: " (Domain owner of jotoho.de) <hostmaster at jotoho.de>"
>                   ^
> Although that is somewhat peculiar it does not harm.  But,
> gpg-wks-client does some processing of the key:

It's been a few months since I generated the key with GnuPG so I don't know if I
put the extra spaces there. Maybe it's a consequence of leaving out my name
during UID creation? (Back then I was hesitant to put my name on that key though
my view on that is more relaxed by now.)

> 1. It list all mail addresses from the key and matches them to the
>    requested mail address.  (in your example hostmaster at ...)
> 
> 2. Now it may happen tha there are several user-ids all with the same
>    mail address.  gpg-wks-tools picks one of them and then extracts
>    exactly that user id - however in this case it does not match by the
>    mail address but by the full user-id so that there will be only one
>    user-id in the final key.
> 
> 3. The filter built expression unfortunately strips leading blanks but
>    requires a verbatim match.  Thus it won't find the user id again and
>    errors out.
> 
> Right there is a second error that the empty file should not have been
> written.  But after all that error should never happen.
> 
> I need to see how I can avoid to trim the leading space from the filter
> expression.

This question I'm asking myself at this explanation for the issue is why my
Gitea instance's signing key was also affected by the bug. (The one with the
autosign at gitea.jotoho.de UID)

When looking at that key with the terminal command 

> gpg --export 56105D315120E79B34C4D39516128FBFDB6214C9 | gpg --list-packets

there does not appear to be any whitespace in the UserID that shouldn't be there.

Do you mean by "Thus it won't find the user id again and errors out." that the
error when working with my domain management key also stops the software from
processing other keys, that come after it, properly?

I get the impression that maybe the code dealing with the different keys/uids
should be better isolated amongst each other so any error pertaining to key Y
doesn't also impact processing of key Z. I don't know the big picture or the code
in question though, so feel free to ignore my rambling.

In the meantime, I was able to generate a working Web Key Directory using Sequoia
and installed that on my domain so the issue has no urgency or immediate impact
for me. (Though it would be good to be able to get rid of those extra packages
again once gpg-wks-client works properly for me)

-- 
Jonas Tobias Hopusch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210819/ac5c661e/attachment.sig>

From n8fear at stackptr.de  Thu Aug 19 23:36:14 2021
From: n8fear at stackptr.de (HvB)
Date: Thu, 19 Aug 2021 23:36:14 +0200
Subject: Designated Revoker
Message-ID: <20210819233614.3cd107ed@TheHive.snrvn-alpha.sldf>

Hi,

is there a way to make a designated revoker on a key sensitive after it
is already added as normal designated revoker? I have a key with a
designated revoker that is incompatible with opengpgjs (because they
ignore the standard, afaict). If the designated revoker was marked
sensitive and therefore would not be exported I guess I could make the
key more usable for people trying to mail pgp-encrypted mails to me.

WKR H.


From gniibe at fsij.org  Fri Aug 20 08:47:53 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 20 Aug 2021 15:47:53 +0900
Subject: MS Surface Go Sim Card appears to cause scdaemon crash
In-Reply-To: <CA+_4pB9JE65HsuecrmT8wTAoVT4n1_h88ctv=pRWG_uivfjNhw@mail.gmail.com>
References: <CA+_4pB9JE65HsuecrmT8wTAoVT4n1_h88ctv=pRWG_uivfjNhw@mail.gmail.com>
Message-ID: <87o89sipd2.fsf@akagi.fsij.org>

Hello,

Derek C Hoffmann via Gnupg-users <gnupg-users at gnupg.org> wrote:
> It looks like scdaemon is crashing when attempting to access a sim card
> slot/sim card itself on my Surface Go.

It is my fault.  I added multiple card readers support (for PC/SC) to
GnuPG 2.3, and it causes an issue in your use case.  By default,
scdaemon tries to access all available card readers.  It has a bug
accessing the second reader when the first reader doesn't have a card.

Related bug is tracked at:

	https://dev.gnupg.org/T5416

And it will be fixed in GnuPG 2.3.2.

> Any other suggestions as to prevent this crash without disabling the
> Mobile Broadband card?

If you have a line in scdaemon.conf, like:

	reader-port Microsoft IFD 0

scdaemon will only access to the card reader.  Please try this, until
fixed version will be released.
-- 


From wk at gnupg.org  Fri Aug 20 16:45:03 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Aug 2021 16:45:03 +0200
Subject: gpg-wks-client generates empty files
In-Reply-To: <20210819151402.rnpeedwnmk5il23s@jotoho.de> (Jonas Tobias Hopusch
 via Gnupg-users's message of "Thu, 19 Aug 2021 17:14:02 +0200")
References: <20210731210542.pfftewek7umzhwos@jotoho.de>
 <874kblwov7.fsf@wheatstone.g10code.de>
 <20210819151402.rnpeedwnmk5il23s@jotoho.de>
Message-ID: <878s0wuqds.fsf@wheatstone.g10code.de>

On Thu, 19 Aug 2021 17:14, Jonas Tobias Hopusch said:

> It's good to see one of you respond to my mail. I was worried that maybe the
> mailinglist broke both the SPF and DKIM checks and prevented it from being

Sorry, for taking long to reply.

> It's been a few months since I generated the key with GnuPG so I don't know if I
> put the extra spaces there. Maybe it's a consequence of leaving out my name
> during UID creation? (Back then I was hesitant to put my name on that key though
> my view on that is more relaxed by now.)

I general we strip all leading and trailing spaces. But there are of
course ways to generate such a user-id, it is covered by the specs.

> This question I'm asking myself at this explanation for the issue is why my
> Gitea instance's signing key was also affected by the bug. (The one with the
> autosign at gitea.jotoho.de UID)

Well, this

           /* Fixme: Unescape fields[9] */
           if (!append_to_uidinfo_list (&mboxes, fields[9],

explains it.  gpg --with-colons returns the user-id with C-style
escapes.  The "https://" has a colon and thus needs escaping.

I have pushed fixes for both bugs to 2.3 and 2.2


Shalom-Salam,

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

From derek.hoffmann at gmail.com  Mon Aug 23 18:02:32 2021
From: derek.hoffmann at gmail.com (Derek C Hoffmann)
Date: Mon, 23 Aug 2021 12:02:32 -0400
Subject: MS Surface Go Sim Card appears to cause scdaemon crash
In-Reply-To: <87o89sipd2.fsf@akagi.fsij.org>
References: <CA+_4pB9JE65HsuecrmT8wTAoVT4n1_h88ctv=pRWG_uivfjNhw@mail.gmail.com>
 <87o89sipd2.fsf@akagi.fsij.org>
Message-ID: <CA+_4pB8QmWorUv1wMKR=uvAGbs5eGJVDUZGUJc-uHny78jSAkA@mail.gmail.com>

Thanks, good to know that it's a known issue and being worked on, looking
forward to the next update!

Just FYI though, the indicated workaround doesn't seem to work unless the
intended card reader for gpg is listed first:

I have another system I just started working on which needs two different
smart cards (Gemalto eToken Pro for work, and yubikey for personal use,
which is what I use with gpg).  The gemalto card readers are listed first,
and even putting various versions of 'reader-port Yubico YubiKey
OTP+FIDO+CCID 0', 'reader-port Yubico YubiKey', 'reader-port Yubico Yubi'
in scdaemon.conf result in the same behaviour.

2021-08-21 09:53:11 scdaemon[16820.1] DBG: chdir to '/tmp' failed: No such
file or directory
2021-08-21 09:53:11 scdaemon[16820.1] listening on socket
'C:\\Users\\derek\\AppData\\Roaming\\gnupg\\S.scdaemon'
2021-08-21 09:53:11 scdaemon[16820.2] handler for fd -1 started
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK GNU
Privacy Guard's Smartcard server ready
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- GETINFO
socket_name
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> D
C:\Users\derek\AppData\Roaming\gnupg\S.scdaemon
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- OPTION
event-signal=2bc
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- GETINFO
version
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> D 2.3.1
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- SERIALNO
2021-08-21 09:53:11 scdaemon[16820.2] detected reader 'AKS ifdh 0'
2021-08-21 09:53:11 scdaemon[16820.2] detected reader 'AKS ifdh 1'
2021-08-21 09:53:11 scdaemon[16820.2] detected reader 'Yubico YubiKey
OTP+FIDO+CCID 0'
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: AKS ifdh 0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: new device=AKS
ifdh 0
2021-08-21 09:53:11 scdaemon[16820.2] reader slot 0: not connected
2021-08-21 09:53:11 scdaemon[16820.2] DBG: enter: apdu_connect: slot=0
2021-08-21 09:53:11 scdaemon[16820.2] pcsc_connect failed: removed card
(0x80100069)
2021-08-21 09:53:11 scdaemon[16820.2] reader slot 0: not connected
2021-08-21 09:53:11 scdaemon[16820.2] DBG: leave: apdu_connect => sw=0x10008
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> S
PINCACHE_PUT 0//
2021-08-21 09:53:11 scdaemon[16820.2] DBG: enter: apdu_close_reader: slot=0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: enter: apdu_disconnect: slot=0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: leave: apdu_disconnect => sw=0x0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: leave: apdu_close_reader => 0x0
(close_reader)
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: (null)
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: new
device=(null)


For now I've fallen back to 2.2

--
Derek C Hoffmann


On Fri, Aug 20, 2021 at 2:48 AM NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> Derek C Hoffmann via Gnupg-users <gnupg-users at gnupg.org> wrote:
> > It looks like scdaemon is crashing when attempting to access a sim card
> > slot/sim card itself on my Surface Go.
>
> It is my fault.  I added multiple card readers support (for PC/SC) to
> GnuPG 2.3, and it causes an issue in your use case.  By default,
> scdaemon tries to access all available card readers.  It has a bug
> accessing the second reader when the first reader doesn't have a card.
>
> Related bug is tracked at:
>
>         https://dev.gnupg.org/T5416
>
> And it will be fixed in GnuPG 2.3.2.
>
> > Any other suggestions as to prevent this crash without disabling the
> > Mobile Broadband card?
>
> If you have a line in scdaemon.conf, like:
>
>         reader-port Microsoft IFD 0
>
> scdaemon will only access to the card reader.  Please try this, until
> fixed version will be released.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210823/89a6574e/attachment-0001.html>

From wk at gnupg.org  Tue Aug 24 19:51:51 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 24 Aug 2021 19:51:51 +0200
Subject: [Announce] GnuPG 2.3.2 released
Message-ID: <87eeaispc8.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.3.2.  This is the third release in the new 2.3 series which
fixes a couple of bugs and adds a few new things.  See below for
details.


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

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

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

GnuPG 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.

Three different series of GnuPG are actively maintained:

- Version 2.3 is the latest development series with a lot of new
  features.  This announcement is about the latest release of this
  series.

- Version 2.2 is our LTS (long term support) version and guaranteed to
  be maintained at least until the end of 2024.
  See https://gnupg.org/download/index.html#end-of-life

- Version 1.4 is maintained to allow decryption of very old data which
  is, for security reasons, not anymore possible with other GnuPG
  versions.


Noteworthy changes in version 2.3.2
===================================

  * gpg: Allow fingerprint based lookup with --locate-external-key.
    [ec36eca08c]

  * gpg: Allow decryption w/o public key but with correct card
    inserted.  [50293ec2eb]

  * gpg: Auto import keys specified with --trusted-keys.  [100037ac0f]

  * gpg: Do not use import-clean for LDAP keyserver imports.  [#5387]

  * gpg: Fix mailbox based search via AKL keyserver method.  [4fcfac6feb]

  * gpg: Fix memory corruption with --clearsign introduced with 2.3.1.
    [#5430]

  * gpg: Use a more descriptive prompt for symmetric decryption.
    [6dfae2f402]

  * gpg: Improve speed of secret key listing.  [40da61b89b]

  * gpg: Support keygrip search with traditional keyring.  [#5469]

  * gpg: Let --fetch-key return an exit code on failure.  [#5376]

  * gpg: Emit the NO_SECKEY status again for decryption.  [#5562]

  * gpgsm: Support decryption of password based encryption (pwri).
    [eeb65d3bbd]

  * gpgsm: Support AES-GCM decryption.  [4980fb3c6d]

  * gpgsm: Let --dump-cert --show-cert also print an OpenPGP
    fingerprint.  [52bbdc731f]

  * gpgsm: Fix finding of issuer in use-keyboxd mode.  [6b76693ff5]

  * gpgsm: New option --ldapserver as an alias for --keyserver.
    [89df86157e]

  * agent: Use SHA-256 for SSH fingerprint by default.  [#5434]

  * agent: Fix calling handle_pincache_put.  [#5436]

  * agent: Fix importing protected secret key.  [#5122]

  * agent: Fix a regression in agent_get_shadow_info_type.  [#5393]

  * agent: Add translatable text for Caps Lock hint.  [#4950]

  * agent: New option --pinentry-formatted-passphrase.  [#5517]

  * agent: Add checkpin inquiry for pinentry.  [#5517,#5532]

  * agent: New option --check-sym-passphrase-pattern.  [#5517]

  * agent: Use the sysconfdir for a pattern file.

  * agent: Make QT_QPA_PLATFORMTHEME=qt5ct work for the pinentry.
    [1305baf099]

  * dirmngr: LDAP search by a mailbox now ignores revoked keys.
    [1406f551f1]

  * dirmngr: For KS_SEARCH return the fingerprint also with LDAP.
    [#5441]

  * dirmngr: Allow for non-URL specified ldap keyservers.  [#5405,#5452]

  * dirmngr: New option --ldapserver.  [52cf32ce2f]

  * dirmngr: Fix regression in KS_GET for mail address pattern.
    [#5497]

  * card: New option --shadow for the list command.  [2fce99d73a]

  * tests: Make sure the built keyboxd is used.  [#5406]

  * scd: Fix computing shared secrets for 512 bit curves.
    [9e24f2a45c]

  * scd: Fix unblock PIN by a Reset Code with KDF.  [#5413]

  * scd: Fix PC/SC removed card problem.  [8d81fd7c01]

  * scd: Recover the partial match for PORTSTR for PC/SC.
   [53bdc6288f]

  * scd: Make sure to release the PC/SC context.  [#5416]

  * scd: Fix zero-byte handling in ECC.  [#5163]

  * scd: Fix serial number detection for Yubikey 5.  [#5442]

  * scd: Add basic support for AET JCOP cards.  [544ec7872a]

  * scd: Detect external interference when --pcsc-shared is in use.
    [#5484]

  * scd: Fix access to the list of cards.  [#5524]

  * gpgconf: Do not list a disabled tpm2d.  [#5408]

  * gpgconf: Make runtime changes with different homedir work.
    [31c0aa2ff3]

  * keyboxd: Fix searching for exact mail adddress.  [f79e9540ca]

  * keyboxd: Fix searching with multiple patterns.  [101ba4f18a]

  * gpgtar: Fix file size computation under Windows.  [14e36bdbe1]

  * tools: Extend gpg-check-pattern.  [73c03e0232]

  * wkd: Fix client issue with leading or trailing spaces in
    user-ids.  [b4345f7521]

  * Under Windows add a fallback in case the console can't cope with
    Unicode.  [#5491]

  * Under Windows use LOCAL_APPDATA for the socket directory.  [#5537]

  * Pass XDG_SESSION_TYPE and QT_QPA_PLATFORM envvars to Pinentry.
    [#3659]

  * Change the default keyserver to keyserver.ubuntu.com.  This is a
    temporary change due to the shutdown of the SKS keyserver pools.
    [55b5928099]

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


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

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

GnuPG 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.3.2.tar.bz2 (7411k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.2.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.3.2_20210824.exe (4586k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.2_20210824.exe.sig

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

If you want to use this GnuPG versions with Gpg4win simply install it on
on top of Gpg4win 3.1.16.


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

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

     sha1sum gnupg-2.3.2.tar.bz2

   and check that the output matches the next line:

f0f44b29e3702d3be1b25c964dfc2aaefe70e2fc  gnupg-2.3.2.tar.bz2
7c8ff377310f9781b89efb06222e7e74a19ed477  gnupg-w32-2.3.2_20210824.tar.xz
f6c1591e06ee2801961e216f44bc67243e87576f  gnupg-w32-2.3.2_20210824.exe


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

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


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

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the 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/T5405 for updated information.

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

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


Thanks
======

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

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, or answering questions on the mailing
lists.

The financial support of the governmental CERT of Luxembourg
(GOVCERT.LU) allowed us to develop new and improved features for
smartcards (Yubikey, PIV and Scute) as well as various usability
features.  Thanks.

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


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:

  ed25519 2020-08-24 [expires: 2030-06-30]
  Key fingerprint = 6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
  Werner Koch (dist signing 2020)

  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)

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

The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

--
Please read

  Nils Melzer: Der Fall Julian Assange

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

From xylene2016 at gmail.com  Wed Aug 25 22:51:16 2021
From: xylene2016 at gmail.com (William Holmes)
Date: Wed, 25 Aug 2021 16:51:16 -0400
Subject: gpg: keydb_get_keyblock failed: Invalid object
Message-ID: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>

Hi,
gpg failed after I created a second sign-only Curve 448 key.

# gpg2 --version
gpg (GnuPG) 2.3.2
libgcrypt 1.9.4

# gpg2 --full-gen-key
...
Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 9
Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
Your selection? 2
...

# gpg2 --edit-key testkey1
gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (12) ECC (encrypt only)
  (13) Existing key
  (14) Existing key from card
Your selection? 10
Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
Your selection? 2
..
gpg> save

# gpg2 -k
gpg: keydb_get_keyblock failed: Invalid object
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210825/b4455fdd/attachment.html>

From thomas.cage at hotmail.com  Wed Aug 25 23:36:29 2021
From: thomas.cage at hotmail.com (Thomas Cage)
Date: Wed, 25 Aug 2021 21:36:29 +0000
Subject: Decryption w/o public key does not work in GnuPG 2.3.2
Message-ID: <MN2PR17MB39172AEDDD2C4F53E27485D6EDC69@MN2PR17MB3917.namprd17.prod.outlook.com>

Hi,

I have installed the new 2.3.2 version which supports "decryption w/o public key but with correct card inserted" with commit 50293ec2eb.

I have tried it out with a couple files encrypted with a public key that got lost recently but the private key remains in my smart card. $ gpg --card-status can list the keys when I insert my smart card, but $ gpg --decrypt [FILE] returns the foollwing as if the private key never detected:
```
gpg: encrypted with RSA key, ID 9AEE7E2751187094
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
```

Am I using this feature in the correct way? I just hope my files won't get lost forever. Thanks a lot!

Regards,
Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210825/ec0c9494/attachment-0001.html>

From thomas.cage at hotmail.com  Thu Aug 26 01:35:02 2021
From: thomas.cage at hotmail.com (Thomas Cage)
Date: Wed, 25 Aug 2021 23:35:02 +0000
Subject: Decryption w/o public key does not work in GnuPG 2.3.2
Message-ID: <MN2PR17MB39174D924D82515784549093EDC69@MN2PR17MB3917.namprd17.prod.outlook.com>

Hi,

I have installed the new 2.3.2 version which supports "decryption w/o public key but with correct card inserted" with commit 50293ec2eb.

I have tried it out with a couple files encrypted with a public key that got lost recently but the private key remains in my smart card. $ gpg --card-status can list the keys when I insert my smart card, but no shadow keys are generated and $ gpg --decrypt [FILE] returns the following as if the private key has never been detected:
```
gpg: encrypted with RSA key, ID 9AEE7E2751187094
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
```

Am I using this feature in the correct way? I just hope my files won't get lost forever. Thanks a lot!

Regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210825/923b2cc1/attachment.html>

From gniibe at fsij.org  Thu Aug 26 10:25:14 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 26 Aug 2021 17:25:14 +0900
Subject: gpg: keydb_get_keyblock failed: Invalid object
In-Reply-To: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>
References: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>
Message-ID: <87eeagr4t1.fsf@akagi.fsij.org>

Hello,

Thank you for your report.

William Holmes wrote:
> gpg failed after I created a second sign-only Curve 448 key.

Please use --quick-add-key instead, while I'm fixing the bug.

My changes of following commits were not enough.

	2b50f942672d9a2c325a818f21f69d3ee69255d3
	36355394d865f5760075e62267d70f7a7d5dd671

I think that something like this will be needed to apply.

Please note that 448 keys are not yet standardized as OpenPGP.  So,
format for key, signature, encrypted data may be changed in future.

diff --git a/g10/keygen.c b/g10/keygen.c
index 239e7aca1..cb6487ea3 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -5879,7 +5879,12 @@ generate_subkeypair (ctrl_t ctrl, kbnode_t keyblock, const char *algostr,
       else if (algo == PUBKEY_ALGO_ECDSA
                || algo == PUBKEY_ALGO_EDDSA
                || algo == PUBKEY_ALGO_ECDH)
-        curve = ask_curve (&algo, NULL, NULL);
+        {
+          curve = ask_curve (&algo, NULL, NULL);
+
+          if (curve && (!strcmp (curve, "X448") || !strcmp (curve, "Ed448")))
+            keygen_flags |= KEYGEN_FLAG_CREATE_V5_KEY;
+        }
       else
         nbits = ask_keysize (algo, 0);
 
-- 


From wk at gnupg.org  Thu Aug 26 11:00:10 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Aug 2021 11:00:10 +0200
Subject: Decryption w/o public key does not work in GnuPG 2.3.2
In-Reply-To: <MN2PR17MB39172AEDDD2C4F53E27485D6EDC69@MN2PR17MB3917.namprd17.prod.outlook.com>
 (Thomas Cage via Gnupg-users's message of "Wed, 25 Aug 2021 21:36:29
 +0000")
References: <MN2PR17MB39172AEDDD2C4F53E27485D6EDC69@MN2PR17MB3917.namprd17.prod.outlook.com>
Message-ID: <87zgt4r36t.fsf@wheatstone.g10code.de>

Hi!

On Wed, 25 Aug 2021 21:36, Thomas Cage said:

> I have installed the new 2.3.2 version which supports "decryption w/o
> public key but with correct card inserted" with commit 50293ec2eb.

The description is a bit too brief.  What we do is to lookup the key on
a configured LDAP server.  This allows to start using a new box
immediately by simply inserting your smartcard.  It is a feature for
largers deployments.

> I have tried it out with a couple files encrypted with a public key
> that got lost recently but the private key remains in my smart card. $

You need to get the public key or re-create it.  To do this you need to
know the creation time.  This can be done by looping over a range of
dates - unfortunately tehre is still no tool to do this.

> Am I using this feature in the correct way? I just hope my files won't
> get lost forever. Thanks a lot!

It is a matter ot the available tools or the time required to write them
:-(


Shalom-Salam,

   Werner

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

From mlnl at mailbox.org  Thu Aug 26 11:37:45 2021
From: mlnl at mailbox.org (mlnl)
Date: Thu, 26 Aug 2021 11:37:45 +0200
Subject: gpg: keydb_get_keyblock failed: Invalid object
In-Reply-To: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>
References: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>
Message-ID: <20210826113745.0190f846@localhost>

Hi,

>gpg: keydb_get_keyblock failed: Invalid object

key delete and importing a revocation cert fails too:

$ gpg --delete-secret-and-public-keys key-id
gpg: Error reading the key block: invalid object
gpg: key-id: delete key failed: invalid object

$ gpg_importkey .gnupg/openpgp-revocs.d/key-id.rev
gpg: No valid OpenPGP data found.


-- 
mlnl

GPG:1FC05426F87FA623


From mlnl at mailbox.org  Thu Aug 26 11:29:03 2021
From: mlnl at mailbox.org (mlnl)
Date: Thu, 26 Aug 2021 11:29:03 +0200
Subject: gpg: keydb_get_keyblock failed: Invalid object
In-Reply-To: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>
References: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>
Message-ID: <20210826112903.54fa407a@localhost>

Hi,

># gpg2 -k
>gpg: keydb_get_keyblock failed: Invalid object

Me too with "gpg --list-public-keys user-id", after ich created a key
with:
ed448 (C)
ed25519 (S)
cv25519 (E)

-- 
mlnl

GPG:1FC05426F87FA623


From fred at silberberg.xyz  Wed Aug 25 21:09:27 2021
From: fred at silberberg.xyz (Fredric Silberberg)
Date: Wed, 25 Aug 2021 12:09:27 -0700
Subject: Windows Hello Interference on 2.3.X
Message-ID: <CAKau9Ki-7+M7fAcNrPOpKbbFo-DqUyCKe9tnRXRpW+7k+jVT0w@mail.gmail.com>

Hi folks,

It appears some changes in the 2.3.X branch have broken my Yubikey OpenPGP
key on systems that also have a Windows Hello for Business PIN set up.
Here's the behavior I'm seeing:

scdaemon.conf:

debug-level guru
log-file "%APPDATA%\gnupg\scdaemon.log"
reader-port "Yubico YubiKey OTP+FIDO+CCID 0"

2.2.29: The above works, gpg --card-status returns info on my Yubikey.

2.3.0/1: gpg --card-status returns:
gpg: selecting card failed: End of file
gpg: OpenPGP card not available: End of file

Log file: attached, scdaemon.2.3.1.log

2.3.2: gpg --card-status enters an infinite loop, never completing and
pegging a single CPU as hard as it can. The log file output is attached,
scdaemon.2.3.2.log. I've clipped it to not overwhelm inboxes, but the last
two lines will continuously repeat, making the file as big as you let it
run.

I'd appreciate any help or insight into what's going on here. For the
moment, I'm still using 2.2.29 because the 2.3.X versions are totally
busted for me.

Thanks,
- Fred Silberberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210825/7c81fefa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scdaemon.2.3.1.log
Type: application/octet-stream
Size: 5384 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210825/7c81fefa/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scdaemon.2.3.2.log
Type: application/octet-stream
Size: 1460 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210825/7c81fefa/attachment-0003.obj>

From xylene2016 at gmail.com  Thu Aug 26 16:21:27 2021
From: xylene2016 at gmail.com (William Holmes)
Date: Thu, 26 Aug 2021 10:21:27 -0400
Subject: gpg: keydb_get_keyblock failed: Invalid object
In-Reply-To: <87eeagr4t1.fsf@akagi.fsij.org>
References: <CAMSQ2vi1fmfGOwn9RwRJU1Vkv-n7UTnu9oOAxT7Jhd9wEcGCnw@mail.gmail.com>
 <87eeagr4t1.fsf@akagi.fsij.org>
Message-ID: <CAMSQ2vjKhEYgvaDL4HVZ31OQBv1MpFm9SmaW56DR4jtvhjrmyw@mail.gmail.com>

Hi,
Not just sign-only Curve 448 subkey, gpg will fail after any subkey
(RSA/ECC [S]/[E]/[A]/[C]) is created when a keypair is generated with Curve
448.
When gpg fails, how can I recover keys?
This is so important.
This bug will destroy keydb, it is a "big" issue.

_____________________________________

On Thu, Aug 26, 2021 at 4:25 AM NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> Thank you for your report.
>
> William Holmes wrote:
> > gpg failed after I created a second sign-only Curve 448 key.
>
> Please use --quick-add-key instead, while I'm fixing the bug.
>
> My changes of following commits were not enough.
>
>         2b50f942672d9a2c325a818f21f69d3ee69255d3
>         36355394d865f5760075e62267d70f7a7d5dd671
>
> I think that something like this will be needed to apply.
>
> Please note that 448 keys are not yet standardized as OpenPGP.  So,
> format for key, signature, encrypted data may be changed in future.
>
> diff --git a/g10/keygen.c b/g10/keygen.c
> index 239e7aca1..cb6487ea3 100644
> --- a/g10/keygen.c
> +++ b/g10/keygen.c
> @@ -5879,7 +5879,12 @@ generate_subkeypair (ctrl_t ctrl, kbnode_t
> keyblock, const char *algostr,
>        else if (algo == PUBKEY_ALGO_ECDSA
>                 || algo == PUBKEY_ALGO_EDDSA
>                 || algo == PUBKEY_ALGO_ECDH)
> -        curve = ask_curve (&algo, NULL, NULL);
> +        {
> +          curve = ask_curve (&algo, NULL, NULL);
> +
> +          if (curve && (!strcmp (curve, "X448") || !strcmp (curve,
> "Ed448")))
> +            keygen_flags |= KEYGEN_FLAG_CREATE_V5_KEY;
> +        }
>        else
>          nbits = ask_keysize (algo, 0);
>
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210826/fea23000/attachment.html>

From klaus+gnupg at ethgen.ch  Thu Aug 26 17:23:16 2021
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Thu, 26 Aug 2021 16:23:16 +0100
Subject: gpg-agent and X
In-Reply-To: <YEH2+T/146OVr7w3@ikki.ethgen.ch>
References: <YEH2+T/146OVr7w3@ikki.ethgen.ch>
Message-ID: <YSex5HvKeoUm13i6@ikki.ethgen.ch>

Hi,

I have an update for this issue.

It seems that I have the problem all time I use the QT pinentry. The
gtk2 pinentry seems to be fine and with the switch to QT one, the
problem appears. Now I have the problem on debian and gentoo.

Even more, a `gpg-connect-agent updatestartuptty /bye` over ssh
connection does not work with pinentry-qt.

Unfortunately, the gtk3 version of pinentry has some toxic dependencies
that I never want to have.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 688 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210826/70f707b1/attachment.sig>

From l0f4r0 at tuta.io  Fri Aug 27 13:07:22 2021
From: l0f4r0 at tuta.io (l0f4r0 at tuta.io)
Date: Fri, 27 Aug 2021 13:07:22 +0200 (CEST)
Subject: [OT] Tutanota security/privacy concerns (was: Re: How would you do
 that ...)
In-Reply-To: <eb02a21a-8e03-57db-8678-16d94f2c7317@posteo.ru>
References: <b1e841fe-2eb4-b8b7-6b1c-9e543e9322ed@posteo.ru>
 <MvmFiM3_W9gYjO_KLbs5S9_WW9pBnLwosdF6kbTR32NBlm1N9Of1K4qkIZBoEViACTDYaoJvlB05wx4U7ThrVWCPYJin677f1FwGHQb4BLM=@digicana.com>
 <b40d96a3-3edc-3c4b-7d46-3a18f9c0ed22@posteo.ru>
 <0C3CE731-E12F-42BE-9D52-DBCBBA6DDD6A@digicana.com>
 <e7225829-d8e8-c181-34d2-b5cd582543ad@posteo.ru> <M_9zJv7--3-2@tuta.io>
 <61c3f67a-6402-55fb-8366-a871ce729353@posteo.ru>
 <eb02a21a-8e03-57db-8678-16d94f2c7317@posteo.ru>
Message-ID: <Mi6Hj8h--3-2@tuta.io>

Hi Stefan, all,

Oops, I think I wanted to react sooner but didn't visibly...

8 mai 2021, 15:12 de stefan.vasilev at posteo.ru:

>> l0f4r0 wrote:
>>
>>> I don't use ProtonMail so I can't say.
>>>
>>> But otherwise you have Tutanota (no phone number required):
>>> https://tutanota.com/blog/posts/anonymous-email/
>>>
> BTW. Tutanota does (full???) Browser fingerprinting and they where required
>
> to 'upgrade' their email service.
>
Thanks for the notice.

So are you implying Tutanota does not do browser fingerprinting anymore?
Actually, I cannot find any public source about this. Would you have some pointers to share please?

While we are at it, by any chance, do you/people have (other) complaints/concerns about Tutanota from a security or privacy points of view?

Thanks in advance :)

Best regards,
l0f4r0


From wk at gnupg.org  Fri Aug 27 15:08:19 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 27 Aug 2021 15:08:19 +0200
Subject: [Announce] GnuPG 2.2.30 (LTS) released
Message-ID: <87mtp3qblo.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG LTS release:
version 2.2.30.  This release fixes a few minor bugs and improves the
usability of symmetric-only encryption.  The LTS (long term support)
series of GnuPG is guaranteed to be maintained at least until the end
of 2024.  See https://gnupg.org/download/index.html#end-of-life


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

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

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

GnuPG 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.30 (2021-08-26)
=================================================

  * gpg: Extended gpg-check-pattern to support accept rules,
    conjunctions, and case-sensitive matching.  [5ca15e58b2]

  * agent: New option --pinentry-formatted-passphrase.  [#5553]

  * agent: New option --check-sym-passphrase-pattern.  [#5517]

  * agent: Use the sysconfdir for the pattern files.  [5ed8e598fa]

  * agent: Add "checkpin" inquiry for use by pinentry.  [#5532]

  * wkd: Fix client issue with leading or trailing spaces in
    user-ids.  [576e429d41]

  * Pass XDG_SESSION_TYPE and QT_QPA_PLATFORM envvars to Pinentry.
    [#3659]

  * Under Windows use LOCAL_APPDATA for the socket directory.  [#5537]

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


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

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

GnuPG 2.2.30 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.30.tar.bz2 (7046k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.30.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.30_20210826.exe (4393k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.30_20210826.exe.sig

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

A new version of Gpg4win will probably not be published.  Users affected
by one of the fixed bugs may instead install this version on top of
Gpg4win 3.1.16.


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

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

     sha1sum gnupg-2.2.30.tar.bz2

   and check that the output matches the next line:

bf9908b1a36b2bd1a4b9f0890198e8fb2d77a91c  gnupg-2.2.30.tar.bz2
2de8c54af9387c1068cba06ef23ac197dac8ced0  gnupg-w32-2.2.30_20210826.tar.xz
f576c2b194c609bfd0386569ef3b51dd2eb38a12  gnupg-w32-2.2.30_20210826.exe


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

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


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

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

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

or can be downloaded as PDF at

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

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

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

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

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


Thanks
======

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

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, or answering questions on the mailing
lists.

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


Happy hacking,

   Your GnuPG hackers


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

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

  ed25519 2020-08-24 [expires: 2030-06-30]
  Key fingerprint = 6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
  Werner Koch (dist signing 2020)

  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)

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

The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
Please read

  Nils Melzer: Der Fall Julian Assange

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

From jerry at seibercom.net  Fri Aug 27 15:12:58 2021
From: jerry at seibercom.net (Jerry Seibert)
Date: Fri, 27 Aug 2021 09:12:58 -0400
Subject: gpg-agent and X
In-Reply-To: <YSex5HvKeoUm13i6@ikki.ethgen.ch>
References: <YEH2+T/146OVr7w3@ikki.ethgen.ch> <YSex5HvKeoUm13i6@ikki.ethgen.ch>
Message-ID: <20210827091240.000019ac@seibercom.net>

On Thu, 26 Aug 2021 16:23:16 +0100, Klaus Ethgen stated:
>Unfortunately, the gtk3 version of pinentry has some toxic dependencies
>that I never want to have.

Would you be so kind as to list, and possibly explain, those toxic
dependencies?

-- 
Jerry


From stefan.vasilev at posteo.ru  Fri Aug 27 20:35:47 2021
From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=)
Date: Fri, 27 Aug 2021 18:35:47 +0000
Subject: [OT] Tutanota security/privacy concerns (was: Re: How would you
 do that ...)
In-Reply-To: <Mi6Hj8h--3-2@tuta.io>
References: <b1e841fe-2eb4-b8b7-6b1c-9e543e9322ed@posteo.ru>
 <MvmFiM3_W9gYjO_KLbs5S9_WW9pBnLwosdF6kbTR32NBlm1N9Of1K4qkIZBoEViACTDYaoJvlB05wx4U7ThrVWCPYJin677f1FwGHQb4BLM=@digicana.com>
 <b40d96a3-3edc-3c4b-7d46-3a18f9c0ed22@posteo.ru>
 <0C3CE731-E12F-42BE-9D52-DBCBBA6DDD6A@digicana.com>
 <e7225829-d8e8-c181-34d2-b5cd582543ad@posteo.ru> <M_9zJv7--3-2@tuta.io>
 <61c3f67a-6402-55fb-8366-a871ce729353@posteo.ru>
 <eb02a21a-8e03-57db-8678-16d94f2c7317@posteo.ru> <Mi6Hj8h--3-2@tuta.io>
Message-ID: <34a610ec6667c79251ba9df4acf4fab7@posteo.de>

l0f4r0 wrote:

> Hi Stefan, all,
> 
> Oops, I think I wanted to react sooner but didn't visibly...
> 
> 8 mai 2021, 15:12 de stefan.vasilev at posteo.ru:
> 
>>> l0f4r0 wrote:
>>> 
>>>> I don't use ProtonMail so I can't say.
>>>> 
>>>> But otherwise you have Tutanota (no phone number required):
>>>> https://tutanota.com/blog/posts/anonymous-email/
>>>> 
>> BTW. Tutanota does (full???) Browser fingerprinting and they where 
>> required
>> 
>> to 'upgrade' their email service.
>> 
> Thanks for the notice.
> 
> So are you implying Tutanota does not do browser fingerprinting 
> anymore?
> Actually, I cannot find any public source about this. Would you have
> some pointers to share please?

Hi,

I have not checked again, but can tell you from the past that they check
what web browser you are using, because when you use an anti-fingerprint
add on for your browser and it generates a User Agent string with an 
(old)
unsupported browser Tutanota complains and tells you to use the latest
Browser  x,y,z. If they do it any longer or if they do full 
fingerprinting I do
not know.

> 
> While we are at it, by any chance, do you/people have (other)
> complaints/concerns about Tutanota from a security or privacy points
> of view?

I guess Tutanota is a fine service, like many others, but I would like 
to
see Monero cryptocurrency support, when one likes to sign up via Tor.
(have not checked lately if this is already possible)

Regards
Stefan





From angel at pgp.16bits.net  Sat Aug 28 00:39:38 2021
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Sat, 28 Aug 2021 00:39:38 +0200
Subject: [OT] Tutanota security/privacy concerns (was: Re: How would you
 do that ...)
In-Reply-To: <34a610ec6667c79251ba9df4acf4fab7@posteo.de>
References: <b1e841fe-2eb4-b8b7-6b1c-9e543e9322ed@posteo.ru>
 <MvmFiM3_W9gYjO_KLbs5S9_WW9pBnLwosdF6kbTR32NBlm1N9Of1K4qkIZBoEViACTDYaoJvlB05wx4U7ThrVWCPYJin677f1FwGHQb4BLM=@digicana.com>
 <b40d96a3-3edc-3c4b-7d46-3a18f9c0ed22@posteo.ru>
 <0C3CE731-E12F-42BE-9D52-DBCBBA6DDD6A@digicana.com>
 <e7225829-d8e8-c181-34d2-b5cd582543ad@posteo.ru> <M_9zJv7--3-2@tuta.io>
 <61c3f67a-6402-55fb-8366-a871ce729353@posteo.ru>
 <eb02a21a-8e03-57db-8678-16d94f2c7317@posteo.ru> <Mi6Hj8h--3-2@tuta.io>
 <34a610ec6667c79251ba9df4acf4fab7@posteo.de>
Message-ID: <881372ca0ee4dab94347227f48b48538505e7ada.camel@16bits.net>

On 2021-08-27 at 18:35 +0000, ?????? ???????? via Gnupg-users wrote:
> Hi,
> 
> I have not checked again, but can tell you from the past that they
> check what web browser you are using, because when you use an anti-
> fingerprint add on for your browser and it generates a User Agent
> string with an (old) unsupported browser Tutanota complains and tells
> you to use the latest Browser  x,y,z. If they do it any longer or if
> they do full fingerprinting I do not know.

This is probably unrelated to fingerprinting the user. Most likely they
do that in order to check that the browser is able to use certain
features they use (rather than using feature detection instead).
Or maybe they do that just to force their clients not to use outdated
(and thus probably insecure) browsers.

In any case, using an User Agent which is not common (such as an old
browser, or a made-up one) will actually make you stand out, not
conceal you.


Regards




From klaus+gnupg at ethgen.ch  Sat Aug 28 09:46:41 2021
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Sat, 28 Aug 2021 08:46:41 +0100
Subject: gpg-agent and X
In-Reply-To: <20210827091240.000019ac@seibercom.net>
References: <YEH2+T/146OVr7w3@ikki.ethgen.ch> <YSex5HvKeoUm13i6@ikki.ethgen.ch>
 <20210827091240.000019ac@seibercom.net>
Message-ID: <YSnp4a60iJGrs1hf@ikki.ethgen.ch>

Am Fr den 27. Aug 2021 um 14:12 schrieb Jerry Seibert:
> On Thu, 26 Aug 2021 16:23:16 +0100, Klaus Ethgen stated:
> >Unfortunately, the gtk3 version of pinentry has some toxic dependencies
> >that I never want to have.
> 
> Would you be so kind as to list, and possibly explain, those toxic
> dependencies?

At least some time ago, there was a dependencie to the full gnome world
including gnome-keyring and systemd. I did not test it anymore since
then.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 688 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210828/ffbbb7d6/attachment.sig>

From klaus+gnupg at ethgen.ch  Sat Aug 28 09:54:07 2021
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Sat, 28 Aug 2021 08:54:07 +0100
Subject: gpg-agent and X
In-Reply-To: <20210827091240.000019ac@seibercom.net>
References: <YEH2+T/146OVr7w3@ikki.ethgen.ch> <YSex5HvKeoUm13i6@ikki.ethgen.ch>
 <20210827091240.000019ac@seibercom.net>
Message-ID: <YSnrnyojjVH3o1ik@ikki.ethgen.ch>

Am Fr den 27. Aug 2021 um 14:12 schrieb Jerry Seibert:
> On Thu, 26 Aug 2021 16:23:16 +0100, Klaus Ethgen stated:
> >Unfortunately, the gtk3 version of pinentry has some toxic dependencies
> >that I never want to have.
> 
> Would you be so kind as to list, and possibly explain, those toxic
> dependencies?

I just tested it right away, and there is no gtk3 build anymore in
pinentry, it is only the gnome3 pinentry that can be build. And at least
on gentoo, the pinentry-gnome3 is not working with X anymore.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 688 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210828/eb4d5ba3/attachment.sig>

From wk at gnupg.org  Sat Aug 28 18:56:10 2021
From: wk at gnupg.org (Werner Koch)
Date: Sat, 28 Aug 2021 18:56:10 +0200
Subject: gpg-agent and X
In-Reply-To: <YSex5HvKeoUm13i6@ikki.ethgen.ch> (Klaus Ethgen's message of
 "Thu, 26 Aug 2021 16:23:16 +0100")
References: <YEH2+T/146OVr7w3@ikki.ethgen.ch> <YSex5HvKeoUm13i6@ikki.ethgen.ch>
Message-ID: <87fsutv785.fsf@wheatstone.g10code.de>

On Thu, 26 Aug 2021 16:23, Klaus Ethgen said:

> It seems that I have the problem all time I use the QT pinentry. The
> gtk2 pinentry seems to be fine and with the switch to QT one, the

Did you tried pinentry 1.2.0 which we released last week?

FWIW, I am using xfce and had some problem with icons and thus also
pinentry in the past.  The solution was to set

QT_QPA_PLATFORMTHEME=qt5ct

in the environment and use one of the latest gnupg versons (2.2.30,
2.3.2).  But Pinentry 1.2.0 should also work if icons are not accessible
etc.


Shalom-Salam,

   Werner


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