KeyserverTag
ActivePublic

Members

  • This project does not have any members.

Recent Activity

Oct 29 2018

werner triaged T4165: Dirmngr: Ipv6 causes network failure if Ipv6 can't be reached as High priority.

It actually tries several servers but we need to set a limit because we need to cope with longer timeouts. Do you suggest to toggle between v4 and v6 addresses? That is if a v6 address fails, first try the next v4 address and it that fails, another v6 address, etc.

Oct 29 2018, 9:41 AM · Keyserver, Feature Request, dirmngr

Oct 2 2018

werner added a comment to T4163: hkps://hkps.pool.sks-keyservers.net has to many bad servers to be a good default.

The problem is that the keyserver network is abused as free and
permanent data storage. We can't do much about it without larger
changes on the search capabilities of the keyservers. For more
information see the archives of the sks-devel list starting in July.

Oct 2 2018, 8:50 AM · gnupg, Keyserver

Oct 1 2018

aheinecke added a subtask for T4163: hkps://hkps.pool.sks-keyservers.net has to many bad servers to be a good default: T4165: Dirmngr: Ipv6 causes network failure if Ipv6 can't be reached.
Oct 1 2018, 2:39 PM · gnupg, Keyserver
aheinecke triaged T4163: hkps://hkps.pool.sks-keyservers.net has to many bad servers to be a good default as Normal priority.
Oct 1 2018, 10:24 AM · gnupg, Keyserver
aheinecke claimed T4163: hkps://hkps.pool.sks-keyservers.net has to many bad servers to be a good default.

Ok. I was not aware that HKPS should already have the highest quality.

Oct 1 2018, 10:23 AM · gnupg, Keyserver
kristianf added a comment to T4163: hkps://hkps.pool.sks-keyservers.net has to many bad servers to be a good default.

hkps pool really should be the most responsive, and it already requires clustered only servers for a couple of weeks to try to increase the responsiveness. Experience has shown that any keyserver with less than 3 nodes in a cluster should not be used towards end-users. But do you have any more debugging output as to the problem at hand?

Oct 1 2018, 10:19 AM · gnupg, Keyserver
aheinecke created T4163: hkps://hkps.pool.sks-keyservers.net has to many bad servers to be a good default.
Oct 1 2018, 9:40 AM · gnupg, Keyserver

Sep 11 2018

werner closed T2968: gpg --search: Connection closed in DNS as Resolved.

We assume that this has meanwhile been fixed.

Sep 11 2018, 10:34 AM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Aug 29 2018

werner added a project to T2968: gpg --search: Connection closed in DNS: Info Needed.

@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?

Aug 29 2018, 2:53 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Nov 19 2017

elonsatoshi added a comment to T2968: gpg --search: Connection closed in DNS.

You know... I think connman and DNS have something to do with this. Connman does some weird DNS thing. And it auto-generates /etc/resolv.conf to use localhost as the DNS server.

Nov 19 2017, 4:48 AM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Oct 24 2017

werner placed T2968: gpg --search: Connection closed in DNS up for grabs.
Oct 24 2017, 3:00 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Oct 20 2017

werner edited projects for T2968: gpg --search: Connection closed in DNS, added: gnupg (gpg22); removed gnupg (gpg21), gnupg.
Oct 20 2017, 1:48 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Sep 24 2017

kristianf added a watcher for Keyserver: kristianf.
Sep 24 2017, 6:46 PM
werner added a project to T3392: keyserver default should include pool onionbalance hkp://jirk5u4osbsr34t5.onion: Keyserver.
Sep 24 2017, 10:03 AM · Keyserver, Feature Request, dirmngr

Aug 27 2017

elonsatoshi added a comment to T2968: gpg --search: Connection closed in DNS.

Well, I'm able to reproduce this issue on Parabola. I was also get a different error when I turn off my vpn: `server indicated a failure```, but now I get the dns error again.

elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
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=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
elonsatoshi@tyger ~> sudo rc-service openvpn stop
[sudo] password for elonsatoshi: 
 * WARNING: openvpn is already stopped
elonsatoshi@tyger ~> pidof openvpn
elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
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=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
Aug 27 2017, 4:58 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Jun 23 2017

werner added a comment to T2968: gpg --search: Connection closed in DNS.

Any update on this?

Jun 23 2017, 5:11 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Mar 30 2017

admin created Keyserver.
Mar 30 2017, 6:42 PM

Mar 20 2017

werner updated subscribers of T2968: gpg --search: Connection closed in DNS.
Mar 20 2017, 2:55 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr
werner reassigned T2968: gpg --search: Connection closed in DNS from kardan to justus.
Mar 20 2017, 2:55 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Mar 16 2017

kardan added a comment to T2968: gpg --search: Connection closed in DNS.

I was able to reproduce it again. Maybe this bug depends on which keyserver in
the pool answers. The error is the same for Tor and non-Tor connections.

Mar 16 2017, 3:16 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr
kardan reopened T2968: gpg --search: Connection closed in DNS as "Open".
Mar 16 2017, 3:16 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr
kardan added a comment to T2968: gpg --search: Connection closed in DNS.

I don't know why, it is not repdroducible anymore.

Mar 16 2017, 7:27 AM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr
kardan closed T2968: gpg --search: Connection closed in DNS as Resolved.
Mar 16 2017, 7:27 AM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Feb 21 2017

dkg added a comment to T2968: gpg --search: Connection closed in DNS.

Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?

Feb 21 2017, 4:43 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Feb 19 2017

kardan added projects to T2968: gpg --search: Connection closed in DNS: dirmngr, Keyserver, gnupg, gnupg (gpg21), Debian, Bug Report.
Feb 19 2017, 8:51 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Dec 19 2016

baitisj renamed T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error" from Requesting HKPS service from non-HKPS gives "error searching keyserver: General error"; results in persistent failure state to Requesting HKPS service from non-HKPS gives "error searching keyserver: General error".
Dec 19 2016, 6:46 PM · Keyserver, gnupg
baitisj added a comment to T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error".

> $ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
> gpg: no keyserver known (use option --keyserver)
> gpg: keyserver search failed: No keyserver available
>
> WHAT?! I just specified --keyserver!!!??

Relax. You forgot the '.pool' in the url.

:facepalm: ... Apparently I need more coffee -- persistent failure state in user
encountered.

Sorry for the noise.

I do wonder about fault-tolerance, though, if a e.g. non-responsive host creeps
in to the pool.

At any rate, this is mainly a cosmetic issue at this point, and this bug report
probably contains sufficient information to help someone who "encounters" the
condition to resolve the protocol error quickly.

Dec 19 2016, 6:45 PM · Keyserver, gnupg
werner added a comment to T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error".

For the records, the suggested way to kill dirmngr is

gpgconf --kill dirmngr

this makes sure that dirmngr will not be started if it is not running.

Dec 19 2016, 6:23 PM · Keyserver, gnupg
justus closed T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error" as Invalid.
Dec 19 2016, 4:18 PM · Keyserver, gnupg
justus added a comment to T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error".

tl;dr: HKPS handler will die when used with non-HKPS hosts in a given pool.

I think dying is reasonable. Maybe it should return a nicer error
than 'general error' and it shouldn't take 10 seconds to figure out
the protocol error.

Using setup directions from
https://sks-keyservers.net/overview-of-pools.php I assumed that
configuring my GnuPG client to use ipv4.pool.sks-keyservers.net
would provide an appropriate response. It took me quite some time to
determine that HKPS is totally incompatible with the ipv4 (or other)
server pools.

This is further confused by the fact that an older version of the
GnuPG skeleton files which includes a clause with examples that mix
HKPS and hkp servers (skel may not necessarily be updated in a
user's directory):

Sorry about that. I think the current skeleton file is clearer on
this.

As a result, I kept encountering the errors reported in
T1792

I don't see a connection to this bug.

Here's a simple demonstration of the failure case

$ gpg2 --keyserver hkps://ipv4.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error

Contrast with:

$ gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: data source: https://mud.stack.nl:443
(1) NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>

 	  2048 bit RSA key 2071B08A33BD3F06, created: 2014-10-29, expires: 2020-10-30

PERSISTENT FAILURE CASE:
Now, once the failure condition is encountered, further queries FAIL:

$ pkill dirmngr

A nicer way to kill the dirmngr is:

  gpg-connect-agent --dirmngr 'killdirmngr' /bye

$ gpg2 --keyserver hkp://pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: error searching keyserver: No route to host
gpg: keyserver search failed: No route to host

This is strange, and looks like it should work. Works over here. Maybe it is
bad luck and you got a bad host from the roundrobin.

$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

WHAT?! I just specified --keyserver!!!??

Relax. You forgot the '.pool' in the url.

Let's see if this can be rectified with clearing the keyserver:

$ gpg-connect-agent --dirmngr keyserver
> keyserver --clear
OK

$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Likewise.

  1. Try this with other VALID --keyserver combinations. Bang head against wall. The ONLY command that seems to fix this persistent failure case: $ gpg2 --search-keys 2071B08A33BD3F06 Suddenly, I can use --keyserver again, after this.

I'm pretty sure you just messed up the urls.

Dec 19 2016, 4:18 PM · Keyserver, gnupg
justus removed a project from T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error": Bug Report.
Dec 19 2016, 4:18 PM · Keyserver, gnupg
justus claimed T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error".
Dec 19 2016, 11:37 AM · Keyserver, gnupg

Dec 13 2016

baitisj added projects to T2869: Requesting HKPS service from non-HKPS gives "error searching keyserver: General error": gnupg, Bug Report, Keyserver.
Dec 13 2016, 4:24 AM · Keyserver, gnupg

Jan 15 2016

werner closed T2109: Gpg2.1 http-proxy configuration from 2.0 leads to configuration error as Resolved.
Jan 15 2016, 1:28 PM · Keyserver, Bug Report, gnupg, gnupg (gpg21), gpg4win
werner removed a project from T2109: Gpg2.1 http-proxy configuration from 2.0 leads to configuration error: Testing.
Jan 15 2016, 1:28 PM · Keyserver, Bug Report, gnupg, gnupg (gpg21), gpg4win

Jan 7 2016

werner added a project to T2205: GnuPG does not detect damaged keys on import: Not A Bug.
Jan 7 2016, 4:02 PM · Not A Bug, Debian, Bug Report, gnupg
werner added a comment to T2205: GnuPG does not detect damaged keys on import.

Sorry, I can't see any problem here.

The "priotr-old" key is actually the newer key because an expiration date was
added to that copy of the key (2012-07-09) and that key has meanwhile expired.
Thus you can't encrypt using this key.

When you import the "piotr" key that is actually the same key but w/o the update
with the expiration date. Thus gpg does not chnage the exiting in key because
the existing key has a newer self-signature (where the expiration date is
stored) than the new key. So nothing changes, which is correct.

If you delete the .gnupg directory you don't have the newer key and by importing
the key w/o the expiration date you can encrypt to that key.

Jan 7 2016, 4:02 PM · Not A Bug, Debian, Bug Report, gnupg

Jan 6 2016

estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.

Jan 6 2016, 11:13 AM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Jan 6 2016, 11:13 AM · Not A Bug, Debian, Bug Report, gnupg

Jan 5 2016

werner added a comment to T2205: GnuPG does not detect damaged keys on import.

1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.

Jan 5 2016, 3:13 PM · Not A Bug, Debian, Bug Report, gnupg
werner lowered the priority of T2205: GnuPG does not detect damaged keys on import from Unbreak Now! to Normal.
Jan 5 2016, 3:13 PM · Not A Bug, Debian, Bug Report, gnupg

Dec 27 2015

estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Dec 27 2015, 5:51 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Dec 27 2015, 5:51 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/

Dec 27 2015, 5:50 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Dec 27 2015, 5:50 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added projects to T2205: GnuPG does not detect damaged keys on import: gnupg (gpg14), Keyserver, gnupg, Bug Report, Debian.
Dec 27 2015, 5:36 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb set Version to 1.4.12 on T2205: GnuPG does not detect damaged keys on import.
Dec 27 2015, 5:36 PM · Not A Bug, Debian, Bug Report, gnupg

Oct 8 2015

werner updated subscribers of T2109: Gpg2.1 http-proxy configuration from 2.0 leads to configuration error.
Oct 8 2015, 7:15 PM · Keyserver, Bug Report, gnupg, gnupg (gpg21), gpg4win
werner added a project to T2109: Gpg2.1 http-proxy configuration from 2.0 leads to configuration error: Testing.
Oct 8 2015, 7:15 PM · Keyserver, Bug Report, gnupg, gnupg (gpg21), gpg4win
werner added a comment to T2109: Gpg2.1 http-proxy configuration from 2.0 leads to configuration error.

Applied with commit ea079d2. Thanks.

Oct 8 2015, 7:15 PM · Keyserver, Bug Report, gnupg, gnupg (gpg21), gpg4win