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 <haw.loe...@canonical.com
> <mailto:haw.loe...@canonical.com>> 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
> Sks-devel@nongnu.org <mailto:Sks-devel@nongnu.org>
> https://lists.nongnu.org/mailman/listinfo/sks-devel
> <https://lists.nongnu.org/mailman/listinfo/sks-devel>
>
>
>
>
> _______________________________________________
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
