[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] withdrawal of service:

From: Moritz Wirth
Subject: Re: [Sks-devel] withdrawal of service:
Date: Sun, 15 Jul 2018 09:57:04 +0200

Hi Tom,

I spend the night on the keydump - is now also running with hockeypuck (I did not test anything to be honest though ;)). I'll see if it runs stable (not sure if it is pool compatible) - version is 1.1.6.

A short write-up for installing this thing is already done - I can send the link if it works ;)

The server is only peering with my own instances right now - however it looks like recon has a problem with the filters of sks (which should not be a big deal)..

{filters do not match.\n\tlocal filters: [ yminsky.dedup yminsky.merge ]\n\tremote filters: [ yminsky.dedup  yminsky.merge ]} {remote rejected configuration}]" label="serve :11370"

Best regards,


Am 15.07.18 um 04:31 schrieb Tom at FlowCrypt:
> Does anyone in the pool run hockeypuck? How compatible is its recon with others running sks-keyserver?

However, it was kicked out of the pool because "SKS version < 1.1.6" as per

It does seem to be syncing well - key diff 1,385 looks great to me even compared to servers that are in the pool.

I'm adding Robert in copy in case he's able to share his experience running the Hockeypuck server. Robert, if this email can reach you, We'd be interested to know how is the server coping with recent issues that were affecting the SKS network? How stable do you find Hockeypuck overall, how much dev-ops do you need to do?

On Sun, Jul 15, 2018 at 1:21 AM, Haw Loeung <address@hidden> wrote:
On Sun, Jul 15, 2018 at 11:17:20AM +1000, Haw Loeung wrote:
> On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote:
> > I am still willing to help with possible upgrades and/or
> > replacements for the SKS network. At this point I have come to
> > believe that a minimal network containing only key material, SBINDs
> > and revocations (no id packets, no third party sigs) is the absolute
> > maximum functionality we can hope to sustain in the long term. And
> > for this to be bulletproof, all such material must be
> > cryptographically verified (otherwise people could just create
> > “random” key material containing arbitrary data).
> If it helps others, we have a patched SKS packaged to exclude the bad
> key (one of them at least)[1]. A couple of others in my team did all
> the work so I can't comment on the details.

I should also add, you'll then need to drop the key from the DB with:

$ sks drop 8C070D00D81E934B3C79247175E6B4BC



Sks-devel mailing list

Sks-devel mailing list

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]