Re: [Sks-devel] Another poison-key?

[Jason John Schwarz]

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 multiple versions of the key being merged?  

I have seen several rather odd keys lately.  The key for Daniel Austin (0xEBF54CD6472EFFFF) who operates pgpkeys.eu is appearing strange 

as  well.    When I look it up on my server (keyserver.insect.com) or pgp.pm it is full of trash in the display, but on his server the key is fine. 

I have tried removing the key and I just get the same key back with the issue.

Jason John Schwarz

Chief Technical Officer

MSC Inc

eMail: address@hidden

Phone: (910) 689.0557

              (800) 284.7872

Fax: (910) 689.0558

On Feb 4, 2019, at 11:41 AM, Kim Minh Kaplan <address@hidden> wrote:

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 interface being slow
randomly versus the SigAlarm on performance?

Yes, during the storing of the huge key, the server will not
answerother queries due to its single threaded and single query
conception.
My first thoughts regarding this setting:

1, SKS is not suited as a web interface so this point seems moot,
2, being slow (around 3 minutes) once to accept the key appears
betterthan being a little slow (around 1 minute) frequently,
3, alas as I mentioned earlier this is just pushing the problem ahead,
4, I believe the key has yet grown a bit further in the mean time.I.e.
somebody is actively hurting SKS :-(
--
Kim Minh.