Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Moritz Wirth]

Hi Tom,

I spend the night on the keydump - keys.flanga.io 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,

Moritz

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?

Yes, here is one: http://keyserver.snt.utwente.nl

(see https://sks-keyservers.net/status/ and http://keyserver.snt.utwente.nl:11371/pks/lookup?op=stats ) 

However, it was kicked out of the pool because "SKS version < 1.1.6" as per https://sks-keyservers.net/status/ks-status.php?server=keyserver.snt.utwente.nl

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


Regards,

Haw

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc
Description: OpenPGP digital signature