I do have a proxy in front of SKS, but it impacts queries from GPG as well
during the timeout. I guess the hope is that the sum of the outages
under the higher timeout is less than the sum of the outages under the lower
timeout with the alarm.
I wonder if we have a situation where there are mu
Jason John Schwarz wrote:
> I pushed my command_timeout up to 180 seconds per Kim's recommendation, but
> that seems to cause the web interface to be very sluggish
> during the period of key loads. I assume that is because the single thread
> is busy. Any thoughts the trade off of the web inte
Hi
On 04/02/2019 11:35, Jason John Schwarz wrote:
> I pushed my command_timeout up to 180 seconds per Kim's recommendation, but
> that seems to cause the web interface to be very sluggish
> during the period of key loads. I assume that is because the single thread
> is busy. Any thoughts the t
I pushed my command_timeout up to 180 seconds per Kim's recommendation, but
that seems to cause the web interface to be very sluggish
during the period of key loads. I assume that is because the single thread is
busy. Any thoughts the trade off of the web interface being slow
randomly versus th
Martin Dobrev writes:
> 2019-01-29 14:20:05 1 hashes recovered from
> 2019-01-29 14:20:05 7594FE72B3E93A0350D9950B926F81A7
> 2019-01-29 14:20:11 1 keys found
> 2019-01-29 14:20:16 Requesting 1 missing keys from [188.138.x.x]:23371>, starting with 7594FE72B3E93A0350D9950B926F81A7
> 2019-01-29
> 2019-01-29 14:21:22 Adding hash 7594FE72B3E93A0350D9950B926F81A7
> 2019-01-29 14:21:22 Del'ng hash A3875A8B77A3ABADE2B855A8FCABC73D
> 2019-01-29 14:22:29 add_keys_merge failed: Eventloop.SigAlarm
> 2019-01-29 14:22:38 Key addition failed: Eventloop.SigAlarm
>
> My best guess is that this key has
Hi,
I'm looking at my server logs and there is a pattern within:
2019-01-29 14:16:55 Requesting 1 missing keys from , starting with 7594FE72B3E93A0350D9950B926F81A7
2019-01-29 14:17:31 1 keys received
2019-01-29 14:17:58 Applying 2 changes
2019-01-29 14:17:58 Adding hash 7594FE72B3E93A0350D9950B9
Thanks!
Yeah, I know that is not a solution.
Looking at the code, it seems "reasonable" to add keys to the blacklist...
so I guess I will check everyday for problematic keys, and if I find any I
will be able to ban them from my SKS server (and I will notify the list
with the keys, as I guess I won
Ok, so that was created with my program:
https://gitlab.com/yegortimoshenko/sks-exploits/blob/807ca89c0c2192ccb33d908ec2974779735805d8/sks-fake-uid/main.go#L15
Relevant issue:
https://bitbucket.org/skskeyserver/sks-keyserver/issues/60
> I know it is not a solution, but... is there any way to
> bl
I am receiving lots of request for key: 0x69D2EAD9
http://pgp.librelabucm.org/pks/lookup?search=0x69D2EAD9&fingerprint=on&op=index
And, as it turns out, when I have an error and I clic on the browser on
"View page source", I can see part of the key text is:
Do not use SKS keyserver sites (no val
PM brent s. wrote:
> well, that's the issue - hkp won't pull it, gpg won't pull it either.
>
> anyone know of a way to dump/extract a specific key from the SKS DB?
> i'd imagine there'd be a bdb way to do it but i'm not that old.
I've just wrote a short snippet to pull out data directly from Berk
On 18/01/2019 11:17, Simon Lange wrote:
> Am 18.01.2019 11:01, schrieb Andrew Gallagher:
>> On 18/01/2019 06:09, Gabor Kiss wrote:
>>> Is "... while gossip disabled. Ignoring." is normal?
>>
>> Yes. SKS is single-threaded, so while it is in the middle of a task it
>> politely ignores incoming netwo
Am 18.01.2019 11:01, schrieb Andrew Gallagher:
On 18/01/2019 06:09, Gabor Kiss wrote:
Is "... while gossip disabled. Ignoring." is normal?
Yes. SKS is single-threaded, so while it is in the middle of a task it
politely ignores incoming network requests.
And how do we tell sks to use more tha
On 18/01/2019 06:09, Gabor Kiss wrote:
> Is "... while gossip disabled. Ignoring." is normal?
Yes. SKS is single-threaded, so while it is in the middle of a task it
politely ignores incoming network requests.
--
Andrew Gallagher
signature.asc
Description: OpenPGP digital signature
___
> i noticed a key, which, whenever one of my peers tries to send it to me, is
> failing and causing unstable enlistment in the sks pool list.
My typical logs in the same time:
> Jan 14 13:54:08 atlas sks[17917]: 2019-01-14 13:54:08 Requesting 100 missing
> keys from , starting with
> 030E4ECA584F
On 1/14/19 10:06 AM, Yegor Timoshenko wrote:
>> hrm.. yeah, looks malformatted.
>>
>> "Error handling request: 128-bit v3 fingerprints not
>> implemented"
>>
>> https://bugs.launchpad.net/launchpad/+bug/144435
>> https://bugs.launchpad.net/launchpad/+bug/4746
>
> Could you upload the key somewhere
> hrm.. yeah, looks malformatted.
>
> "Error handling request: 128-bit v3 fingerprints not
> implemented"
>
> https://bugs.launchpad.net/launchpad/+bug/144435
> https://bugs.launchpad.net/launchpad/+bug/4746
Could you upload the key somewhere and link to it?__
On 1/14/19 9:35 AM, Simon Lange wrote:
> Hi,
>
> i noticed a key, which, whenever one of my peers tries to send it to me,
> is failing and causing unstable enlistment in the sks pool list.
>
> Jan 14 06:48:05 atlas sks[17917]: 2019-01-14 06:48:05 Requesting 100
> missing keys from , starting with
Hi,
i noticed a key, which, whenever one of my peers tries to send it to me,
is failing and causing unstable enlistment in the sks pool list.
Jan 14 06:48:05 atlas sks[17917]: 2019-01-14 06:48:05 Requesting 100
missing keys from , starting with
030E4ECA584FC3298423CA5B0CB7855C
Jan 14 08:51:5
19 matches
Mail list logo
