Another poison-key?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Another poison-key?

Martin Dobrev
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 <ADDR_INET
[188.138.x.x]:23371>, 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 7594FE72B3E93A0350D9950B926F81A7
2019-01-29 14:17:58 Del'ng hash A3875A8B77A3ABADE2B855A8FCABC73D
2019-01-29 14:19:11 add_keys_merge failed: Eventloop.SigAlarm
2019-01-29 14:19:20 Key addition failed: Eventloop.SigAlarm
2019-01-29 14:20:05 1 hashes recovered from <ADDR_INET [188.138.x.x]:23371>
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 <ADDR_INET
[188.138.x.x]:23371>, starting with 7594FE72B3E93A0350D9950B926F81A7
2019-01-29 14:20:54 1 keys received
2019-01-29 14:21:22 Applying 2 changes
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 been poisoned. Do you experience
similar issues? All my server nodes (7+ in total) are suffering atm.

Kind regards,
Martin dobrev


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

pEpkey.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another poison-key?

Gabor Kiss
> 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 been poisoned. Do you experience
> similar issues?

Negative.

Gabor

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another poison-key?

Kim Minh Kaplan-2
In reply to this post by Martin Dobrev
Martin Dobrev writes:

> 2019-01-29 14:20:05 1 hashes recovered from <ADDR_INET [188.138.x.x]:23371>
> 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 <ADDR_INET
> [188.138.x.x]:23371>, starting with 7594FE72B3E93A0350D9950B926F81A7
> 2019-01-29 14:20:54 1 keys received
> 2019-01-29 14:21:22 Applying 2 changes
> 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 been poisoned. Do you experience
> similar issues? All my server nodes (7+ in total) are suffering atm.

This issue also reached my server. That prompted me to investigate. It
was caused by a huge key (34MB) that was taking to long to store in the
database. At first I thought that increasing wserver_timeout would allow
the key in. It turns out to be the wrong knob: increasing command_timeout
did it.

Of course I realize this is merely sweeping the real issue under the
carpet. I just hope this will allow us to sustain the network some more.

Kim Minh.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another poison-key?

Jason John Schwarz
In reply to this post by Martin Dobrev
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?

Jason John Schwarz
eMail: [hidden email]



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another poison-key?

Martin Dobrev
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 trade off of the web interface being slow
randomly versus the SigAlarm on performance?

Jason John Schwarz
eMail: [hidden email]

I've pushed mine to 600. Yes, I agree, there is a trade off but as long as you have some caching layer(s) in front things are a bit more reliable. I'm actually planning to write a blog article and dump all my findings so far regarding operating a SKS cluster.

Regards,
Martin Dobrev



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

pEpkey.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another poison-key?

Kim Minh Kaplan
In reply to this post by Jason John Schwarz
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.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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

Phone: (910) 689.0557
              (800) 284.7872
Fax: (910) 689.0558



On Feb 4, 2019, at 11:41 AM, Kim Minh Kaplan <[hidden email]> 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.


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel