User Details
- User Since
- Mar 27 2017, 4:47 PM (394 w, 1 d)
- Availability
- Available
Apr 23 2019
For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches
Feb 9 2019
So, the keyserver operator had thrown in a hockeypuck server in the pool, causing this.. While the keyserver remains in the exclude list until confirmation it has been resolved, that explains the behavior and it has been made clear that separate software needs to use different names in the future.
Oct 9 2018
I believe this would be a good improvement in user experience
Oct 1 2018
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?
May 15 2018
Feb 1 2018
The patch is available in our downstream bugtracker as attachment to https://bugs.gentoo.org/646194
Sep 24 2017
Sep 22 2017
Thanks, that is interesting info, I need to look into that.
Sep 21 2017
I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.
Aug 14 2017
Jul 24 2017
I'm not sure if this post ever made it into a bug report, but has master been tested with tiling WM like awesome to see if issue is fixed? https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032608.html (if not I'm sure robbat2 is helpful enough with that if picking up the thread)
Jul 23 2017
as a quick fix something like the attached seems to avoid the immediate issue{F166535}
Jun 26 2017
Jun 23 2017
Issue seems to be gone in gpg (GnuPG) 2.1.22-beta75
Additional info: I tried setting up a reproducer without using a smartcard, and it fails with no secret key similar to earlier versions
Jun 19 2017
Sep 1 2016
How about _pgpkey-http._tcp. record?
Apr 23 2016
The downstream issue does not persist in gcc 4.9.3 but triggers for 4.8.5
Fwiw we're tracking this downstream as "dev-libs/libgcrypt-1.7.0: impossible
constraints on 'asm' operand" - https://bugs.gentoo.org/show_bug.cgi?id=580270
Dec 19 2015
Thanks, I can confirm that this solves it.
Dec 15 2015
Nov 18 2015
As an additional point, the client max body size in nginx defaults to 1 MiB[0].
Currently no checking is done for larger request bodies for inclusion in the
keyserver pools. Apache does not have such a limit by default.
Reference:
[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
Oct 2 2015
looks good to me
Thanks, but I'm afraid that's not sufficient; the issue of the whitespace after
have_qt5_libs still exists after that commit for bash.
See the following test case: $ cat ./test.sh
#!/bin/bash
have_qt5_libs="no";
echo ${have_qt5_libs}
have_qt5_libs2 = "no";
echo ${have_qt5_libs2}
$ ./test.sh
no
./test.sh: line 5: have_qt5_libs2: command not found
The good news is that besides this buglet I've now pushed the updated revision
to our testing repository and have yet to get any bug reports. The patch I've
pushed is
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/pinentry/files/pinentry-0.9.6-add-disable-pinentry-qt5-option.patch#n38
which doesn't experience this issue.
Sep 29 2015
"+ have_qt5_libs = no;" result in command not found issues in configure so I
changed this to "+ have_qt5_libs="no";".
I've done some preliminary packaging tests and things seems to be working as
expected, will give it some more local testing before pushing it onto users in
testing
Sep 25 2015
Thank you, that is exactly the kind of mechanism I was looking for. I'll give it
a try to packaging over the next few days.