sks-devel
[Top][All Lists]
Advanced

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

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


From: Tom at FlowCrypt
Subject: Re: [Sks-devel] withdrawal of service: sks.spodhuis.org
Date: Sun, 15 Jul 2018 02:31:15 +0000

> 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



reply via email to

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