Re: Looking for keyserver software without any validation or fancy features

[Andrew Gallagher via Gnupg-users]

(resending because the previous mail went out HTML-only, apologies)

Hi, Bernd.

> hagrid and huckeypuck are total overkill,

(Disclaimer: I’m one of the hockeypuck contributors)

If you have docker-compose installed, it’s *very* easy to spin up a test 
instance of hockeypuck, see the README at 
https://github.com/hockeypuck/hockeypuck

You will need a non-empty keydump to start with, but you can export a single 
key to a file with the suffix “.gpg” and it should suffice.

> and at least hagrid is not
> even /intended/ to be "self hosted".

I’m pretty sure you can self-host hagrid, although I haven’t tested it.

> I have seen https://github.com/SKS-Keyserver/sks-keyserver but still
> have to check it out if it really suites my needs.

SKS-keyserver is very similar to hockeypuck (hockeypuck was first developed as 
an SKS-keyserver replacement). It does have the ability for a quick-build that 
serves static files directly without ingesting them into a database in advance, 
however you will still probably have to build the ptree (at least in its 
default configuration). It also has an unofficial docker image at 
https://registry.hub.docker.com/r/zhusj/sks 
<https://registry.hub.docker.com/r/zhusj/sks#!>
> Are there any other options?

https://github.com/PennockTech/openpgpkey-control comes to mind.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Looking for keyserver software without any validation or fancy features

[Andrew Gallagher via Gnupg-users]

Hi, Bernd. hagrid and huckeypuck are total overkill,(Disclaimer: I’m one of the hockeypuck contributors)If you have docker-compose installed, it’s *very* easy to spin up a test instance of hockeypuck, see the README at https://github.com/hockeypuck/hockeypuckYou will need a non-empty keydump to start with, but you can export a single key to a file with the suffix “.gpg” and it should suffice. and at least hagrid is noteven /intended/ to be "self hosted".I’m pretty sure you can self-host hagrid, although I haven’t tested it.I have seen https://github.com/SKS-Keyserver/sks-keyserver but stillhave to check it out if it really suites my needs.SKS-keyserver is very similar to hockeypuck (hockeypuck was first developed as an SKS-keyserver replacement). It does have the ability for a quick-build that serves static files directly without ingesting them into a database in advance, however you will still probably have to build the ptree (at least in its default configuration). It also has an unofficial docker image at https://registry.hub.docker.com/r/zhusj/sksAre there any other options?https://github.com/PennockTech/openpgpkey-control comes to mind.A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Looking for keyserver software without any validation or fancy features

[Bernd Naumann]

On 07.07.23 12:21, Werner Koch wrote:

> https://www.gnupg.org/blog/20201018-gnupg-and-ldap.html

Thanks, I will have a look into it.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Looking for keyserver software without any validation or fancy features

[Werner Koch via Gnupg-users]

On Fri,  7 Jul 2023 10:59, Bernd Naumann said:
> For a test setup / proof of concent / lab, I'm looking for a pretty
> simple keyserver implementation.

Use an LDAP server; this is the most flexible and best supported way to
store keys.

https://www.gnupg.org/blog/20201018-gnupg-and-ldap.html

> `gpg-wks-server` has to send and receive verification mails, right?
> I would like to avoid having to configure a mail-server and mail-clients.

gpg-wks-server is about key enrollment via mail and web.  A simpler
setup is by using gpg-wks-client to create Web Key Directory locally and
then upload it.

  gpg --list-options show-only-fpr-mbox | gpg-wks-client --install-key

or if you already got an LDAP:

https://gnupg.com/kb/mirror-ldap-to-wkd.html


Salam-Shalom,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Looking for keyserver software without any validation or fancy features

[Bernd Naumann]

Hi *,

For a test setup / proof of concent / lab, I'm looking for a pretty
simple keyserver implementation.

I don't need any form of validation, web ui, etc.
At least I want to be able to disable send mail validation, federation,
web server, and what not.

I just want to be able to send and receive keys to/from a server.

All machines in this setup are running Debian 11 or 12.

hagrid and huckeypuck are total overkill, and at least hagrid is not
even /intended/ to be "self hosted".

I have seen https://github.com/SKS-Keyserver/sks-keyserver but still
have to check it out if it really suites my needs.

`gpg-wks-server` has to send and receive verification mails, right?
I would like to avoid having to configure a mail-server and mail-clients.

Are there any other options?
I would like to not take `cp` and `scp` as an option, I'm doing this
already...

Thanks.
Bernd

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: lost id on keyserver

[Raja Saha]

Hi,

I am using Debian 10. My key was verified... I think you are right. At
that time (~3yrs back) I more worried about spam from publishing it on
the keyserver.

I'm pretty sure that is what it is. I didn't verify my email. Since I
was using the same machine to know more about gpg, it wasn't a problem,
it was reading my keyring.

Thank you! I would have never figured it out.

Cheers!



On Thu, 2022-02-10 at 14:50 +, Andrew Gallagher via Gnupg-users
wrote:
> On 10/02/2022 13:23, Raja Saha wrote:
> > I created the subkey, output it to a file and imported it to gpg on
> > working dir. Then I sent the key to the keyserver, gpg --send-keys
> > *. After that when I searched the keyserver by my email it,
> > there
> > was no key. When I searched by my key
> > F01D54EDAEB1700EBEDE6FC6C0A9DE3BFEFD07E2 (now revoked) it was
> > there.
> > When I imported it, it didn't have a mail id.
> 
> What OS are you using? The default keyserver depends on your linux 
> distro, and the default in Debian-based distros (keys.openpgp.org) 
> doesn't serve userIDs by default. If you published your key there
> and 
> then imported it into a different keyring, it wouldn't have come
> with 
> the userID unless you went through their email verification procedure
> first.
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: lost id on keyserver

[Andrew Gallagher via Gnupg-users]

On 10/02/2022 13:23, Raja Saha wrote:


I created the subkey, output it to a file and imported it to gpg on
working dir. Then I sent the key to the keyserver, gpg --send-keys
*. After that when I searched the keyserver by my email it, there
was no key. When I searched by my key
F01D54EDAEB1700EBEDE6FC6C0A9DE3BFEFD07E2 (now revoked) it was there.
When I imported it, it didn't have a mail id.


What OS are you using? The default keyserver depends on your linux 
distro, and the default in Debian-based distros (keys.openpgp.org) 
doesn't serve userIDs by default. If you published your key there and 
then imported it into a different keyring, it wouldn't have come with 
the userID unless you went through their email verification procedure first.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

lost id on keyserver

[Raja Saha]

Hi,

I was following Debian Subkey guide to create and maintain keys/subkeys
https://wiki.debian.org/Subkeys

I had a functional key on the gpg (default) key server for this email
(r...@rsdisk.com). 

I renamed ~/.gnupg to ~/.gnupg_hot and created a blank ~/.gnupg. At
this point I didn't use the export command to set the dir, but instead
toggled the names of the ~/.gnupg dir to shift between the two dirs in
gpg.

I created the subkey, output it to a file and imported it to gpg on
working dir. Then I sent the key to the keyserver, gpg --send-keys
*. After that when I searched the keyserver by my email it, there
was no key. When I searched by my key
F01D54EDAEB1700EBEDE6FC6C0A9DE3BFEFD07E2 (now revoked) it was there.
When I imported it, it didn't have a mail id.

I'm not sure where I made the mistake. I have now made a new
key/subkey, published it.

I would like to know where I went wrong so I know, for in future.

Thanks!



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys retrieved from keyserver (keys.openpgp.org) are unusable

[Werner Koch via Gnupg-users]

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.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

SOLVED: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

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!

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Xi Ruoyao via Gnupg-users]

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

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Xi Ruoyao via Gnupg-users]

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 
School of Aerospace Science and Technology, Xidian University


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

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.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

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.
> 
Thanks. "gnutls-cli keys.openpgp.org" seems to work:

~> gnutls-cli keys.openpgp.org
Processed 145 CA certificate(s).
Resolving 'keys.openpgp.org:443'...
Connecting to '37.218.245.50:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
[...]
- Handshake was completed

- Simple Client Mode:

- Peer has closed the GnuTLS connection
~>

> 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.)
> 
p11-kit was built with
--with-trust-paths=/etc/pki/anchors 
which is in accordance with BLFS-10.1. But I suppose that is equivalent
to  -Dtrust_paths=/etc/pki/anchors ?

Anyway - I'll try "make-ca -f -g" and then re-build gnupg without
--with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt
and report back.

So long!





___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

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" }
> 
Thanks. None of those files is on my system. So it's probably no wonder
that "--search-keys" didn't work.

Either I messed up big or LFS/BLFS uses a setup for the certificates
that is not what gnupg expects. In the latter case
--with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt
may indeed be the way to go for LFS/BLFS systems.

I'll cc this to blfs-support so that the editors can draw their own
conclusions. Or castigate me for being too stupid to follow the
instructions somewhere. ;)

>> to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so
>> that dirmngr looks in the Mozilla certificate library.
> 
> Not a too good idea becuase these certificates are used for a different
> purpose.  
> 
> 
> FWIW, here is the list of internal certificate classes used:
> 
>   CERTTRUST_CLASS_SYSTEM  = 1, /* From the system's list of trusted certs. */
>   CERTTRUST_CLASS_CONFIG  = 2, /* From dirmngr's config files. */
>   CERTTRUST_CLASS_HKP = 4, /* From --hkp-cacert*/
>   CERTTRUST_CLASS_HKPSPOOL= 8, /* The one and only from sks-keyservers */
> 
> 
> Shalom-Salam,
> 
>Werner
> 
> 


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Werner Koch via Gnupg-users]

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" }

> to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so
> that dirmngr looks in the Mozilla certificate library.

Not a too good idea becuase these certificates are used for a different
purpose.  


FWIW, here is the list of internal certificate classes used:

  CERTTRUST_CLASS_SYSTEM  = 1, /* From the system's list of trusted certs. */
  CERTTRUST_CLASS_CONFIG  = 2, /* From dirmngr's config files. */
  CERTTRUST_CLASS_HKP = 4, /* From --hkp-cacert*/
  CERTTRUST_CLASS_HKPSPOOL= 8, /* The one and only from sks-keyservers */


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

Am 29.07.21 um 19:36 schrieb Andrew Gallagher:
> On 29/07/2021 17:52, Rainer Fiebig wrote:
>>
>> ~> openssl x509 -text > After"
>>  Not After : Sep 30 14:01:15 2021 GMT
> 
> So the file exists, and appears to have the correct contents (the
> difference in checksum is probably whitespace or commentary, I wouldn't
> worry about it).
> 
> I'm going to refer back to my earlier statement: "It looks like dirmngr
> isn't using the same set of CAs that curl is using".
> 
> If you built gnupg from its default configuration, it does not
> automatically look in /etc/ssl/certs for CA certificates. You may want
> to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so
> that dirmngr looks in the Mozilla certificate library.
> 
Perhaps solved. As the main issue here seemed to be that gnupg could not
find the certificate(s) and the symlink to /etc/ssl/certs (all .pem) did
not work, I re-built gnupg with this configure-switch:

--with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt


And now  --search-keys is working:

~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568
gpg: data source: https://keys.openpgp.org:443
(1) Łukasz Langa (GPG langa.pl) 
Łukasz Langa 
Łukasz Langa 
  4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
von Nummern, Nächste (N) oder Abbrechen (Q) >

~> gpg --keyserver hkps://keys.openpgp.org --search-keys
E3FF2839C048B25C084DEBE9B26995E310250568
gpg: data source: https://keys.openpgp.org:443
(1) Łukasz Langa (GPG langa.pl) 
Łukasz Langa 
Łukasz Langa 
  4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
von Nummern, Nächste (N) oder Abbrechen (Q) >

~> gpg --keyserver hkps://pgpkeys.eu --search-keys
E3FF2839C048B25C084DEBE9B26995E310250568
gpg: data source: https://pgpkeys.eu:443
(1) Łukasz Langa (GPG langa.pl) 
Łukasz Langa 
Łukasz Langa 
Łukasz Langa (Work e-mail account) 
  4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
von Nummern, Nächste (N) oder Abbrechen (Q) >



However, having to build gnupg with this switch feels somewhat akward,
like a workaround, not like it should be.

I'll post this solution over at blfs-supp...@lists.linuxfromscratch.org
and see what they think about it. Perhaps they have a more elegant
solution or can tell me whether I've made a configuration-mistake elsewhere.

Thank you guys for your time and suggestions. They helped a lot!



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

Am 29.07.21 um 19:36 schrieb Andrew Gallagher:
> On 29/07/2021 17:52, Rainer Fiebig wrote:
>>
>> ~> openssl x509 -text > After"
>>  Not After : Sep 30 14:01:15 2021 GMT
> 
> So the file exists, and appears to have the correct contents (the
> difference in checksum is probably whitespace or commentary, I wouldn't
> worry about it).
> 
> I'm going to refer back to my earlier statement: "It looks like dirmngr
> isn't using the same set of CAs that curl is using".
Yes, that seems to be at the heart of the matter. Curl is built with
this ./configure switch:
--with-ca-path=/etc/ssl/certs

and so it finds the correct certificate.

There's no such switch for gnupg. So I guess dirmngr looks in /etc/pki
for the certs? And maybe the DST_Root_CA_X3 (in "ca-bundle.crt) there is
different (outdated?) from the one in /etc/ssl/certs.

> 
> If you built gnupg from its default configuration, it does not
> automatically look in /etc/ssl/certs for CA certificates. You may want
> to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so
> that dirmngr looks in the Mozilla certificate library.
> 
The manpage for dirmngr says that the certificates in
/etc/gnupg/trusted-certs  are expected to be in .der or .crt  encoding.
Those in /etc/ssl are .pem, though.

I created a symlink /etc/gnupg/trusted-certs -> /etc/ssl/certs/ but gpg
--search-keys  still fails, probably due to the .pem encoding.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 29/07/2021 17:52, Rainer Fiebig wrote:


~> openssl x509 -text 

So the file exists, and appears to have the correct contents (the 
difference in checksum is probably whitespace or commentary, I wouldn't 
worry about it).


I'm going to refer back to my earlier statement: "It looks like dirmngr 
isn't using the same set of CAs that curl is using".


If you built gnupg from its default configuration, it does not 
automatically look in /etc/ssl/certs for CA certificates. You may want 
to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so 
that dirmngr looks in the Mozilla certificate library.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

Am 29.07.21 um 18:45 schrieb Andrew Gallagher:
> On 29/07/2021 17:33, Rainer Fiebig wrote:
>> Thanks. File exists but has a different checksum:
>>
>> /etc/ssl/certs> sha256sum DST_Root_CA_X3.pem
>> 4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980
>> DST_Root_CA_X3.pem
> 
> Ah, I wonder is the expiry date different. Can you incant the following
> please?
> 
> ```
> openssl x509 -text  ```
> 
> Mine says:
> 
> ```
> Not After : Sep 30 14:01:15 2021 GMT
> ```
> 

Same here:

~> openssl x509 -text http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 29/07/2021 17:33, Rainer Fiebig wrote:

Thanks. File exists but has a different checksum:

/etc/ssl/certs> sha256sum DST_Root_CA_X3.pem
4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980
DST_Root_CA_X3.pem


Ah, I wonder is the expiry date different. Can you incant the following 
please?


```
openssl x509 -text 

OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

Am 29.07.21 um 18:16 schrieb Andrew Gallagher:
> On 29/07/2021 08:41, Rainer Fiebig via Gnupg-users wrote:
>> Am 28.07.21 um 21:38 schrieb Ingo Klöcker:
>>> On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users 
> wrote:
>>>
>>> Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you?
>>>
>> No, same output as reported initially.
> 
> The common problem is the LetsEncrypt R3 certificate.
> 
>> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
>> * ALPN, server accepted to use http/1.1
>> * Server certificate:
>> *  subject: CN=keys.openpgp.org
>> *  start date: Jul 26 04:32:08 2021 GMT
>> *  expire date: Oct 24 04:32:06 2021 GMT
>> *  subjectAltName: host "keys.openpgp.org" matched cert's
>> "keys.openpgp.org"
>> *  issuer: C=US; O=Let's Encrypt; CN=R3
>> *  SSL certificate verify ok.
> ...
>> Looks OK to me. The Let's Encrypt certificate is recognized and
>> verified. Or what do you think?
> 
> I think it looks like dirmngr isn't using the same set of CAs that curl
> is using.
> 
> The missing root certificate is:
> 
>> 2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate: #/CN=DST Root 
> CA
>> X3,O=Digital Signature Trust Co.
> Can you confirm that /etc/ssl/certs/DST_Root_CA_X3.pem exists on your
> machine and has the following checksum?
> 
> ```
> andrewg@whippet:~$ sha256sum /etc/ssl/certs/DST_Root_CA_X3.pem
> 139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99
> /etc/ssl/certs/DST_Root_CA_X3.pem
> ```
> 
Thanks. File exists but has a different checksum:

/etc/ssl/certs> sha256sum DST_Root_CA_X3.pem
4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980
DST_Root_CA_X3.pem

> Also, is your system clock correct? (long shot, but always worth asking
> when debugging TLS cert issues)
> 
System clock is OK. No problem asking - I'm happy for every clue I can
get in this matter. ;)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 29/07/2021 08:41, Rainer Fiebig via Gnupg-users wrote:

Am 28.07.21 um 21:38 schrieb Ingo Klöcker:
On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users 

wrote:
>>

Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you?


No, same output as reported initially.


The common problem is the LetsEncrypt R3 certificate.


* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=keys.openpgp.org
*  start date: Jul 26 04:32:08 2021 GMT
*  expire date: Oct 24 04:32:06 2021 GMT
*  subjectAltName: host "keys.openpgp.org" matched cert's "keys.openpgp.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

...

Looks OK to me. The Let's Encrypt certificate is recognized and
verified. Or what do you think?


I think it looks like dirmngr isn't using the same set of CAs that curl 
is using.


The missing root certificate is:

2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate: #/CN=DST Root 

CA

X3,O=Digital Signature Trust Co.
Can you confirm that /etc/ssl/certs/DST_Root_CA_X3.pem exists on your 
machine and has the following checksum?


```
andrewg@whippet:~$ sha256sum /etc/ssl/certs/DST_Root_CA_X3.pem
139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99 
/etc/ssl/certs/DST_Root_CA_X3.pem

```

Also, is your system clock correct? (long shot, but always worth asking 
when debugging TLS cert issues)


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

Am 28.07.21 um 21:38 schrieb Ingo Klöcker:
> On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users wrote:
>> Am 28.07.21 um 17:42 schrieb Andrew Gallagher:
>>> On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote:
>>>> 2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
>>>> 'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der
>>>> Kette
>>>> 2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
>>>> Fehlendes Herausgeberzertifikat in der Kette
>>>> 2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6
>>>> beendet
>>>
>>> "Fehlendes Herausgeberzertifikat in der Kette" translates as "Missing
>>> publisher certificate in the chain", is that correct?
>>
>> Correct.
>>
>>> keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to
>>> other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses
>>> the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org.
>>
>> This works:
>>
>> ~> gpg --keyserver pgpkeys.eu --search-keys
>> E3FF2839C048B25C084DEBE9B26995E310250568
>> gpg: enabled debug flags: memstat
>> gpg: data source: http://pgpkeys.eu:11371
>> (1)  Łukasz Langa (GPG langa.pl) 
>>  Łukasz Langa 
>>  Łukasz Langa 
>>  Łukasz Langa (Work e-mail account) 
>>4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
>> Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
>> von Nummern, Nächste (N) oder Abbrechen (Q) >
> 
> Doesn't use TLS. Just plain HTTP.
> 
>> Each of these lines in dirmngr.conf also work:
>> keyserver http://keys2.andreas-puls.de/
>> keyserver http://pgpkeys.eu/
> 
> Ditto. Since your problems seem to be related to TLS it's not really 
> surprising that keyservers not using https work.
> 
At least I now know that such keyservers still exist. ;)

> Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you?
> 
No, same output as reported initially.

> What does 'curl -v https://keys.openpgp.org' say?
> 
~> curl --max-filesize 1 -v https://keys.openpgp.org
*   Trying 37.218.245.50:443...
* Connected to keys.openpgp.org (37.218.245.50) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: none
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=keys.openpgp.org
*  start date: Jul 26 04:32:08 2021 GMT
*  expire date: Oct 24 04:32:06 2021 GMT
*  subjectAltName: host "keys.openpgp.org" matched cert's "keys.openpgp.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: keys.openpgp.org
> User-Agent: curl/7.77.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.14.2
< Date: Thu, 29 Jul 2021 07:20:26 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 1761
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Referrer-Policy: no-referrer-when-downgrade
< Content-Security-Policy: default-src 'none'; script-src 'self';
img-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self';
frame-ancestors 'none'; base-uri 'none'; form-action 'self'; report-uri
https://keysopenpgporg.report-uri.com/r/d/csp/enforce
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Expect-CT: max-age=31536000,
report-uri="https://keysopenpgporg.report-uri.com/r/d/ct/reportOnly;
< alt-svc:
h2="zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion:443";
ma=86400; persist=1
<

[..]

Looks OK to me. The Let's Encrypt certificate is recognized and
verified. Or what do you think?

> Regards,
> Ingo
> 
Thanks for your help!

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Ingo Klöcker]

On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users wrote:
> Am 28.07.21 um 17:42 schrieb Andrew Gallagher:
> > On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote:
> >> 2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
> >> 'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der
> >> Kette
> >> 2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
> >> Fehlendes Herausgeberzertifikat in der Kette
> >> 2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6
> >> beendet
> > 
> > "Fehlendes Herausgeberzertifikat in der Kette" translates as "Missing
> > publisher certificate in the chain", is that correct?
> 
> Correct.
> 
> > keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to
> > other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses
> > the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org.
> 
> This works:
> 
> ~> gpg --keyserver pgpkeys.eu --search-keys
> E3FF2839C048B25C084DEBE9B26995E310250568
> gpg: enabled debug flags: memstat
> gpg: data source: http://pgpkeys.eu:11371
> (1)   Łukasz Langa (GPG langa.pl) 
>   Łukasz Langa 
>   Łukasz Langa 
>   Łukasz Langa (Work e-mail account) 
> 4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
> Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
> von Nummern, Nächste (N) oder Abbrechen (Q) >

Doesn't use TLS. Just plain HTTP.

> Each of these lines in dirmngr.conf also work:
> keyserver http://keys2.andreas-puls.de/
> keyserver http://pgpkeys.eu/

Ditto. Since your problems seem to be related to TLS it's not really 
surprising that keyservers not using https work.

Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you?

What does 'curl -v https://keys.openpgp.org' say?

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

Am 28.07.21 um 17:42 schrieb Andrew Gallagher:
> On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote:
>> 2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
>> 'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der
>> Kette
>> 2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
>> Fehlendes Herausgeberzertifikat in der Kette
>> 2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6
>> beendet
> 
> "Fehlendes Herausgeberzertifikat in der Kette" translates as "Missing
> publisher certificate in the chain", is that correct?
> 
Correct.

> keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to
> other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses
> the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org.
> 
This works:

~> gpg --keyserver pgpkeys.eu --search-keys
E3FF2839C048B25C084DEBE9B26995E310250568
gpg: enabled debug flags: memstat
gpg: data source: http://pgpkeys.eu:11371
(1) Łukasz Langa (GPG langa.pl) 
Łukasz Langa 
Łukasz Langa 
Łukasz Langa (Work e-mail account) 
  4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
von Nummern, Nächste (N) oder Abbrechen (Q) >


Each of these lines in dirmngr.conf also work:
keyserver http://keys2.andreas-puls.de/
keyserver http://pgpkeys.eu/

~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568
gpg: enabled debug flags: memstat
gpg: data source: http://keys2.andreas-puls.de:80
(1) Łukasz Langa (GPG langa.pl) 
Łukasz Langa 
Łukasz Langa 
Łukasz Langa (Work e-mail account) 
  4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
von Nummern, Nächste (N) oder Abbrechen (Q) >

> What OS are you using? Do you have the latest version of ca-certificates
> (or equivalent) installed?
> 
Linux From Scratch, latest stable. The ca-certificates (from
Mozilla.org) are updated regularly (automated).



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote:

2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6 beendet


"Fehlendes Herausgeberzertifikat in der Kette" translates as "Missing 
publisher certificate in the chain", is that correct?


keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to 
other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses 
the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org.


What OS are you using? Do you have the latest version of ca-certificates 
(or equivalent) installed?


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Rainer Fiebig via Gnupg-users]

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
> 
> note that this particular keyserver has decided to be incompatible with 
> the current OpenPGP standard, by ommitting a valid user id, unless
> it was "validated".
> (It says so it in its FAQ and there is port of a discussion here
> https://dev.gnupg.org/T4393#133695)
> This could potentially cause problems.
> 
>> However, this (and only this) works:
>>
>> ~> gpg --keyserver keyserver.ubuntu.com --search-keys
>> E3FF2839C048B25C084DEBE9B26995E310250568
> 
> Have you tried some other keyservers like http://keys2.andreas-puls.de/ ?
> Or you can set some dirmngr options to get more diagnostic output
> in its logfile. (See dirmngr's documentation.)
> 
> Regards,
> Bernhard
> 
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
Thanks for your quick reply. Set dirmngr to "verbose". The output points
to a certificate-issue (again my apologies to non German-speaking members):

~> cat dirmngr.log
2021-07-28 16:06:49 dirmngr[4134] Es wird auf Socket
`/run/user/1000/gnupg/S.dirmngr' gehört
2021-07-28 16:06:49 dirmngr[4135.0]dauerhaft geladene Zertifikate: 0
2021-07-28 16:06:49 dirmngr[4135.0]  zwischengespeicherte Zertifikate: 0
2021-07-28 16:06:49 dirmngr[4135.0] vertrauenswürdige Zertifikate: 0
(0,0,0,0)
2021-07-28 16:06:49 dirmngr[4135.6] Handhabungsroutine für fd 6 gestartet
2021-07-28 16:06:49 dirmngr[4135.6] connection from process 4132 (1000:1000)
2021-07-28 16:06:50 dirmngr[4135.6] resolve_dns_addr for
'keys.openpgp.org': 'keys.openpgp.org' [already known]
2021-07-28 16:06:50 dirmngr[4135.6] resolve_dns_addr for
'keys.openpgp.org': 'keys.openpgp.org' [already known]
2021-07-28 16:06:50 dirmngr[4135.6] detected interfaces: IPv4 IPv6
2021-07-28 16:06:50 dirmngr[4135.6] Zertifikat wurde zwischengespeichert
2021-07-28 16:06:50 dirmngr[4135.6] Zertifikat wurde zwischengespeichert
2021-07-28 16:06:50 dirmngr[4135.6] Hinweis: Die unkritische
Zertifikatsrichtlinie ist nicht erlaubt
2021-07-28 16:06:50 dirmngr[4135.6] Das Zertifikat ist korrekt
2021-07-28 16:06:50 dirmngr[4135.6] Hinweis: Die unkritische
Zertifikatsrichtlinie ist nicht erlaubt
2021-07-28 16:06:50 dirmngr[4135.6] Das Zertifikat ist korrekt
2021-07-28 16:06:50 dirmngr[4135.6] Hinweis: Die unkritische
Zertifikatsrichtlinie ist nicht erlaubt
2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Holen des Zertifikats
mittels Subject: Konfigurationsfehler
2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate
{C4A7B1A47B2C71FADBE14B9075FFC41560858910} not found using
authorityKeyIdentifier
2021-07-28 16:06:50 dirmngr[4135.6] Herausgeberzertifikat nicht gefunden
2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate: #/CN=DST Root CA
X3,O=Digital Signature Trust Co.
2021-07-28 16:06:50 dirmngr[4135.6] TLS handshake failed: Fehlendes
Herausgeberzertifikat in der Kette 
2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6 beendet
~>

Have to admit that I'm a bit clueless here.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[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

note that this particular keyserver has decided to be incompatible with 
the current OpenPGP standard, by ommitting a valid user id, unless
it was "validated".
(It says so it in its FAQ and there is port of a discussion here
https://dev.gnupg.org/T4393#133695)
This could potentially cause problems.

> However, this (and only this) works:
>
> ~> gpg --keyserver keyserver.ubuntu.com --search-keys
> E3FF2839C048B25C084DEBE9B26995E310250568

Have you tried some other keyservers like http://keys2.andreas-puls.de/ ?
Or you can set some dirmngr options to get more diagnostic output
in its logfile. (See dirmngr's documentation.)

Regards,
Bernhard


-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

--search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[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

gnupg version is 2.2.29 but I also see this with 2.2.27.

Locale is German but "Kein "Inquire" "Callback" für IPC gesetzt" should
be equivalent to "No inquire callback in IPC". Sorry.


~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568
gpg: enabled debug flags: memstat
gpg: error searching keyserver: Kein "Inquire" "Callback" für IPC gesetzt
gpg: Suche auf dem Schlüsselserver fehlgeschlagen: Kein "Inquire"
"Callback" für IPC gesetzt
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:build=0 update=0 insert=0 delete=0
gpg:reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
  outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
~>


However, this (and only this) works:

~> gpg --keyserver keyserver.ubuntu.com --search-keys
E3FF2839C048B25C084DEBE9B26995E310250568
gpg: enabled debug flags: memstat
gpg: data source: http://162.213.33.8:11371
(1) Łukasz Langa (GPG langa.pl) 
Łukasz Langa 
Łukasz Langa 
Łukasz Langa (Work e-mail account) 
  4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568".  Eingabe
von Nummern, Nächste (N) oder Abbrechen (Q)
[...]


Any ideas? Thanks.

Rainer Fiebig

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys retrieved from keyserver (keys.openpgp.org) are unusable

[root]

On Tue, Jul 27, 2021 at 02:34:28PM +0200, Ingo Klöcker wrote:
> On Dienstag, 27. Juli 2021 01:32:53 CEST root wrote:
> > Long story short, when the public key is downloaded to my PC as a plain text
> > .asc file, and later imported using the function
> > gpgme_op_keylist_from_data_start() and gpgme_op_keylist_new(), the
> > key->can_encrypt, key->sign_certify, and can_sign are all 0x01.
> 
> gpgme_op_keylist_from_data_start() does _not_ import any keys. All it does is 
> retrieve the meta data of the keys passed to it as data. Those keys cannot be 
> used for any crypto operations like signing, encrypting, etc. because the 
> public key data has _not_ been imported. The keys have just been listed. This 
> is very similar to listing the keys on a keyserver without actually 
> retrieving 
> the public keys from the keyserver.
> 
> > Alternatively, if I do gpgme_op_keylist_start() using an email address with
> > GPGME_KEYLIST_MODE_EXTERN, the key->can_encrypt, key->can_certify and
> > key->can_sign are all 0x00. I've tried several email addresses found on
> > keys.opengpg.org, and the result is the same.
> 
> Using gpgme_op_keylist_start() with GPGME_KEYLIST_MODE_EXTERN does a remote 
> lookup on the keyserver. It does _not_ import the found keys. That's why 
> can_encrypt, etc. are all 0x00. You need to download and import the keys if 
> you want to use them.
> 
This makes sense now. I will look into the sample codes and manual to see how
I can download and import the keys after listing it. Any suggestion on where to
look for them ? Hopefully, it'll be straight forward.
> Alternatively, you may want to use the auto-key-locate option of gpg which 
> automatically locates and retrieves keys when encrypting to an email address.
The codes that I am developing is actually a DLL used by another C#/C++ written
in .Net framwork. Thus, the binary developed has to be portable. I will look 
into the auto-key-locate option for sure. 
> 
> Don't reinvent the wheel using gpgme if you can simply use what gpg provides 
> out of the box. Of course, you can still use gpgme for doing the encryption, 
> but don't try to retrieve the keys yourself if gpg can do it for you.
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 ? 

Thanks again,
Eric
> 
> Regards,
> Ingo



> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys retrieved from keyserver (keys.openpgp.org) are unusable

[Ingo Klöcker]

On Dienstag, 27. Juli 2021 01:32:53 CEST root wrote:
> Long story short, when the public key is downloaded to my PC as a plain text
> .asc file, and later imported using the function
> gpgme_op_keylist_from_data_start() and gpgme_op_keylist_new(), the
> key->can_encrypt, key->sign_certify, and can_sign are all 0x01.

gpgme_op_keylist_from_data_start() does _not_ import any keys. All it does is 
retrieve the meta data of the keys passed to it as data. Those keys cannot be 
used for any crypto operations like signing, encrypting, etc. because the 
public key data has _not_ been imported. The keys have just been listed. This 
is very similar to listing the keys on a keyserver without actually retrieving 
the public keys from the keyserver.

> Alternatively, if I do gpgme_op_keylist_start() using an email address with
> GPGME_KEYLIST_MODE_EXTERN, the key->can_encrypt, key->can_certify and
> key->can_sign are all 0x00. I've tried several email addresses found on
> keys.opengpg.org, and the result is the same.

Using gpgme_op_keylist_start() with GPGME_KEYLIST_MODE_EXTERN does a remote 
lookup on the keyserver. It does _not_ import the found keys. That's why 
can_encrypt, etc. are all 0x00. You need to download and import the keys if 
you want to use them.

Alternatively, you may want to use the auto-key-locate option of gpg which 
automatically locates and retrieves keys when encrypting to an email address.

Don't reinvent the wheel using gpgme if you can simply use what gpg provides 
out of the box. Of course, you can still use gpgme for doing the encryption, 
but don't try to retrieve the keys yourself if gpg can do it for you.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

keys retrieved from keyserver (keys.openpgp.org) are unusable

[root]

Hi, all

I've posted this question on stackoverflow.com a few days ago, and I am still 
waiting for someone to comment. 

https://stackoverflow.com/questions/68490051/key-retrieved-from-keyserver-keys-openpgp-org-cant-be-used-gpgme

Long story short, when the public key is downloaded to my PC as a plain text 
.asc file, and later imported using the
function gpgme_op_keylist_from_data_start() and gpgme_op_keylist_new(), the 
key->can_encrypt, key->sign_certify,
and can_sign are all 0x01. 

Alternatively, if I do gpgme_op_keylist_start() using an email address with 
GPGME_KEYLIST_MODE_EXTERN, the key->can_encrypt,
key->can_certify and key->can_sign are all 0x00. I've tried several email 
addresses found on keys.opengpg.org, and the
result is the same. 

Either way, I can't use this key to even encrypt data. For the key downloaded 
as a .asc file, if I manually 
"certify" the key first using Kleopatra prior to 
gpgme_op_keylist_from_data_start(), it then can be used to encrypt the
data. But my purpose is to use the public key downloaded remotely with 
GPGME_KEYLIST_MODE_EXTERN only, and without 
Kleopatra of course. 

The trust-model has been set to "ALWAYS", or "always" using 
gpgme_set_ctx_flag(). The crypto protocol used is OpenPGP. 

I can't find good hints using the sample codes in 
https://github.com/gpg/gpgme.git either.

Any comment/suggestion is welcome. 

Eric

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Malte Gell via Gnupg-users]

Am 25.06.21 um 00:14 schrieb Brandon Anderson via Gnupg-users:
> 
>> The keyserver situation seems a bit difficult currently, maybe
>> https://keys.openpgp.org/ is the best (easiest) workaround for now.
>>
>> But WKD is really worth looking at!
>>
> 
> My understanding is the Ubuntu Key-server is staying up, I could be
> wrong, but https://keyserver.ubuntu.com/ seems to be functioning. It is
> worth noting that the keys.openpgp.org keyserver is not web of trust but
> explicitly trusting that keyserver to validate a person's identity.

I think it´s good to distribute a key thru several channels,
keys.openpgp.org is a good way to establish some trust in a key when
fetching it for the first time. Afterwards you can still get the same
key from a different source with WoT signatures added.

If you have no fountain at all for a key to establish a chain(web) of
trust, keys.openpgp.org is the only way to have some trust in a key. The
WoT works only if you have some fountain for the trust.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Andrew Gallagher via Gnupg-users]

On 24/06/2021 22:39, Brandon Anderson via Gnupg-users wrote:



$ host pool.sks-keyservers.net <http://pool.sks-keyservers.net>

Host pool.sks-keyservers.net <http://pool.sks-keyservers.net> not 
found: 3(NXDOMAIN)


Did these names get permanently deleted? Any workarounds or 
suggestions would be appreciated.


Hey Alex,

From what I can tell a lot of the keyservers are being shutdown. Take a 


look at the message on the SKS site (the SSL cert is expired) 
https://sks-keyservers.net/.


The keyserver *pools* at sks-keyservers.net are no longer maintained for 
legal reasons. sks-keyservers.net was receiving GDPR requests, e.g. for 
RTBF, that it could not satisfy because the pools had no formal 
structure that could compel individual operators to comply with legal 
requests. While sks-keyservers.net did not host personal data, it was 
providing a DNS round-robin service for keyservers that did, and the 
distinction was poorly understood.


Most of the individual keyservers that used to be in the pools are still 
working, however. There is a service at https://sks-status.gwolf.org/ 
that monitors the known keyservers. Scroll to the bottom and click on 
the latest "Success" link to see a graph of keyservers that are 
currently responsive.


What to do next depends on your use case. If your CI is searching for a 
key that is under your own control, then you have more freedom of 
choice. If it is searching for someone else's key then you may need to 
use whatever keyserver they use.


keys.openpgp.org is the default keyserver for most new installs, and 
many long-time users have also switched to it. If you don't have a 
particular reason to choose one, this is probably the safest bet. The 
main caveat is that it does not serve third-party sigs, and so you won't 
be able to verify a downloaded key by its signatures.


keyserver.ubuntu.com is reliable, but is not widely used outside the 
Ubuntu developer community. It doesn't get key updates particularly 
often, so you may find yourself with a stale copy of your 
correspondent's key.


If you need continuity of dataset with the sks-keyservers pool, then you 
may prefer to use a Hockeypuck server that was formerly part of the 
pool, such as pgpkeys.eu, keyserver.trifence.ch or keys.andreas-puls.de 
(other keyservers are available, see https://sks-status.gwolf.org/). 
Note that Hockeypuck is generally more reliable than SKS due to 
limitations in SKS's design.


Due to the fragmented nature of the keyserver ecosystem at the moment, 
you may want to try all of the above. And as mentioned in an earlier 
reply, you should probably also search WKD.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Brandon Anderson via Gnupg-users]

The keyserver situation seems a bit difficult currently, maybe
https://keys.openpgp.org/ is the best (easiest) workaround for now.

But WKD is really worth looking at!



My understanding is the Ubuntu Key-server is staying up, I could be 
wrong, but https://keyserver.ubuntu.com/ seems to be functioning. It is 
worth noting that the keys.openpgp.org keyserver is not web of trust but 
explicitly trusting that keyserver to validate a person's identity.




OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[mailinglisten--- via Gnupg-users]

Am 24.06.21 um 19:19 schrieb Alexander Polcyn via Gnupg-users:
> ()
> Host ipv4.pool.sks-keyservers.net <http://ipv4.pool.sks-keyservers.net>
> not found: 3(NXDOMAIN)
> ()
> Did these names get permanently deleted? Any workarounds or suggestions
> would be appreciated.

One alternative could be https://keys.openpgp.org/

This keyserver has one big advantage, when you upload a key there, this
server verifies the email address associated with that key is valid and
you have actual access to this email address. Fake keys have no chance
there.

Now, it also has one big disadvantage, this keyserver strips *all*
signatures associated to that key. All signatures will bw removed when
you upload a key there.

And GnuPG seems to have issues to fetch keys from there directly, using
e.g. gpg --recv-keys, it may be better to use wget to fetch keys from there.

If you have control over your own domain you may learn how to use WKD
web key directory, this way your key(s) is stored on your very own host.

The keyserver situation seems a bit difficult currently, maybe
https://keys.openpgp.org/ is the best (easiest) workaround for now.

But WKD is really worth looking at!



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Brandon Anderson via Gnupg-users]

Starting on the morning of June 21 between ~6am and 9am PDT, one of 
our CI jobs which fetches gpg keys with:


gpg --keyserver hkp://pool.sks-keyservers.net 
<http://pool.sks-keyservers.net> --recv-keys ...
 started failing because of what looks like a failure to resolve 
the pool name.


FWIW the following also fails in the same way:

gpg --keyserver hkp://ipv4.pool.sks-keyservers.net 
<http://ipv4.pool.sks-keyservers.net> --recv-keys ...


And testing from my machine, it looks like these names now get 
NXDOMAIN when attempting to resolve in DNS:


$ host ipv4.pool.sks-keyservers.net <http://ipv4.pool.sks-keyservers.net>

Host ipv4.pool.sks-keyservers.net 
<http://ipv4.pool.sks-keyservers.net> not found: 3(NXDOMAIN)



$ host pool.sks-keyservers.net <http://pool.sks-keyservers.net>

Host pool.sks-keyservers.net <http://pool.sks-keyservers.net> not 
found: 3(NXDOMAIN)





Did these names get permanently deleted? Any workarounds or 
suggestions would be appreciated.





Hey Alex,

From what I can tell a lot of the keyservers are being shutdown. Take a 
look at the message on the SKS site (the SSL cert is expired) 
https://sks-keyservers.net/.


You can read about some of whats going on from here 
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f.


Sincerely,

Brandon Anderson



OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Alexander Polcyn via Gnupg-users]

Starting on the morning of June 21 between ~6am and 9am PDT, one of our CI
jobs which fetches gpg keys with:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys ...

 started failing because of what looks like a failure to resolve the
pool name.

FWIW the following also fails in the same way:

gpg --keyserver hkp://ipv4.pool.sks-keyservers.net --recv-keys ...

And testing from my machine, it looks like these names now get NXDOMAIN
when attempting to resolve in DNS:

$ host ipv4.pool.sks-keyservers.net

Host ipv4.pool.sks-keyservers.net not found: 3(NXDOMAIN)


$ host pool.sks-keyservers.net

Host pool.sks-keyservers.net not found: 3(NXDOMAIN)




Did these names get permanently deleted? Any workarounds or suggestions
would be appreciated.


thanks,

Alex
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: error searching keyserver: Network is unreachable

[Christian Ribeaud]

Hi,

Thanks to all for the great support and the warm feedbacks, I learned a lot.

Finally, after a long search and research, I was able to solve the problem by 
putting 'standard-resolver' in a '~/.gnupg/dirmngr.conf' file.
I could not explain to you why though... __

Wishing you a great Sunday.
Best regards,

christian 

On 07.03.21, 11:12, "Andrew Gallagher via Gnupg-users"  
wrote:


Hi, Christian
 >
 > And, actually, we deployed our own (hkp://keyserver.dcc.sib.swiss:80) 
keyserver, which I am trying to access. But can't for some reason I do 
not understand.

I can connect to that server from here, but it appear to contain only 85 
keys. Did you import a dump, or is it meant to be internal-only?

> Desperately searching for hours now… I am NOT able to run following
> command:
 >
> gpg --keyserver hkp://keyserver.dcc.sib.swiss:80 --keyserver-options 
no-self-sigs-only,no-import-clean --search-keys  
 >
> Always getting following output: 
 >
> gpg: error searching keyserver: No keyserver available > gpg: keyserver 
search failed: No keyserver available

In the title of this thread however, you report "Network is 
unreachable". Are you getting both errors? "Network unreachable" is 
usually a network routing issue.

What happens if you run the following in your terminal?

 host keyserver.dcc.sib.swiss
 ping keyserver.dcc.sib.swiss
 host keys.openpgp.org
 ping keys.openpgp.org

> Changing keyserver does not help. I've tried 
> /ipv4.pool.sks-keyservers.net/ as well. Because the command takes
> some time to return, I would assume that it is still trying to do
> something. What could be the reason? How to fix it?
The pool algorithm doesn't include a test for server capacity, so it is 
common to get directed to a node running a single-threaded SKS instance, 
which can lead to long timeouts. Try testing against pgpkeys.uk, 
pgpkeys.eu and keyserver.trifence.ch instead. If it times out on all of 
those, then I would suspect a network issue, either a bad routing table 
or a firewall DROP rule.

> I am using v2.2.27, installed via Homebrew 
> (https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gnupg.rb) on
> Mac OS X Big Sur.
Did you ever install from gpgtools.org or only homebrew?

Andrew

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: error searching keyserver: Network is unreachable

[Klaus Ethgen]

Hi Christian,

Am Sa den  6. Mär 2021 um  8:44 schrieb Christian Ribeaud:
> Desperately searching for hours now???
> I am NOT able to run following command:
> 
> gpg --keyserver hkp://keyserver.dcc.sib.swiss:80 --keyserver-options 
> no-self-sigs-only,no-import-clean --search-keys 
> 
> Always getting following output:
> 
> gpg: error searching keyserver: No keyserver available
> gpg: keyserver search failed: No keyserver available

Remember, dirmng is using tor by default if it is installed and running!

You have to put no-use-tor to your .gnupg/dirmngr.conf to prevent this.

This did cost me hours to find out, when the feature was implemented.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: error searching keyserver: Network is unreachable

[Andrew Gallagher via Gnupg-users]

Hi, Christian
>
> And, actually, we deployed our own (hkp://keyserver.dcc.sib.swiss:80) 
keyserver, which I am trying to access. But can't for some reason I do 
not understand.


I can connect to that server from here, but it appear to contain only 85 
keys. Did you import a dump, or is it meant to be internal-only?



Desperately searching for hours now… I am NOT able to run following
command:

>
gpg --keyserver hkp://keyserver.dcc.sib.swiss:80 --keyserver-options no-self-sigs-only,no-import-clean --search-keys  

>
Always getting following output: 

>

gpg: error searching keyserver: No keyserver available > gpg: keyserver search 
failed: No keyserver available


In the title of this thread however, you report "Network is 
unreachable". Are you getting both errors? "Network unreachable" is 
usually a network routing issue.


What happens if you run the following in your terminal?

host keyserver.dcc.sib.swiss
ping keyserver.dcc.sib.swiss
host keys.openpgp.org
ping keys.openpgp.org

Changing keyserver does not help. I've tried 
/ipv4.pool.sks-keyservers.net/ as well. Because the command takes

some time to return, I would assume that it is still trying to do
something. What could be the reason? How to fix it?
The pool algorithm doesn't include a test for server capacity, so it is 
common to get directed to a node running a single-threaded SKS instance, 
which can lead to long timeouts. Try testing against pgpkeys.uk, 
pgpkeys.eu and keyserver.trifence.ch instead. If it times out on all of 
those, then I would suspect a network issue, either a bad routing table 
or a firewall DROP rule.


I am using v2.2.27, installed via Homebrew 
(https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gnupg.rb) on

Mac OS X Big Sur.

Did you ever install from gpgtools.org or only homebrew?

Andrew

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: error searching keyserver: Network is unreachable

[Christian Ribeaud]

Stefan,

Thanks for your answer.

Up to you, which one should I take for testing? There is a lot of red here…
And, actually, we deployed our own (hkp://keyserver.dcc.sib.swiss:80) 
keyserver, which I am trying to access. But can't for some reason I do not 
understand.
This instance is working properly. This is for sure. The problem is only on my 
side and my gpg installation.
Best,

christian

From: Stefan Claas 
Date: Saturday, 6 March 2021 at 15:18
To: Christian Ribeaud , "gnupg-users@gnupg.org" 

Subject: Re: gpg: error searching keyserver: Network is unreachable


Christian Ribeaud wrote:

> Good morning, > > > > Desperately searching for hours now… > > I am NOT able 
> to run following command: > > > > gpg --keyserver 
> hkp://keyserver.dcc.sib.swiss:80 --keyserver-options > 
> no-self-sigs-only,no-import-clean --search-keys  > > > > Always 
> getting following output: > > > > gpg: error searching keyserver: No 
> keyserver available > > gpg: keyserver search failed: No keyserver available 
> > > > > Changing keyserver does not help. I've tried > 
> /ipv4.pool.sks-keyservers.net/ as well. > > Because the command takes some 
> time to return, I would assume that it > is still trying to do something. > > 
> > > What could be the reason? How to fix it? > > I am using v2.2.27, 
> installed via Homebrew > 
> (https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gnupg.rb) > on 
> Mac OS X Big Sur. > > Any help greatly appreciated here. Thanks a lot, and 
> have a beautiful > day, >
Hello,


you may check out the current status of the SKS Network and try to select

a different server.


https://sks-keyservers.net/status/


Regards

Stefan
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg: error searching keyserver: Network is unreachable

[Christian Ribeaud]

Good morning,

Desperately searching for hours now…
I am NOT able to run following command:

gpg --keyserver hkp://keyserver.dcc.sib.swiss:80 --keyserver-options 
no-self-sigs-only,no-import-clean --search-keys 

Always getting following output:

gpg: error searching keyserver: No keyserver available
gpg: keyserver search failed: No keyserver available

Changing keyserver does not help. I've tried ipv4.pool.sks-keyservers.net as 
well.
Because the command takes some time to return, I would assume that it is still 
trying to do something.

What could be the reason? How to fix it?
I am using v2.2.27, installed via Homebrew 
(https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gnupg.rb) on Mac 
OS X Big Sur.
Any help greatly appreciated here. Thanks a lot, and have a beautiful day,

christian
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Keyserver] Hockeypuck 2.1.0 released

[Stefan Claas via Gnupg-users]

On Mon, Dec 14, 2020 at 5:24 PM Casey Marshall via Gnupg-users
 wrote:
>> [...]

> The fix to this issue was to have Hockeypuck remove all packets lacking a 
> currently-valid self-signature from responses. This removes fake packets 
> (like the uat example) as well as expired identities. The self-signature on 
> the UID packet in your example expired 2008-12-31, so it (and all of its 
> third-party signatures) are pruned from the response. Only the public key 
> packet remains.

Thanks for the information, much appreciated!

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Keyserver] Hockeypuck 2.1.0 released

[Casey Marshall via Gnupg-users]

>
> Date: Fri, 11 Dec 2020 17:56:24 +
> From: Stefan Claas 
> To: Casey Marshall via Gnupg-users ,
> sks-de...@nongnu.org, Casey Marshall 
> Subject: Re: [Keyserver] Hockeypuck 2.1.0 released
> Message-ID:
> <
> cac6fiz6epr-eud0azmcvz7m4c9hxga1isfg7jsc2hxwsovf...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> On Fri, Dec 11, 2020 at 10:25 AM Werner Koch  wrote:
> >
> > On Thu, 10 Dec 2020 11:07, Casey Marshall said:
> >
> > >- Authenticated key management. This adds a couple of extra
> endpoints
> > >which allow a key owner to replace and delete their key,
> authenticated by
> > >signing the armored key in the request. This allows a key owner to
> still
> > >update their own key once it has been inflated beyond the key
> >
> > Finally after more than 20 years waiting for someone to implement such a
> > feature.  Yeah.  Where can I find the specs?
> >
> > Did you consider that an authenticated request to delete a key may not
> > actually remove the key from the keyserver?  Instead the the primary key
> > should be kept and the server prepared to receive and merge even
> > unauthenticated revocation certificates.  This is important in case of a
> > lost key (or passphrase forgotten) so that a pre-created revocation
> > certificate can be uploaded.  Also avoids DoS after a key compromise.
> Hi Werner and Casey,
> I have a question for both of you.
> When I reported a while ago on GitHub about a fake uat packet on Werner's
> key you quickly fixed the issue and the added image of 'Donnie' no longer
> showed up at the Ubuntu keyserver. Interestingly now GitHub shows zero
> issues as of today, while yesterday still some issues where open and a lot
> of them closed.
>

Hockeypuck has several issues still open on Github:
https://github.com/hockeypuck/hockeypuck/issues


> Now my second question how is/was this done with Werner's key?
> SKS still shows Werner's key with signatures, while the Ubuntu keyserver
> shows only a very small key now. Before that the Ubuntu key server showed
> the sigs too and additionally the fake uat packet (Donnie image).
> Does this mean that a GnuPG user can modify his key in such a way
> and re-submit it, so that the result is now like Werner's key or can a
> Hockerpuck operator do this (on behalf) of the key owner? The key
> in question, on the Ubuntu keyserver has also no longer a UID, which
> I thought only sequoia-pgp can handle and not GnuPG.
>
> https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630=on=vindex
>
> http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630=on=vindex


The fix to this issue was to have Hockeypuck remove all packets lacking a
currently-valid self-signature from responses. This removes fake packets
(like the uat example) as well as expired identities. The self-signature on
the UID packet in your example expired 2008-12-31, so it (and all of its
third-party signatures) are pruned from the response. Only the public key
packet remains.


> Regards
> Stefan
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Keyserver] Hockeypuck 2.1.0 released

[Stefan Claas via Gnupg-users]

On Fri, Dec 11, 2020 at 10:25 AM Werner Koch  wrote:
>
> On Thu, 10 Dec 2020 11:07, Casey Marshall said:
>
> >- Authenticated key management. This adds a couple of extra endpoints
> >which allow a key owner to replace and delete their key, authenticated by
> >signing the armored key in the request. This allows a key owner to still
> >update their own key once it has been inflated beyond the key
>
> Finally after more than 20 years waiting for someone to implement such a
> feature.  Yeah.  Where can I find the specs?
>
> Did you consider that an authenticated request to delete a key may not
> actually remove the key from the keyserver?  Instead the the primary key
> should be kept and the server prepared to receive and merge even
> unauthenticated revocation certificates.  This is important in case of a
> lost key (or passphrase forgotten) so that a pre-created revocation
> certificate can be uploaded.  Also avoids DoS after a key compromise.

Hi Werner and Casey,

I have a question for both of you.

When I reported a while ago on GitHub about a fake uat packet on Werner's
key you quickly fixed the issue and the added image of 'Donnie' no longer
showed up at the Ubuntu keyserver. Interestingly now GitHub shows zero
issues as of today, while yesterday still some issues where open and a lot
of them closed.

Now my second question how is/was this done with Werner's key?

SKS still shows Werner's key with signatures, while the Ubuntu keyserver
shows only a very small key now. Before that the Ubuntu key server showed
the sigs too and additionally the fake uat packet (Donnie image).

Does this mean that a GnuPG user can modify his key in such a way
and re-submit it, so that the result is now like Werner's key or can a
Hockerpuck operator do this (on behalf) of the key owner? The key
in question, on the Ubuntu keyserver has also no longer a UID, which
I thought only sequoia-pgp can handle and not GnuPG.

https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630=on=vindex

http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630=on=vindex

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Keyserver] Hockeypuck 2.1.0 released

[Werner Koch via Gnupg-users]

On Thu, 10 Dec 2020 11:07, Casey Marshall said:

>- Authenticated key management. This adds a couple of extra endpoints
>which allow a key owner to replace and delete their key, authenticated by
>signing the armored key in the request. This allows a key owner to still
>update their own key once it has been inflated beyond the key

Finally after more than 20 years waiting for someone to implement such a
feature.  Yeah.  Where can I find the specs?

Did you consider that an authenticated request to delete a key may not
actually remove the key from the keyserver?  Instead the the primary key
should be kept and the server prepared to receive and merge even
unauthenticated revocation certificates.  This is important in case of a
lost key (or passphrase forgotten) so that a pre-created revocation
certificate can be uploaded.  Also avoids DoS after a key compromise.

> Blacklists and auth key management may also be of interest to keyserver

Still revocation certificates should get through.  At least the first
valid revocation certificate needs to be handles before the key can be
set into an eternal non-modifiable state.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Keyserver] Hockeypuck 2.1.0 released (Andrew Gallagher)

[Andrew Gallagher]

> On 11 Dec 2020, at 05:11, Casey Marshall via Gnupg-users 
>  wrote:
> 
> Peers across these more divergent cohorts may still peer at a lower 
> frequency, so key material accepted by both may still propagate.

But the problem with divergence isn’t loss of efficiency - divergent servers 
don’t gracefully degrade. They work perfectly fine until they hit the 
polynomial limit, and then they just break. And they break in a way
that requires reloading the entire database from scratch. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Keyserver] Hockeypuck 2.1.0 released (Andrew Gallagher)

[Casey Marshall via Gnupg-users]

>
> Date: Thu, 10 Dec 2020 19:59:46 +
> From: Andrew Gallagher 
> To: SKS Development and Deployment discussion ,
> GnuPG Users 
> Subject: Re: [Keyserver] Hockeypuck 2.1.0 released
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> How do you handle the gradual degradation of sync as different operators
> implement divergent blacklists?
>

This might be a controversial opinion, but I would allow it to happen.

Even if reconciliation cannot provide perfect consistency in such a world,
it is still useful as a gossip protocol to distribute new keys and
signatures.

My prediction (given keyserver operator buy-in) is, some cohorts of
like-minded keyserver operators will coordinate on their settings. Peers in
these cohorts will keep relatively more closely in sync and propagate key
material faster amongst themselves, than with those that have different
policies that cause them to diverge more widely. Peers across these more
divergent cohorts may still peer at a lower frequency, so key material
accepted by both may still propagate.

-Casey

A
> On 10/12/2020 17:07, Casey Marshall wrote:
> > I've released Hockeypuck 2.1.0
> > <https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0> [0], which
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Keyserver] Hockeypuck 2.1.0 released

[Andrew Gallagher]

How do you handle the gradual degradation of sync as different operators 
implement divergent blacklists?


A

On 10/12/2020 17:07, Casey Marshall wrote:
I've released Hockeypuck 2.1.0 
<https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0> [0], which 
contains several new features that may be useful to mitigate 
spamming/flooding/DoS [1] attacks on GnuPG and keyservers. See the 
release link for details, but here's the highlights:


  * Configurable key length and packet size limits, with sensible
defaults to limit keyserver resource consumption (1MB and 8K
respectively).
  * Configurable blacklist of primary key fingerprints.
  * Authenticated key management. This adds a couple of extra endpoints
which allow a key owner to replace and delete their key,
authenticated by signing the armored key in the request. This allows
a key owner to still update their own key once it has been inflated
beyond the key length limit.

Blacklists and auth key management may also be of interest to keyserver 
operators subject to GDPR-related requests.



-Casey


[0] https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0 
<https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0>


[1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f 
<https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f>





--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Keyserver] Hockeypuck 2.1.0 released

[Casey Marshall via Gnupg-users]

I've released Hockeypuck 2.1.0
<https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0> [0], which
contains several new features that may be useful to mitigate
spamming/flooding/DoS [1] attacks on GnuPG and keyservers. See the release
link for details, but here's the highlights:

   - Configurable key length and packet size limits, with sensible defaults
   to limit keyserver resource consumption (1MB and 8K respectively).
   - Configurable blacklist of primary key fingerprints.
   - Authenticated key management. This adds a couple of extra endpoints
   which allow a key owner to replace and delete their key, authenticated by
   signing the armored key in the request. This allows a key owner to still
   update their own key once it has been inflated beyond the key length limit.

Blacklists and auth key management may also be of interest to keyserver
operators subject to GDPR-related requests.


-Casey


[0] https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0

[1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A question about the status of the keyserver structure

[Stefan Claas via Gnupg-users]

Hi,

attached is the (hopefully proper) key.

Regards
Stefan

On Tue, Nov 3, 2020 at 10:44 PM Stakanov via Gnupg-users
 wrote:
>
> I hope this is the correct list for this question:
>
>
>
> I tried to follow the instructions of
>
> https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso
>
> were it says you can import the key to verify the iso.
>
> But kleopatra stays without reaction (no matter how many pools I join) and
>
> entropia@roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys 
> EDCA7A90
> gpg: using character set 'utf-8'
> gpg: ricezione dal keyserver fallita: Connessione rifiutata
>
> which is: reception of keyserver failed: connection refused.
>
>
>
> Now I remember time ago there was an issue of keyservers abused and the 
> structure was halted.
>
>
>
> What is the current status and how can one download a signature as of today? 
> Manually or with a "keyserverpage" on https or how does it work now?
>
> Thank you in advance.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


mageia.asc
Description: Binary data
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

A question about the status of the keyserver structure

[Stakanov via Gnupg-users]

I hope this is the correct list for this question:

I tried to follow the instructions of 
https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso[1] 
were it says you can import the key to verify the iso.
But kleopatra stays without reaction (no matter how many pools I join) and 
entropia@roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys 
EDCA7A90 


Now I remember time ago there was an issue of keyservers abused and the 
structure 
was halted. 

What is the current status and how can one download a signature as of today? 
Manually or with a "keyserverpage" on https or how does it work now?
Thank you in advance. 


[1] https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preserving public keyserver network (Re: Which keyserver)

[Stefan Claas via Gnupg-users]

If it is a technical challenge and Kristian as head (pool maintainer),
why does he not ask publicity
the hockeypuck author, dkg and the sequoia-team, for help?

As an example, if I would be Kristian I would do so, set-up with my
pool gang a hockeypuck
test-net (bootstrapped with a handful of pub keys) and work with the
programmer(s) on long
standing issues. Secondly I would give my gang a timeframe of a couple
of months to
gracefully shut down their SKS servers.

Would that have any disadvantages for GnuPG users worldwide, while we also have
Mailvelope and Hagrid?

On Sat, Oct 24, 2020 at 1:39 PM Andrew Gallagher  wrote:
>
>
> > On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users 
> >  wrote:
> >
> > there can
> > be no consensus achieved between privacy loving EU citizens and (US
> > based) SKS operators
>
> Most SKS operators are (were?) based outside the US. This is primarily a 
> technical challenge, not a political one.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preserving public keyserver network (Re: Which keyserver)

[Andrew Gallagher]

> On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users 
>  wrote:
> 
> there can
> be no consensus achieved between privacy loving EU citizens and (US
> based) SKS operators

Most SKS operators are (were?) based outside the US. This is primarily a 
technical challenge, not a political one. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preserving public keyserver network (Re: Which keyserver)

[Stefan Claas via Gnupg-users]

I can only speak for myself and see that when it comes to SKS that there can
be no consensus achieved between privacy loving EU citizens and (US
based) SKS operators, while Mailvelope and Hagrid respect the users wishes.

With that being said I am out and better let Mr Barr and Mr de Kerchove decide
what the SKS future will bring.

Last but not least I no longer need public SKS key servers.

Best regards
Stefan




On Fri, Oct 23, 2020 at 12:55 PM Bernhard Reiter  wrote:
>
> Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> > I stand by my points that hockeypuck can solve the issues
>
> To me
> it makes sense to preserve a decentalised network of public keyservers [1].
>
> In my post
>  Preserving non-central and privacy with a "permission recording keyserver"
> [Reiter 2019-07 a]
>  https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html
> there is a concept allowing for compatibility with strong privacy laws.
>
> Some ideas how we could conceptually preserve third party
> signature information on public servers:
>   Preserving third party signatures distribution [Reiter 2019-07 b]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html
>
> So yes, I also believe that improvements to hockeypuck or a fresh
> implementation could step by step get the public keyserver network up again.
>
>
> Best Regards,
> Bernhard
> ps.: Because I believe funding more qualified dev time is part of the
> solution: You can become a sponsor for hockeypuck development, see
>   https://github.com/sponsors/cmars
> (my company Intevation is one, we also gave a small donation to KF Web running
>  https://sks-keyservers.net/).
>
>
> [1]
>   Web of Trust's usefulness [Reiter 2019-07 c]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034412.html
>
>   | as additional source of trust and history.
>
>   | Abandoning the web of trust common infrastructure works against usage
>   | models where there is anonymous usage, several identities, non-email use
>   | and offline usage. All those maybe not the majority case, they may even be
>   | niche models, but I think they are important to add diversity and
>   | resiliance against manipulations of mainstream players.
>(spelling improved)
>
> --
> www.intevation.de/~bernhard   +49 541 33 508 3-3
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preserving public keyserver network (Re: Which keyserver)

[Andrew Gallagher]

On 23/10/2020 13:23, Andrew Gallagher wrote:
> * Hints could take the form of fake preferred-keyserver subpackets, in a
> similar manner to fake "fpr:DEADBEEF" user-id packets that have been
> previously discussed to support UID-less key refresh on legacy systems
> (could both be combined in a single fake BIND sig?).

After a little further thought, such a combined-bind is wrongheaded. The
entire point of fake userids is that userids are (potentially) personal
data and therefore can't sync. ;-) So we'd have to bind the fake
preferred-keyserver subpacket separately.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preserving public keyserver network (Re: Which keyserver)

[Andrew Gallagher]

On 23/10/2020 10:14, Bernhard Reiter wrote:
> So yes, I also believe that improvements to hockeypuck or a fresh 
> implementation could step by step get the public keyserver network up again.

I've thought about this quite a bit after my previous attempts to
reconcile recon with selective retention. I believe the solution is to
segregate the "recon" part of the process from the "retention" part.

Our current recon model requires that all packets that exist in the
keyserver network be reconned via the same method. This causes problems
when trying to apply retention policies to certain packets and not
others. For example, we almost always want revocation packets to recon,
almost *never* want user-attribute packets, and other packets such as
user-id fall somewhere in between.

If we segregate the recon and retention components, we can recon an
agreed bare minimum of packet types, without needing to apply per-key
filters and thereby avoiding any split-brain or sync-storm failures.
This minimal list of packet types would have to include primary keys and
revocation keys, but little (perhaps nothing?) else.

Along with these packets each keyserver would gossip a list of
associated hints from other keyservers. These hints would declare that
an "authoritative keyserver" exists that is serving the full key,
presumably having performed validation. The full set of packets would
not be advertised for recon, but would be available through hkp(s) as
normal (for the purposes of this section, the existence of an entry in
WKD would count as an "authoritative keyserver"). Other keyservers would
gossip that they have recently been able to download the full key from
one or more authoritative locations. Such hints would not be
cryptographically part of the key in question, so they should have an
expiration date in order to prevent stale info accumulating in the network.

A keyserver that is not willing to retain the full set of packets for a
given key could instead choose to serve them via a caching proxy or an
HTTP redirect to a server that is willing. This would allow for the full
public key to be discovered and refreshed by the usual methods, but
without every keyserver in the network having to retain its own copy.

It would still be advisable for a user to upload their full key to more
than one validating keyserver, in order to guard against service
outages, but even in the case where the only copy of the full key
becomes unavailable indefinitely, primary and revocation packets
associated with it would continue to recon. This model also has the
advantage of significantly reducing the number of packets in the recon
database.

Some other initial ideas:

* The new pool would have to be completely separate from the old pool,
because the deltas would be astronomical.

* Existing validating keyservers could cheaply "join the new pool" by
setting up a separate reconning keyserver in the pool that a) advertises
the appropriate hints on behalf of the validating keyserver and b)
submits any newly-synced packets into the validating keyserver.

* Hints could take the form of fake preferred-keyserver subpackets, in a
similar manner to fake "fpr:DEADBEEF" user-id packets that have been
previously discussed to support UID-less key refresh on legacy systems
(could both be combined in a single fake BIND sig?). These would be
amenable to recon, and naturally come with a timestamp that could be
used to expire them from the cache. Cryptographic non-verification
should ensure that real preferred-keyserver subpackets would override
such hints in client applications.

Thoughts?

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Preserving public keyserver network (Re: Which keyserver)

[Bernhard Reiter]

Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> I stand by my points that hockeypuck can solve the issues

To me 
it makes sense to preserve a decentalised network of public keyservers [1].

In my post 
 Preserving non-central and privacy with a "permission recording keyserver"
[Reiter 2019-07 a]
 https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html
there is a concept allowing for compatibility with strong privacy laws.

Some ideas how we could conceptually preserve third party 
signature information on public servers:
  Preserving third party signatures distribution [Reiter 2019-07 b]
  https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html

So yes, I also believe that improvements to hockeypuck or a fresh 
implementation could step by step get the public keyserver network up again.


Best Regards,
Bernhard
ps.: Because I believe funding more qualified dev time is part of the 
solution: You can become a sponsor for hockeypuck development, see   
  https://github.com/sponsors/cmars 
(my company Intevation is one, we also gave a small donation to KF Web running
 https://sks-keyservers.net/).


[1]
  Web of Trust's usefulness [Reiter 2019-07 c]
  https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034412.html

  | as additional source of trust and history.

  | Abandoning the web of trust common infrastructure works against usage
  | models where there is anonymous usage, several identities, non-email use
  | and offline usage. All those maybe not the majority case, they may even be
  | niche models, but I think they are important to add diversity and
  | resiliance against manipulations of mainstream players.
   (spelling improved)

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[MFPA via Gnupg-users]

Hi


On Sunday 20 September 2020 at 11:29:07 PM, in
, Mark wrote:-


> I'm the one that asked the original question in
> regards to GPG4Win. I
> know with the latest version the default is
> "hkp://keys.gnupg.net"

Thanks, Mark.

hkp://keys.gnupg.net is an alias for hkps://hkps.pool.sks-keyservers.net, which 
Phil said a couple of days ago was returning zero results. That issue is either 
intermittent or fixed, because I retrieved some keys from 
hkps://hkps.pool.sks-keyservers.net a few hours ago and again a few minutes 
ago. At least, a line of the output said "gpg: data source: 
https://hkps.pool.sks-keyservers.net:443 ". 

-- 
Best regards

MFPA  

Never interrupt me when I'm trying to interrupt you.

pgptemJrvZkD0.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Mark]

I'm the one that asked the original question in regards to GPG4Win. I
know with the latest version the default is "hkp://keys.gnupg.net"

On 9/20/2020 4:58 AM, MFPA via Gnupg-users wrote:
> Hi
>
>
> On Saturday 19 September 2020 at 7:34:13 PM, in
> , Phil
> Pennock via Gnupg-users wrote:-
>
>
>> The original question was:
>> } I use GPG4Win and I've noticed that
>> "hkp://keys.gnupg.net" is not
>> so that's what I answered.
> I asked a different but related question that occurred to me when I read in 
> your post that hkps.pool.sks-keyservers.net "is now returning zero results". 
> I had noticed the GnuPG manual says the default keyserver is 
> hkps.pool.sks-keyservers.net. I was under the impression the default had been 
> changed to the Hagrid keyserver at keys.openpgp.org after the SKS attacks, so 
> I asked the question to this list.
>
>
>> The mapping is in
>> dirmngr/server.c:make_keyserver_item() and the default
>> is found via compile-time configure, which defaults to
>> hkps://hkps.pool.sks-keyservers.net (see configure.ac
>> DIRMNGR_DEFAULT_KEYSERVER).
> So we have a default keyserver that is returning zero results?
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[MFPA via Gnupg-users]

Hi


On Saturday 19 September 2020 at 7:34:13 PM, in
, Phil
Pennock via Gnupg-users wrote:-


> The original question was:
> } I use GPG4Win and I've noticed that
> "hkp://keys.gnupg.net" is not

> so that's what I answered.  

I asked a different but related question that occurred to me when I read in 
your post that hkps.pool.sks-keyservers.net "is now returning zero results". I 
had noticed the GnuPG manual says the default keyserver is 
hkps.pool.sks-keyservers.net. I was under the impression the default had been 
changed to the Hagrid keyserver at keys.openpgp.org after the SKS attacks, so I 
asked the question to this list. 


> The mapping is in
> dirmngr/server.c:make_keyserver_item() and the default
> is found via compile-time configure, which defaults to
> hkps://hkps.pool.sks-keyservers.net (see configure.ac
> DIRMNGR_DEFAULT_KEYSERVER).

So we have a default keyserver that is returning zero results?

-- 
Best regards

MFPA  <mailto:2017-r3sgs86x8e-lists-gro...@riseup.net>

The more corrupt the state, the more numerous the laws. (Tacitus)

pgp7t_A9mk5bx.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Neal H. Walfield]

Hi Andrew,

On Sat, 19 Sep 2020 21:38:22 +0200,
Andrew Gallagher wrote:
> Hagrid “solves” the vandalism problem by abandoning
> decentralisation.

This is not strictly true.

When we think about updating keys, there are two types of information
that can be updated:

  - Identity Information (User IDs)
  - Operational Information (Revocations, Subkey Rotations, Metadata
(self-sig) updates, etc.)

Identity information in privacy sensitive, and we think people should
be able to control where their details are published, and have the
ability to retract them, if desired.  This requires some type of
centralization.

Operation Information does not require the same protection, and can
and should be widely published.  It would be possible to create a
network of keyservers that synchronize this type of information in a
similar way to how SKS worked.  But, we know from experience with SKS
that this is not easy (the set of filters needs to be synchronized,
etc., which is a type of centralization).  So far, no one has taken
the time to think through this problem, and implement a solution for
Hagrid.  But, I think that we'd welcome a patch that adds such
functionality.

:) Neal

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Stefan Claas]

Andrew Gallagher wrote:
 
> 
> > On 19 Sep 2020, at 21:06, Stefan Claas  wrote:
> > 
> > *With all due respect*, the problems you mention with the SKS protocol is 
> > IMHO absolutely solvable with hockeypuck if the
> > author implements the same Mailvelope or Hagrid confirmation process for 
> > its users
> 
> If you have not yet read the mega threads from a year or two back over on the 
> sks mailing list discussing how filtering is
> incompatible with open synchronisation, I suggest you do so before opining 
> further. I really don’t have the energy to explain
> it again! ;-) tl;dr: if you don’t have either a central authority or an 
> agreed, future-proof zkp system of verification
> (itself a Very Hard Problem) then your decentralised network goes split brain 
> at the slightest provocation. 
> 
> https://lists.nongnu.org/archive/html/sks-devel/2018-05/msg9.html
> 
> https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00010.html
> 
> I’d also suggest reading DKG’s proposals for what *is* technically possible, 
> as they are pretty comprehensive: 
> 
> https://lists.nongnu.org/archive/html/sks-devel/2019-04/msg2.html
> 
> Finally, I would suggest continuing any technical discussions on sks-devel 
> rather than here as we are veering off topic.

I am not interested to discuss old SKS issues/proposals further on the SKS 
mailing list
with (former) SKS operators and only wanted to bring my POV to GnuPG users 
attention.

I am aware of dkg's fine draft and his other valuable contributions he made.

I stand by my points that hockeypuck can solve the issues and will respect your
wish to not further discuss technical SKS issues here on the GnuPG Mailing List.

In case dkg is reading this thread, maybe he, as highly respected community 
member and
skilled programmer, can discuss these things with the hockeypuck author on 
GitHub, in
case he has time and is willing to do so. 

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Steffen Nurpmeso]

Stefan Claas wrote in
 <20200919201736.2...@300baud.de>:
 |Robert J. Hansen wrote:
 |>> It is true the attacks were what brought it down, but the amount \
 |>> of effort was not a "sustained
 |>> attack" by any measure. The invested resources are somewhere around \
 |>> "couple hours and $0.00".
 |> 
 |> I'm not sure that's true.
 |
 |[...]
 |
 |I think it does not matter.
 |
 |Professional businesses and their customers can use the mentioned Mailve\
 |lope key server,
 |to protect their keys or use for anonymity purposes Hagrid, in combination \
 |with sequoia
 |pgp, while the geeks can use WKD.
 |
 |The only thing SKS, so it seems, is currently good for is decentralized \
 |file sharing or
 |for chat purposes, when using SKS chat software.

SKS served me very well for many years, and it is a shame that
even national/related agencies with quite some funding, or
universities with that immense pool of students did not stood up
trying to keep this decade old community driven infrastructure
alive.  I guess they all were eating burger, and at that level.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Andrew Gallagher]

> On 19 Sep 2020, at 21:06, Stefan Claas  wrote:
> 
> *With all due respect*, the problems you mention with the SKS protocol is 
> IMHO absolutely solvable with hockeypuck if the author
> implements the same Mailvelope or Hagrid confirmation process for its users

If you have not yet read the mega threads from a year or two back over on the 
sks mailing list discussing how filtering is incompatible with open 
synchronisation, I suggest you do so before opining further. I really don’t 
have the energy to explain it again! ;-) tl;dr: if you don’t have either a 
central authority or an agreed, future-proof zkp system of verification (itself 
a Very Hard Problem) then your decentralised network goes split brain at the 
slightest provocation. 

https://lists.nongnu.org/archive/html/sks-devel/2018-05/msg9.html

https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00010.html

I’d also suggest reading DKG’s proposals for what *is* technically possible, as 
they are pretty comprehensive: 

https://lists.nongnu.org/archive/html/sks-devel/2019-04/msg2.html

Finally, I would suggest continuing any technical discussions on sks-devel 
rather than here as we are veering off topic.

A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Stefan Claas]

Andrew Gallagher wrote:
 
> 
> > On 19 Sep 2020, at 20:05, Stefan Claas  wrote:
> > 
> > Well, there is IMHO a good replacement for SKS available, called
> > hockeypuck and it is written in modern Golang.
> 
> This is beside the point. SKS is both a protocol and an implementation. 
> Hockeypuck is a reimplementation of the same protocol
> and is so is vulnerable to the same poisoning issues. 
> 
> The problem with the SKS *protocol* is very hard to fix, because designing a 
> universal, publicly writable datastore means
> solving a trilemma: censorship resistance, vandalism resistance, and 
> decentralisation. SKS prioritises censorship resistance
> and decentralisation, and so is vulnerable to vandalism. Hagrid “solves” the 
> vandalism problem by abandoning
> decentralisation. WKD steps outside the problem space by abandoning 
> universality. All these are valid alternatives, but none
> can be called a “replacement”.

*With all due respect*, the problems you mention with the SKS protocol is IMHO 
absolutely solvable with hockeypuck if the author
implements the same Mailvelope or Hagrid confirmation process for its users, or 
it would honor the SKS --no-modify flag, Werner
implemented long time ago in GnuPG. And if (former) SKS key server operators 
would be honest this could be solved with
hockeypuck and if not people which are using GnuPG or OpenPGP apps may 
wondering how it comes that a client/server model for
*security/privacy* software is from the SKS server side globally still 
operated, if it can not *protect* their users pub keys
adequately?

I am very sorry to say that but all arguments from former or current SKS 
operators do not convince me nor do they show the
OpenPGP users community willingness or advancements in this area, to be taken 
serious.

Best regards
Stefan
 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-19 at 11:44 +0100, MFPA via Gnupg-users wrote:
> On Friday 18 September 2020 at 4:32:55 PM, in
> , Phil
> Pennock via Gnupg-users wrote:-
> 
> 
> > keys.gnupg.net is a CNAME for
> > hkps.pool.sks-keyservers.net -- which is
> > now returning zero results.
> 
> 
> The GnuPG manual's description [0] of the Dirmngr option "--keyserver name" 
> still ends with "If no keyserver is explicitly configured, dirmngr will use 
> the built-in default of hkps://hkps.pool.sks-keyservers.net." Is this still 
> true, or was the default changed?

The original question was:
} I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not

so that's what I answered.  keys.gnupg.net _used to be_ the default, but
it was changed and nowadays there is both a CNAME in DNS and logic in
modern GnuPG to hard-replace the hostname.

The mapping is in dirmngr/server.c:make_keyserver_item() and the default
is found via compile-time configure, which defaults to
hkps://hkps.pool.sks-keyservers.net (see configure.ac
DIRMNGR_DEFAULT_KEYSERVER).

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Andrew Gallagher]

> On 19 Sep 2020, at 20:05, Stefan Claas  wrote:
> 
> Well, there is IMHO a good replacement for SKS available, called
> hockeypuck and it is written in modern Golang.

This is beside the point. SKS is both a protocol and an implementation. 
Hockeypuck is a reimplementation of the same protocol and is so is vulnerable 
to the same poisoning issues. 

The problem with the SKS *protocol* is very hard to fix, because designing a 
universal, publicly writable datastore means solving a trilemma: censorship 
resistance, vandalism resistance, and decentralisation. SKS prioritises 
censorship resistance and decentralisation, and so is vulnerable to vandalism. 
Hagrid “solves” the vandalism problem by abandoning decentralisation. WKD steps 
outside the problem space by abandoning universality. All these are valid 
alternatives, but none can be called a “replacement”.

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Stefan Claas]

Steffen Nurpmeso wrote:
 
> Stefan Claas wrote in
>  <20200919201736.2...@300baud.de>:
>  |Robert J. Hansen wrote:
>  |>> It is true the attacks were what brought it down, but the amount \
>  |>> of effort was not a "sustained
>  |>> attack" by any measure. The invested resources are somewhere around \
>  |>> "couple hours and $0.00".
>  |> 
>  |> I'm not sure that's true.
>  |
>  |[...]
>  |
>  |I think it does not matter.
>  |
>  |Professional businesses and their customers can use the mentioned Mailve\
>  |lope key server,
>  |to protect their keys or use for anonymity purposes Hagrid, in combination \
>  |with sequoia
>  |pgp, while the geeks can use WKD.
>  |
>  |The only thing SKS, so it seems, is currently good for is decentralized \
>  |file sharing or
>  |for chat purposes, when using SKS chat software.
> 
> SKS served me very well for many years, and it is a shame that
> even national/related agencies with quite some funding, or
> universities with that immense pool of students did not stood up
> trying to keep this decade old community driven infrastructure
> alive.  I guess they all were eating burger, and at that level.

Well, there is IMHO a good replacement for SKS available, called
hockeypuck and it is written in modern Golang.

The problem is that those (I don't know what to call these people
publicity) SKS key server operators have no plan.

The hockeypuck author is really fast in responding when it comes
to issues and I guess he would be quite happy to help the SKS operators
with solving issues, or listen to users if they have proposals.

The good thing about the modern programming language Golang is that
*soo* many (young) people are using Golang nowadays, that
it should be easy to assist the author of hockeypuck.

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Stefan Claas]

Robert J. Hansen wrote:
 
> > It is true the attacks were what brought it down, but the amount of effort 
> > was not a "sustained
> > attack" by any measure. The invested resources are somewhere around "couple 
> > hours and $0.00".
> 
> I'm not sure that's true.

[...]

I think it does not matter.

Professional businesses and their customers can use the mentioned Mailvelope 
key server,
to protect their keys or use for anonymity purposes Hagrid, in combination with 
sequoia
pgp, while the geeks can use WKD.

The only thing SKS, so it seems, is currently good for is decentralized file 
sharing or
for chat purposes, when using SKS chat software.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Robert J. Hansen]

> It is true the attacks were what brought it down, but the amount of effort 
> was not a "sustained
> attack" by any measure. The invested resources are somewhere around "couple 
> hours and $0.00".

I'm not sure that's true.

The keyserver poisoning attack was demonstrated first by EFF's Micah
Lee.  When he published his findings, he also published the Python
scripts necessary to execute the attack.

I don't know who the poisoner was.  However, if I were to do the
poisoning attack I certainly would've begun by downloading Micah's code
and adapting it to the task.  And for that reason I think it's entirely
reasonable to believe the keyserver poisoning attack was bootstrapped by
an EFF-funded research project which inappropriately released attack tools.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[MFPA via Gnupg-users]

Hi


On Friday 18 September 2020 at 4:32:55 PM, in
, Phil
Pennock via Gnupg-users wrote:-


> keys.gnupg.net is a CNAME for
> hkps.pool.sks-keyservers.net -- which is
> now returning zero results.


The GnuPG manual's description [0] of the Dirmngr option "--keyserver name" 
still ends with "If no keyserver is explicitly configured, dirmngr will use the 
built-in default of hkps://hkps.pool.sks-keyservers.net." Is this still true, 
or was the default changed?

[0] 
https://gnupg.org/documentation/manuals/gnupg/Dirmngr-Options.html#Dirmngr-Options

-- 
Best regards

MFPA  <mailto:2017-r3sgs86x8e-lists-gro...@riseup.net>

Ballerinas are always on their toes.  We need taller ballerinas!

pgp68dbHVaZmx.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Vincent Breitmoser via Gnupg-users]

> keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
> now returning zero results.

Let me break the prose down into the simple facts:

* the "HKPS" pool is no longer actually a "pool". it is a [single server].

* the "HKP" pool still contains a few servers, but using it means *all 
communication happens in plain text*.

* the newest release of SKS is [1.1.6], from august 2016.

> until it came under sustained attack from people trying to burn it all down

It is true the attacks were what brought it down, but the amount of effort was 
not a "sustained
attack" by any measure. The invested resources are somewhere around "couple 
hours and $0.00".

 - V

[single server]: https://sks-keyservers.net/status/ (hkps column)
[1.1.6]: 
https://github.com/SKS-Keyserver/sks-keyserver/commit/b1725fda5dd89343b304c2126df78ad34bef66a8

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-18 at 15:04 +0200, accounts-gn...@holbrook.no wrote:
> Is it possible to define multiple sources of keys with WKD, for example
> with a dns TXT record? The use-case would be if the main server is down,
> alternative places to get it.

The SRV record approach had to be dropped because the people doing
OpenPGP in web-browsers protested hard, since browsers _still_ refuse to
implement SRV lookup.  So we're stuck with an ancient model.

Currently that means "set up openpgpkey.example.org using whatever
loadbalancers and multiple A records across regions you like".

Within a few years we _might_ be able to get SRV-like distribution for
HTTPS with the proposed new `HTTPS` RR-type for DNS:
  https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https
but that's not something you can rely on today.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Mark]

Phil,

Thanks for the explanation on what was happening. I thought something
was just not right as when I hit search it would come back in less than
a second with 0 results. It seemed to me that it didn't actually even
search through the database. Anyway now that you say there is not really
a server anymore to search it makes sense. 

I'm not familiar with the attack on it and by who so will have to google
it and see if I can learn more.

On 9/18/2020 8:32 AM, Phil Pennock wrote:
> On 2020-09-18 at 08:06 -0700, Mark wrote:
>> I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not
>> working right. I was not getting any hits back when searching with
>> Kleopatra and then I tried to ping that server which returned host not
>> found.  So I'm also interested if there is a better choice.
> keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
> now returning zero results.
>
> The pool of  is Very Unhealthy.  The entire keyserver
> system had Known Issues but worked well enough that the volunteers who
> ran it could keep it alive and improving, until it came under sustained
> attack from people trying to burn it all down and push people to use
> "not OpenPGP" instead (some of the funding for attack tool development
> came from an org which is firmly pushing one of the modern alternative
> encrypted communications tools).
>
> There's still some keyservers, but what you see now are the red smoking
> embers of what's left after everything else has been burnt down.  From a
> pool of around 120 servers, almost all routinely working fairly well and
> being able to maintain per-continent pool aliases of servers which were
> health-checked and removed if not doing well, there's now fewer than 20
> servers left, from very few independent sources, and even those in the
> main pool are often not doing well.
>
> Which is why folks are struggling and trying to find something which
> works well enough.  There's nothing which fits all needs, but various
> solutions for some scenarios.  See my first reply in this thread with
> suggestions of particular servers.
>
> -Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Andreas Mattheiss]

Hello,

>Is it possible to define multiple sources of keys with WKD, for example
>with a dns TXT record?

Well, yes, actually. This can be done with both X509 certificates (where it is 
called SMIMEA) and gpg keys. Obtaining a key basically involves quering the 
appropriate TYPE in the DNS record (53 for SMIMEA, 61 for openpgp). An 
additional step is to check the authenticity of this record. All this is 
completely seperate from WKD though.

That's the theory. In practise, alas, bugger all's using it. It's a shame, 
since this would really be a big step forward. The catch here is that it needs 
to be supported by the mail server where the addressee has his account. 
Needless to mention it is hardly deployed; in Germany mail.de has it, as do a 
number of paid email services. Plus, of course: before this goes big, the big 
email clients would have to support it. Of course you can hack something 
together using only command line tools (I've done that), but that's not the cup 
of tea for 99.9% of normal email users.

Vincent Breitmoser described this in this thread eloquently as being used by 
effectively nobody but a rounding error. Sigh.

Andreas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-18 at 08:06 -0700, Mark wrote:
> I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not
> working right. I was not getting any hits back when searching with
> Kleopatra and then I tried to ping that server which returned host not
> found.  So I'm also interested if there is a better choice.

keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
now returning zero results.

The pool of SKS keyservers is Very Unhealthy.  The entire keyserver
system had Known Issues but worked well enough that the volunteers who
ran it could keep it alive and improving, until it came under sustained
attack from people trying to burn it all down and push people to use
"not OpenPGP" instead (some of the funding for attack tool development
came from an org which is firmly pushing one of the modern alternative
encrypted communications tools).

There's still some keyservers, but what you see now are the red smoking
embers of what's left after everything else has been burnt down.  From a
pool of around 120 servers, almost all routinely working fairly well and
being able to maintain per-continent pool aliases of servers which were
health-checked and removed if not doing well, there's now fewer than 20
servers left, from very few independent sources, and even those in the
main pool are often not doing well.

Which is why folks are struggling and trying to find something which
works well enough.  There's nothing which fits all needs, but various
solutions for some scenarios.  See my first reply in this thread with
suggestions of particular servers.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-18 at 10:08 +0200, Franck Routier (perso) wrote:
> Le jeudi 17 septembre 2020 à 18:13 -0400, Phil Pennock via Gnupg-users
> a écrit :
> >  If publishing keys, I do recommend setting up WKD for your
> > domain, which helps a little.
> 
> What is the status of WKD now, and is it to superseed centralized key
> servers ?

It's a draft spec, it's spreading a little.  Federated control of your
own namespace is always good.  Ultimately it's just HTTPS with a fixed
well-known layout.

kernel.org, debian.org, gentoo.org, archlinux.org -- it's spreading
amongst the Linux folks who have a central idea of what PGP keys are
supposed to exist in their domain.

Then there's exim.org and a couple of others, but I set those up and so
I can't say that this is proof of its popularity.

I think that any organization which uses PGP, including for signing
software releases, should be setting up WKD.  Non-WKD is for individuals
using PGP on a more ad-hoc basis.

Self-pimping:  has
other/standalone-update-website as a Python tool which can be integrated
into static site builds where something else manages the list of keys (I
have it in a Gulp rule for nats.io site build) and the repo itself is a
framework for managing the keys for one or more domains, so is used for
spodhuis.org, exim.org and pennock-tech.com.  The repo is designed to be
easy to fork and replace the key/domain definitions so that others can
use it.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Mark]

I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not
working right. I was not getting any hits back when searching with
Kleopatra and then I tried to ping that server which returned host not
found.  So I'm also interested if there is a better choice.


On 9/17/2020 1:57 PM, Martin wrote:
> Hi list
>
> Which keyserver do you recommend these days?
>
> I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
> are missing a lot of public keys on this server.
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[accounts-gnupg]

I wasn't aware of WKD, thanks for the heads up.

Is it possible to define multiple sources of keys with WKD, for example
with a dns TXT record? The use-case would be if the main server is down,
alternative places to get it.


On Fri, Sep 18, 2020 at 12:55:45PM +0200, Vincent Breitmoser via Gnupg-users 
wrote:
> 
> > What is the status of WKD now, and is it to superseed centralized key
> > servers ?
> 
> Not for folks who have their email address at the domain of an email provider,
> or an organization that doesn't support WKD. So statistically, everyone but
> a rounding error.
> 
> That said, for folks who run their own domain, a it seems WKD is gaining some
> ground.  keys.o.o has a (sort of experimental) "[WKD as a Service]" feature, 
> and
> at this point there are more than 100 domains running on it. That's not a huge
> amount, assuming most of those are single-user domains, but it's something :)
> 
>  - V
> 
> [WKD as a Service]: https://keys.openpgp.org/about/usage#wkd-as-a-service
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Vincent Breitmoser via Gnupg-users]

> What is the status of WKD now, and is it to superseed centralized key
> servers ?

Not for folks who have their email address at the domain of an email provider,
or an organization that doesn't support WKD. So statistically, everyone but
a rounding error.

That said, for folks who run their own domain, a it seems WKD is gaining some
ground.  keys.o.o has a (sort of experimental) "[WKD as a Service]" feature, and
at this point there are more than 100 domains running on it. That's not a huge
amount, assuming most of those are single-user domains, but it's something :)

 - V

[WKD as a Service]: https://keys.openpgp.org/about/usage#wkd-as-a-service

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Franck Routier (perso)]

Le jeudi 17 septembre 2020 à 18:13 -0400, Phil Pennock via Gnupg-users
a écrit :
>  If publishing keys, I do recommend setting up WKD for your
> domain, which helps a little.

What is the status of WKD now, and is it to superseed centralized key
servers ?

Franck


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-17 at 22:57 +0200, Martin wrote:
> Which keyserver do you recommend these days?

For what purpose?

For receiving updates to previously known keys, of people who care
enough about their keys to distribute their keys across multiple
keyservers instead of just going "I pushed it to the keyservers, that's
it, I don't care", hkps://keys.openpgp.org is probably the most
reasonable choice.

There's no choice for general purpose, and  "running a keysigning party"
or "finding someone's key from their fingerprint" which works well
today.  If publishing keys, I do recommend setting up WKD for your
domain, which helps a little.  And heck, I run a finger daemon written
in Go for a true blast from the past.  :)

 is in the UK, run from the same University bunch of
folks as gave us PuTTY and has been around receiving keys from the SKS
keyservers via email for ages, so tends to be "fairly well populated",
so is where I try next after openpgp.org.

After that I hit old SKS keyservers which usually seem to work, whether
or not these entries are in the pools and _current_, since they'll at
least get me some of a key; the pool hostnames haven't been worth trying
the last several times I checked, too many bad servers.

  hkps://keyserver.ubuntu.com
  hkps://zimmermann.mayfirst.org
  hkp://keys2.kfwebs.net
  hkps://pgp.mit.edu

The kfwebs and pgp.mit.edu servers appear to not be working right now,
which leaves us with Ubuntu's and Dan Gillmor's (DKG's) mayfirst.org
server.

You can still look over https://sks-keyservers.net/status/ to see if
there are any working there, if the pool hostnames are broken for you at
the time you check.  The status list for the servers not in the pools
will show you how far "behind" they are.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Stefan Claas]

Martin wrote:
 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi list
> 
> Which keyserver do you recommend these days?
> 
> I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
> are missing a lot of public keys on this server.

Hi,

good question ... I like https://keys.mailvelope.com/ best, because
it only allows publishing your pub key if you decrypt their reply
with your secret key and as bonus it keeps your collected WoT sigs,
in case you need the classical WoT signatures, or CA sigs, like from
Governikus etc.

Unfortunately gpg.conf, IIRC, allows only defining one key server and
many people still use SKS key servers.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Which keyserver

[Martin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list

Which keyserver do you recommend these days?

I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
are missing a lot of public keys on this server.

- --
Best regards,
Martin
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE92uV/w2x7WB1p4XLsdyR185C444FAl9jzeAACgkQsdyR185C
444yaAgAgoj2wlUFhclr4nr/PeRu9LXHWR4IAbI7UvfmNEk2PcJVveIYHXrRQqdq
AOzxOv+HCzxz5RN9TIiQjLnqcyJlzQpZd6BIFRizr7ZMXEjtSS0oM/u0zevypcae
8L/uhFHgqp3KzYU7njz17k08JVGGTcOBhdGwICa+jlxc4L2y7eZhkFHoFFUxAPwc
xegbJOQKRLZhlLbvSsiFUc5x4uvxesA4ivqFNHWk336XHqdtUOG2tFr6i+hJF3Qc
d6b3g5psigQycr5l2NVQbsHHR0ie6KlX0/KJM9hZmpvPL3yEo4YhdWaeOAABU+AS
J+VEervsa2vRod5euFtPisS+EM2Z5g==
=d3Cq
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver refresh failed: No keyserver available

[Werner Koch via Gnupg-users]

On Mon,  6 Jul 2020 09:11, Jerry said:

> gpg2 --refresh-keys
> gpg: enabled debug flags: memstat
> gpg: refreshing 168 keys from hkp://pool.sks-keyservers.net
> gpg: keyserver refresh failed: No keyserver available

Please add in the error case always the --verbose option which may yield
more diagnostics.

For network related problems, it is best to enable logging for dirmngr:
Put

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

into ~/.gnupg/dirmngr.conf and

  gpgconf --kill dirmngr

(see watchgnupg(1) for a consolidated debug output of all components)
If the output does not show anything helpful, add more debug options:

  debug ipc,network,dns

will give you a trace of all requests to dirmngr (ipc), Network
conenctions and data (network), and DNS lookups (dns).

  dirmngr --debug help

gives a list of such debug options.

Sometimes it is required to either add the option
"disable-ipv4" or "disable-ipv6" to dirmngr.conf.  After changing any
dirmngr option better restart dimngr as described above.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver refresh failed: No keyserver available

[Dmitry Alexandrov]

Jerry  wrote:
> I have not been able to refresh the keys on my system. I have run the 
> following command with the error as shown.
>
> gpg2 --refresh-keys
> gpg: enabled debug flags: memstat
> gpg: refreshing 168 keys from hkp://pool.sks-keyservers.net
> gpg: keyserver refresh failed: No keyserver available

> I don't believe it is a firewall problem, since there is no entry in the 
> firewall log to even suggest that gpg2 tried to access anything.

That is, your have not tried to check the connection on the same machine but 
with some other tool first?  Why?  FWIW, HKP is HTTP on port 11371.

> I have a Windows 10 machine that is using Kleopatra, on the same network, and 
> it is working perfectly.

I do not remember for sure, but is not it, at least, preconfigured to use HKPS, 
i. e. HTTP/TLS on port 443, if not some proprietary keyserver instead of SKS 
pool?


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg: keyserver refresh failed: No keyserver available

[Jerry]

If this is the wrong place to ask this question, I apologize.

FreeBSD 11.4-RELEASE

I have not been able to refresh the keys on my system. I have run the
following command with the error as shown.

gpg2 --refresh-keys
gpg: enabled debug flags: memstat
gpg: refreshing 168 keys from hkp://pool.sks-keyservers.net
gpg: keyserver refresh failed: No keyserver available
gpg: keydb: handles=1 locks=0 parse=168 get=168
gpg:build=0 update=0 insert=0 delete=0
gpg:reset=0 found=168 not=1 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
  outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

This is the version info for gpg2:
gpg2 --version
gpg (GnuPG) 2.2.20
libgcrypt 1.8.5
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/gerard/.gnupg
Supported algorithms:
Pubkey: RSA (1), ELG (16), DSA (17), ECDH (18), ECDSA (19), EDDSA (22)
Cipher: IDEA (S1), 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7),
AES192 (S8), AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11),
CAMELLIA192 (S12), CAMELLIA256 (S13)
Hash: SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10),
  SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)

I don't believe it is a firewall problem, since there is no entry in
the firewall log to even suggest that gpg2 tried to access anything.

I have a Windows 10 machine that is using Kleopatra, on the same
network, and it is working perfectly.

I was hoping that someone could give me some suggestions on how to
debug this problem.

Thanks!

-- 
Jerry


pgpU9C9_wqH8C.pgp
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Keyserver

[Mark]

Thanks I will update it and make sure both Kleopatra and Enigmail are
using the same one so they are "on the same page"

On 5/15/2020 11:55 PM, Michał Górny wrote:
> On Fri, 2020-05-15 at 16:52 -0700, Mark wrote:
>> I know this may be a subjective question but what is the best keyserver
>> to use?  I use GPG4Win with the Enigmail plugin for Thunderbird.  The
>> keyservers listed in Enigmail are:
>>
>> vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net,
>> hkps://pgp.mit.edu
>>
>> The keyserver that is used in Kelopatra (GPG4Win) is:
>>
>> hkp://keys.gnupg.net
> $ host keys.gnupg.net
> keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net.
>

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Keyserver

[Michał Górny via Gnupg-users]

On Fri, 2020-05-15 at 16:52 -0700, Mark wrote:
> I know this may be a subjective question but what is the best keyserver
> to use?  I use GPG4Win with the Enigmail plugin for Thunderbird.  The
> keyservers listed in Enigmail are:
> 
> vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net,
> hkps://pgp.mit.edu
> 
> The keyserver that is used in Kelopatra (GPG4Win) is:
> 
> hkp://keys.gnupg.net

$ host keys.gnupg.net
keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Best Keyserver

[Mark]

I know this may be a subjective question but what is the best keyserver
to use?  I use GPG4Win with the Enigmail plugin for Thunderbird.  The
keyservers listed in Enigmail are:

vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net,
hkps://pgp.mit.edu

The keyserver that is used in Kelopatra (GPG4Win) is:

hkp://keys.gnupg.net


I would think it would be a good idea for both to be configured to use
the same keyserver, so which one is "the best"


Thanks




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location?

[Mihai Moldovan]

* On 9/16/19 3:27 PM, Werner Koch wrote:
> On Mon, 16 Sep 2019 10:11, io...@ionic.de said:
> 
>> which also means that requests to URLs like http://keys.gnupg.net will 
>> sometimes
>> redirect a user to that location.
> 
> That is not correct.  For quite some time that address is a hardwired to
> avoid problems DNS problems (https://dev.gnupg.org/T3755):

I probably should have been more specific.

Yes, that holds for the GnuPG tool, but I was talking about users accessing the
keyserver web interface directly using a normal browser (e.g., for checking on
own or foreign public keys). The CNAME is still used in this case. :)


I was quite surprised to browse to http://keys.gnupg.net and be redirected to
https://analytics.sumptuouscapital.com/ - though luckily only the one mentioned
node does that.



Mihai



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location?

[Werner Koch via Gnupg-users]

On Mon, 16 Sep 2019 10:11, io...@ionic.de said:

> which also means that requests to URLs like http://keys.gnupg.net will 
> sometimes
> redirect a user to that location.

That is not correct.  For quite some time that address is a hardwired to
avoid problems DNS problems (https://dev.gnupg.org/T3755):

  /* We used to have DNS CNAME redirection from the URLs below to
   * sks-keyserver pools.  The idea was to allow for a quick way to
   * switch to a different set of pools.  The problem with that
   * approach is that TLS needs to verify the hostname and - because
   * DNS is not secured - it can only check the user supplied hostname
   * and not a hostname from a CNAME RR.  Thus the final server all
   * need to have certificates with the actual pool name as well as
   * for keys.gnupg.net - that would render the advantage of
   * keys.gnupg.net useless and so we better give up on this.  Because
   * the keys.gnupg.net URL are still in widespread use we do a static
   * mapping here.
   */
  if (!strcmp (uri, "hkps://keys.gnupg.net")
  || !strcmp (uri, "keys.gnupg.net"))
uri = "hkps://hkps.pool.sks-keyservers.net";
  else if (!strcmp (uri, "https://keys.gnupg.net;))
uri = "https://hkps.pool.sks-keyservers.net;;
  else if (!strcmp (uri, "hkp://keys.gnupg.net"))
uri = "hkp://hkps.pool.sks-keyservers.net";
  else if (!strcmp (uri, "http://keys.gnupg.net;))
uri = "http://hkps.pool.sks-keyservers.net;;
  else if (!strcmp (uri, "hkps://http-keys.gnupg.net")
   || !strcmp (uri, "http-keys.gnupg.net"))
uri = "hkps://ha.pool.sks-keyservers.net";
  else if (!strcmp (uri, "https://http-keys.gnupg.net;))
uri = "https://ha.pool.sks-keyservers.net;;
  else if (!strcmp (uri, "hkp://http-keys.gnupg.net"))
uri = "hkp://ha.pool.sks-keyservers.net";
  else if (!strcmp (uri, "http://http-keys.gnupg.net;))
uri = "http://ha.pool.sks-keyservers.net;;


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

37.191.231.105 (part of keyserver pool) redirects to ... unknown location?

[Mihai Moldovan]

Hi


Since I know that the keyserver maintainers follow this list, I wonder what
happened to 37.191.231.105, which is part of the keyserver pool?

It currently HTTP-301-redirects to https://analytics.sumptuouscapital.com/ -
which also means that requests to URLs like http://keys.gnupg.net will sometimes
redirect a user to that location.



Mihai



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

On 03/07/2019 16:55, Werner Koch wrote:
> And well, self-sigs-only is a less intrusive change than changing
> import-minimal.  If it breaks something it can easily be reverted by the
> user - a change to the semantics of import-minimal can't be reverted by
> the user.

Ah, yes, I had completely not considered that area of impact.

> "self-sigs-only" also better expresses what it does.  If you have a
> better name, let us know.

No, I think it's a good name.

Thanks for making the rationale of the design clear!

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 04/07/2019 03:29, Phil Pennock wrote:
> Depends upon the implementation.  I'm biased here, I wrote my own in
> Go back in 2016:  https://go.pennock.tech/fingerd/

Nice. I can't see corporate firewall admins buying it though. :-)

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

> On 4 Jul 2019, at 03:23, Ángel  wrote:
> 
> A point I don't like about the design of hagrid is that verification is
> performed by the server itself.
> Thus, it seems that if there were a reconciliation protocol between
> them, either entering into one of them would lead to all of them blindly
> trusting it, or the owner would need to validate a challenge for each
> keyserver to which it gets replicated.

Exactly. This is why I believe we need to separate the functions of “master” 
keystores (such as hagrid, keybase, WKD) from “caching” keystores such as SKS. 
The master (but not authoritative) keystores would provide IDs and third party 
sigs, at the cost of having to perform verification (email in the case of email 
IDs and domain in the case of server IDs). The caching keystores would 
synchronise, but only the primary keys. They would then spider the master 
keystores for the rest of the key info. 

There is no reason for the master keystores to publicly certify keys - their 
verification process is an antispam measure, not an attestation of identity. 
But we can’t do away with verifying entirely, because there is no other known 
way to prevent flooding. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 07/03/2019 10:19 PM, Mirimir wrote:
> Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd
> appreciate some advice about how to fix it.
> 
> I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome.
> Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7
> from pool.sks-keyservers.net, but that just timed out.
> 
> So I downloaded it via HTTPS. And it was ~60MB. I tried importing from
> the downloaded file, but that went nowhere. With 100% CPU.
> 
> So I got it from https://keybase.io/rjh and imported from clipboard in
> Enigmail Key Management. That worked just fine. So then I tried
> refreshing keys in Enigmail, leaving pool.sks-keyservers.net as the
> default keyserver. And that failed, complaining about no dirmngr. Then I
> tried refreshing keys with gpg in terminal, and got the same error about
> no dirmngr.
> 
> Then I deleted rjh's key, and got my own from Keybase, and imported it.
> But when I tried refreshing keys, I got the same error about no dirmngr.
> 
> So gpg must still work, because I can import and delete keys via
> Enigmail. But something seems borked about dirmngr. I guess that I'll
> try purging and reinstalling. Or is there a better fix?

Damn. Somehow dirmngr didn't get installed with Thunderbird and
Enigmail. How embarrassing. So now Enigmail does refresh my key.

But after importing rjh's key, refreshing in Enigmail fails:

| Downloading of keys failed
| gpg: keyserver receive failed: No data

I also tried in terminal:

| user@debian:~$ gpg --refresh-keys
| gpg: refreshing 2 keys from hkps://hkps.pool.sks-keyservers.net
| gpg: key ...: 22 signatures not checked due to missing keys
| gpg: key ...: "mirimir " not changed
| gpg: Total number processed: 1
| gpg:  unchanged: 1

Then I disabled rjh's key, and found that my key still refreshed
quickly. Using hkps.pool.sks-keyservers.net.

So that's good news, yes? Trying to refresh rjh's key failed, but it
failed quickly, and the attempt apparently didn't break anything.

> And yes, I should have tested everything first with a clean key, before
> messing with rjh's key. Is it likely that I borked dirmngr during the
> intital attempt to get it from pool.sks-keyservers.net?
> 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users