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