I'm also seeing this behavior when there is something wrong with the reverse DNS
lookups. For example:

Nov 08 10:54:36 alice dirmngr[1714]: handler for fd 5 started
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> # Home: /home/dkg/.gnupg
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> # Config:
/home/dkg/.gnupg/dirmngr.conf
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK Dirmngr 2.1.15 at your
service
Nov 08 10:54:36 alice dirmngr[1714]: connection from process 7623 (1000:1000)
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- GETINFO version
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> D 2.1.15
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- KEYSERVER
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> S KEYSERVER
hkps://hkps.pool.sks-keyservers.net
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- KS_GET --
0x2E8DD26C53F1197DDF403E6118E667F1EB8AF314
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L3: ASSERT:
mpi.c[_gnutls_x509_read_uint]:246
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]:
Allocating epoch #0
Nov 08 10:54:36 alice dirmngr[1714]: can't connect to 'oteiza.siccegge.de':
Invalid argument
Nov 08 10:54:36 alice dirmngr[1714]: error connecting to
'https://oteiza.siccegge.de:443': Invalid argument
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]: Start
of epoch cleanup
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]: End of
epoch cleanup
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]: Epoch
#0 freed
Nov 08 10:54:36 alice dirmngr[1714]: command 'KS_GET' failed: Invalid argument
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> ERR 167804976 Invalid
argument <Dirmngr>
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- BYE
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK closing connection
Nov 08 10:54:36 alice dirmngr[1714]: handler for fd 5 terminated

This appears to be because the pool included 92.43.111.21, which has a PTR of
oteiza.siccegge.de, despite the fact that oteiza.siccegge.de has no A record.

There is no reason for dirmngr to be talking to the member of the pool by its
hostname, anyway -- it should make the connection by IP address, with the TLS
SNI set to the pool name.

The TCP specs demand something different and it is not the duty of dirmngr to do
something about it. You have ths behavour with all TCP connections and that is
also what makes TCP a reliable connection.

On Linux if would be possible to reduce the intial SYN retries but that is not
portable.

For --auto-key-retrieve I already implemented a --quick parameter in gpg to
advise dirmngr to give up earlier. The dirmngr side has not been implemented,
though.

There are two related problem, which are only related to the key listing:

We do not indicate in the output whether a user id is valid. Instead we show
the validity info from the trustdb regardless of the time conflict. Ths could
be changed for example to show "[invalid]" instead of "[full]". This covers all
cases which render a user id invalid and not just a time conflict.

Due to the invalid user id the key is also not valid but we do not indicate this
either.

By using --ignore-time-conflict the problem goes away but that is not a
solution. We need to properly indicate when a user id or Key is not valid even
when not doing --check-sigs. One way to do this would be to use the same tags
we use with --checks-sigs with -k for the used self-signatures. That
information is readily available.

Fixed in 5840353d8bbcd9e75374f3bdb2547ffa7bbea897.

Neal, that is exactly what happens, thanks for writing it out.

Werner, yes, it also affects gpg1:

% faketime "2016-07-01" g10/gpg --edit foo
gpg (GnuPG) 1.4.22-beta2; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 0707DEE4 was created 29 seconds in the future (time warp or clock problem)

pub 2048R/0707DEE4 created: 2016-06-30 expires: never usage: SCEA

trust: unknown       validity: unknown

[ unknown] (1). foo bar <foo@example.org>
% faketime "2016-07-02" g10/gpg --edit foo
gpg (GnuPG) 1.4.22-beta2; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!

pub 2048R/0707DEE4 created: 2016-06-30 expires: 2016-09-28 usage: C

trust: unknown       validity: unknown

[ unknown] (1). foo bar <foo@example.org>

Because it took me a while to understand what is actually going wrong, a summary
of the problem: if we get an error such as "key 517912BA66E730CA was created 78
seconds in the future", then the key's flags will be wrong (below: SCEA instead
of C) and the expiration date will not be printed.

Interesting stuff. My solution wouyld be to switch to the gtk pinetry, but I'll
take care care of your patch tomorrow.

D386: 903_0001-gnome3-Fall-back-to-curses-if-screensaver-is-locked.patch

Attached is a patch to check for locked screensaver and fall back to curses if
detected.

Perhaps gcr needs to refuse to prompt in the event that the graphical session is
known-idle/locked (in screensaver mode, whatever). Then the pinentry could know
to fall back to the tty because of the locked screen.

I just spent a while trying to research this, and i'm afraid that the code i've
written to detect whether gcr is available does nothing to detect whether the
screen is currently locked.

Furthermore, when "getpin" is called against a dbus session that is locked, it
immediately returns with a "Cancelled" message, in a way that is pretty
difficult to diagnose.

However, it looks like i can query the gnome screensaver via dbus to see whether
the screen is locked. From the command line, that's:

dbus-send --print-reply=literal --session --dest=org.gnome.ScreenSaver

/org/gnome/ScreenSaver org.gnome.ScreenSaver.GetActive

which returns a boolean true or false depending on whether the screen is locked.

We'd just need to translate it into GDBus, i think, perhaps using something
higher-level like g_dbus_connection_call(), or something lower-level, like
g_dbus_connection_send_message_with_reply() (or their synchronous variants):

file:///usr/share/doc/libglib2.0-doc/gio/GDBusConnection.html#g-dbus-connection-call
file:///usr/share/doc/libglib2.0-doc/gio/GDBusConnection.html#g-dbus-connection-send-message-with-reply

In your example, i don't think updatestartuptty is necessary for text-mode
prompting -- the "gpg --decrypt …" process will be able to detect which tty it
is connected to and pass it to the agent.

But the question here has to do with graphical consoles as well, and i don't
think there's a clear answer yet.

There are two X11 graphical sessions in the example:

a) the local machine's graphical console, where the user is currently sitting,
running ssh *to* the remote machine
b) the remote machine's graphical console, where the user is logged in, but idle

There are also three kinds of pinentry user-attention-getting mechanisms:

0) terminal

1. X11
2. d-bus

finally, i'll note that there are (at least) two d-bus user sessions running in
this example: on the remote host and on the local host. I'm assuming in this
example that the user has a single shared d-bus session across all logins on the
computer (this is the dbus-user-session model, which is well-aligned with the
gpg-agent standard-socket model, where there is one running process per user per
machine)

Since "ssh -X remote" forwards the X11 session but not the d-bus session, any
d-bus-based pinentry (like pinentry-gnome3) will connect to the d-bus session on
the remote machine. But the d-bus session on the remote machine is *also*
connected to the remote graphical (X11) console.

pinentry on the remote machine has two choices:

x) talk to the d-bus session it is connected to (which will trigger a prompt on
the remote graphical console, or
y) fall back to curses

If it chooses (x) then the user is unlikely to see the prompt (they're not
sitting in front of that graphical console). But it's not clear how to
distinguish the situation from normal use in order to choose (y).

Perhaps gcr needs to refuse to prompt in the event that the graphical session is
known-idle/locked (in screensaver mode, whatever). Then the pinentry could know
to fall back to the tty because of the locked screen. If it does that, then the
error case (where the graphical prompt is shown on the idle session) is limited
to situations where the user left the remote graphical console unlocked. I
don't know whether we can get gcr to report that successfully or not, though.

They need to run

gpg-connect-agent updatestartuptty /bye

to tell gpg-agent where to open the Pinentry. Depending on how they log in
either a curses or GUI Pinentry will be shown. I.e.

  ssh -X example.org
  gpg-connect-agent updatestartuptty /bye
  gpg --decrypt ....

shows a GUI Pinentry. If -X is not used the curses pinentry comes up.

Not quite true. As soon as a blocking system cal is used another thread is
scheduled. Long running operations like generating a new key may indeed take a
long time and inhibit other threads from running. They run long becuase they
need to collect entropy. Having other threads running at that time would not
really be helpful. Using gpg-agent for more than a decade now, I never made
that experience.

The more likely reason for the problem is that no working pinentry is installed
and the boths threads are waiting for the pinentry (pinentry access is obviously
serialized).

We need a log file from gpg-agent: Out this into gpg-agent.conf

log-file /tmp/foo/agent.log
debug 1024
verbose

and restart the agent.

In gpg-agent, only a single thread of execution runs at a time. So it is
entirely possible that what you are describing happens. For us to debug it, we
need a very concrete example. Please provide us with the command line(s) that
you are using to decrypt the files in parallel. Also, please list the keys. (A
small guess: you are using 16k RSA.)

Can you test this also with 1.4 (iirc, Debian has a tool to fake the sytsem time
for a process)

Fixed with commit df08a0c. Thanks.

I just tried:

$ g10/gpg --encrypt -r samuel </dev/urandom >/dev/null

As expected, the gpg process eats a lot of cpu time, and I can spawn two of them
just fine. This works with both my build as well as gpg from Debian testing.

I once thought about making yatm emit org mode. Wdyt?

I'm closing this bug due to inactivity. Feel free to reopen it with more
information.

Fixed in 60ad1a7f37ffc10e601e69a3e2d2bb14af510257.

Hi Andre,

Thanks for following up. I seem to be able to reproduce the first part of your
issue here and I'm looking in to it.

Thanks,
Neal

Sry I accidentally posted an incomplete message with T2812 (aheinecke on Oct 31 2016, 05:08 PM / Roundup) (I used itsalltext
and postet a wrong version).

I wanted to write:

On the command line it's looking good. The second keylist is also down to 5
seconds on Windows.

But used from gpgme it still takes about a minute. If you add --with-colons and
slow down system calls by using strace you can also see this on GNU/Linux:

~> time strace gpg2 --no-default-keyring \

--keyring /usr/share/keyrings/debian-keyring.gpg \
--no-auto-check-trustdb --trust-model pgp \
--with-colons -k >/dev/null 2>&1

2.26s user 0.40s system 102% cpu 2.601 total
~> time strace gpg2 --no-default-keyring \

--keyring /usr/share/keyrings/debian-keyring.gpg \
--no-auto-check-trustdb --trust-model tofu \
--with-colons -k >/dev/null 2>&1

21.43s user 24.47s system 108% cpu 42.451 total

On Windows it's:

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--trust-model tofu --list-keys > $null
}
TotalSeconds : 7.0945596

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--with-colons --trust-model tofu --lis
t-keys > $null }
TotalSeconds : 56.0914993

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--with-colons --trust-model pgp --list
-keys > $null }
TotalSeconds : 1.4855689

I'm also still seeing decryption blocked on Windows while a keylist
--with-colons runs.

I wonder if we should generally check out performance of reading the keyring on
Windows
mabye we could genrally improve it so that it's better cached by Windows.

No both have unknown trust.

7a634e48b13c5d5d295b8fed9b429e1b2109a333 should fix the contention issue.
Please let me know if you are still having issues.

(see on-list discussion at
https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056978.html)

eec365a & 614ca00 fixed the performance issue for me here.

us@chu:~/neal/work/gpg/test (GnuPGTest)$ rm tofu.db
us@chu:~/neal/work/gpg/test (GnuPGTest)$ time gpg --no-default-keyring --keyring
/usr/share/keyrings/debian-keyring.gpg -k >/dev/null
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m45.569s
user 0m34.316s
sys 0m10.872s
us@chu:~/neal/work/gpg/test (GnuPGTest)$ time gpg --no-default-keyring --keyring
/usr/share/keyrings/debian-keyring.gpg -k >/dev/null
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m2.306s
user 0m2.284s
sys 0m0.020s
us@chu:~/neal/work/gpg/test (GnuPGTest)$ time gpg --no-auto-check-trustdb
--trust-model pgp --no-default-keyring --keyring
/usr/share/keyrings/debian-keyring.gpg -k >/dev/null
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: please do a --check-trustdb
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m2.261s
user 0m2.248s
sys 0m0.012s

The first time a key is encountered, we need to do a number of checks that
require reading its keyblock. These include checking whether the key is signed
by an ultimately trusted key. So, this cost is pretty much unavoidable, but it
should be a one time thing.

That other gpg processes stall is surprising, and I will investigate this. I
went to a fair amount of trouble to make sure that that doesn't happen in practice.

That the cost is higher on subsequent runs is a bit disconcerting. I will also
investigate this.

Are the two keys that you testing ultimately trusted? If so, then their
validity is good independent of their TOFU policy.

It is a bit unfortunate that the TOFU policy doesn't show this. I will try and
fix this, but it is a bit complicated because when a key's ownertrust is changed
(or a signature is added, etc.), the tofu db is not updated.

Duplicate of T2341

Thanks for your report,

This was already fixed in T2341

Which is currently not yet released. I'm marking this issue here as released
with superseder (duplicate) to keep the tracker clean.

Fixed with: 5579c4b4f

The code was overcomplicated as it was based on a bad assumption about Outlook
which I never questioned myself. We now properly encrypt in the send event so no
need for ticklish threads / callbacks.

Well, I can only say right now that since upgrading to Ubuntu 16.10, the gpg
command now is gnupg v2 by default, and my parallel decryption using
multiple gpg processes does not work any more. "Not working" means there is
only one gpg-agent processes using any CPU at all, and it is using only one
CPU core at 100% for a very long time. Nothing else pops up in top regarding
CPU usage. 75% of the CPU cores remain idle. So my guess is that the gpg-
agent does all of the work and therefore prevents multiple parallel
executions. My conclusions seem pretty obvious to me. But maybe it has to do
with stuff done by some downstream debian or Ubuntu packagers?

It seems that it's related to ADNS.
I fixed error handling in the commits of 8a9341b and 6f1d812, so that correct
error from adns_synchronous will be logged.
I mean, the error message of "DNS query failed: System error w/o errno" will be
improved with correct error value.

I'm trying to understand this, but I'm not seeing it.

Here's the test i did. While recording all traffic from my machine on port 53
(the dns port), i ran:

    GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr

That interactive session looked like this:

> getinfo dnsinfo
OK - ADNS w/o Tor support
> getinfo tor
dirmngr[11713.1]: command 'GETINFO' failed: False
ERR 167772416 False <Dirmngr> - Tor mode is NOT enabled
> keyserver --clear
OK
> keyserver hkps://hkps.pool.sks-keyservers.net
OK
> keyserver --resolve hkps://hkps.pool.sks-keyservers.net
dirmngr[11713.1]: DNS query returned an error or no records: No such domain

(nxdomain)

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'bone.digitalis.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'ip-209-135-211-141.ragingwire.net'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'gpg.nebrwesleyan.edu'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'host-37-191-220-247.lynet.no'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'cryptonomicon.mit.edu'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'zimmerman.mayfirst.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'sks.srv.dumain.com'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'b4ckbone.de'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'sks.spodhuis.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'oteiza.siccegge.de'

    S # https://cryptonomicon.mit.edu:443
    OK
    > keyserver --hosttable
    S # hosttable (idx, ipv6, ipv4, dead, name, time):
    S #   0       hkps.pool.sks-keyservers.net
    S #   .   --> 8 1 5* 3 4 2 10 9 7 6
    S #   1   4   bone.digitalis.org v4=212.12.48.27
    S #   2   4   ip-209-135-211-141.ragingwire.net v4=209.135.211.141
    S #   3   4   gpg.nebrwesleyan.edu v4=192.94.109.73
    S #   4   4   host-37-191-220-247.lynet.no v4=37.191.220.247
    S #   5   4   cryptonomicon.mit.edu v4=18.9.60.141
    S #   6   4   zimmerman.mayfirst.org v4=216.66.15.2
    S #   7   4   sks.srv.dumain.com v4=85.119.82.209
    S #   8   4   b4ckbone.de v4=193.164.133.100
    S #   9   4   sks.spodhuis.org v4=94.142.242.225
    S #  10   4   oteiza.siccegge.de v4=92.43.111.21
    OK
    >

So, the SRV lookup did indeed fail, but subsequent queries succeeded.

I've attached a pcapng file of the network traffic sent and received from the
described test.

The textual version of the traffic is:

query 0x311f SRV _hkp._tcp.hkps.pool.sks-keyservers.net
query response 0x311f No such name SRV

_hkp._tcp.hkps.pool.sks-keyservers.net SOA ns2.kfwebs.net

query 0x3120 A hkps.pool.sks-keyservers.net
query response 0x3120 A hkps.pool.sks-keyservers.net A 92.43.111.21 A

94.142.242.225 A 193.164.133.100 A 85.119.82.209 A 216.66.15.2 A 18.9.60.141 A
37.191.220.247 A 192.94.109.73 A 209.135.211.141 A 212.12.48.27

query 0xbd61 PTR 27.48.12.212.in-addr.arpa
query response 0xbd61 PTR 27.48.12.212.in-addr.arpa PTR bone.digitalis.org
query 0x384a PTR 141.211.135.209.in-addr.arpa
query response 0x384a PTR 141.211.135.209.in-addr.arpa PTR

ip-209-135-211-141.ragingwire.net

query 0xb36e PTR 73.109.94.192.in-addr.arpa
query response 0xb36e PTR 73.109.94.192.in-addr.arpa PTR gpg.nebrwesleyan.edu
query 0xcac3 PTR 247.220.191.37.in-addr.arpa
query response 0xcac3 PTR 247.220.191.37.in-addr.arpa PTR

host-37-191-220-247.lynet.no

query 0xd28b PTR 141.60.9.18.in-addr.arpa
query response 0xd28b PTR 141.60.9.18.in-addr.arpa PTR cryptonomicon.mit.edu
query 0x4be9 PTR 2.15.66.216.in-addr.arpa
query response 0x4be9 PTR 2.15.66.216.in-addr.arpa CNAME

2.0-27.15.66.216.in-addr.arpa PTR zimmerman.mayfirst.org PTR zimmermann.mayfirst.org

query 0x823b PTR 209.82.119.85.in-addr.arpa
query response 0x823b PTR 209.82.119.85.in-addr.arpa PTR sks.srv.dumain.com
query 0x3b0c PTR 100.133.164.193.in-addr.arpa
query response 0x3b0c PTR 100.133.164.193.in-addr.arpa PTR b4ckbone.de
query 0x9600 PTR 225.242.142.94.in-addr.arpa
query response 0x9600 PTR 225.242.142.94.in-addr.arpa PTR sks.spodhuis.org
query 0xed36 PTR 21.111.43.92.in-addr.arpa
query response 0xed36 PTR 21.111.43.92.in-addr.arpa PTR oteiza.siccegge.de

Under GNU/Linux you can compare the strace output to see that there is a problem
even if it's quick because it is cached:

~> time strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 |wc -l
33383
strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 1.04s user 0.45s
system 104% cpu 1.433 total
wc -l 0.02s user 0.16s system 12% cpu 1.433 total

~> time strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 |wc -l
558528
strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 9.60s user 8.47s
system 106% cpu 17.022 total
wc -l 0.60s user 2.34s system 17% cpu 17.022 total

This is with my normal pubring that contains 790 public keys.

Now that gnupg v2 is using gpg-agent for all of the hard work,

It isn't. The agent merely decrypts the session key. gpg then decrypts the
actual data with the symmetric cipher.

and gpg-agent either gets locked

It isn't.

or isn't parallelized,

It is.

this does not work any more.

Can you please be more specific?

We are waiting for Plusserver or one of their sub-companies to tell us how to
proceeed.

Okay, we can then add the code to dirmngr.

The README describes that this is a one time migration and that is a Good Thing.
Anything else means the addition of additional code and surprises for 2.1 using
applications by keys suddenly appearing.

The migration code is there to help the majority of users and not to help
speical use cases.

Those who really want to create new keys with 1.4 can use the standard way of
exporting and importing secret keys.

A year later on a new computer I had to troubleshoot this problem again, and
found my own bug report. So I am including the patch this time. Please consider
including the proposed change (or some other fix) into mainstream.

D320: 895_0001-Let-other-processes-use-OpenPGP-card-over-pcscd.patch

thanks, that seems to have resolved the problem in my tests.

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

There are two http links left on the page. One (drm.info) is unfortunately
unavailable over https. The other (openit.de) seems to no longer exist, as the
company has merged with another one and is only a forward to plusserver. Probably
that simply should be changed to https://www.plusserver.com/ (and maybe the logo
as well).

It seems to be solved now but see the comment in
2f7d4c3 agent: Move inotify code to common and improve it.