I concur with the rest of the sentiment, I think its time to start accepting HP as a replacement for SKS.. If the sks-pool will not recognize the value of HP servers I suppose our only recourse is to fake it for the time being.
However I’d like to see some efforts made towards: - Rolling our SKS hacks back upstream with HP, initially this seems stupid but HP has already put in efforts to maintain compatibility with SKS peers.. I think a transitional SKS emulation mode that is easy to implement and maintain upstream is worthwhile, especially if we can come up with a plan to deprecate this nonsense down the road and its just to get us through the near future. - Continued pressure to extend the sks-keyserver pools to include HP out the box, this is the only way we’re going to save it. In its current state its already being mass purged from the clients.. Lying to the pool to save the pool seems totally defeating. - If it becomes clear the sks-keyserver pool is never going to accept patches, contributions, whatever it takes to get HP Servers included then its time to declare it dead, we can’t plan on lying to it until the end of time and SKS operators are dropping off like flies, and those that are sticking around struggle to maintain service. - Start a new pool service, designed to be extensible and start asking the few clients remaining on the sks-pool to start migrating off.. Technology stacks have changed quite a bit over the years and this may be less effort than it seems with standard libraries to interact with cloud DNS services pretty widespread. HP stats can be machine readable w/JSON, and we’ve got the opportunity to extend HP specifically to make joining pools more robust, trusted, and less fragile since I think there’s far more of us here capable of contributing GoLang over OCaml upstream.. I’m thinking like a dedicated machine readable status/health API endpoint that the server can sign with its own key and the pool provider can verify its the server it claims to be, and make accommodations for blacklisted/removed keys/max key sizes/etc accounting for variations in key counts. TBH I think creating our own pool is likely our best option going forward, yeah it’ll take some time (ie years) before Distros and the various PGP clients come back.. but most of em that I used personally that came out the box w/the SKS pool no longer do so I think the damage has long been done. I’ve been playing with the Cloudflare DNS API’s of recent and they seem like they would be well suited to hosting us a Hockeypuck pool, and Cloudflare has such a favorable stance for internet protection/security I would be astonished If they pulled the plug on a free account doing Keyserver pooling.. its more likely the’d be willing to donate some premium features to the cause than anything if needed. Best Regards, -Ryan Hunt > On Mar 22, 2021, at 1:41 PM, Marcel Waldvogel <marcel.waldvo...@trifence.ch> > wrote: > > On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote: >> >> I've created now a patch that just replaces in the json export contact >> with server_contact and Total with numkeys. >> https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385 >> >> <https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385> > > Great, thanks! I just merged this. Now my Hockeypuck server appears in the > statistics. > >> In my hockeypuck configuration i've set Version to 1.1.6+ and Software >> to SKS > > Hockeypuck is blacklisted in the sks-keyservers.net code, because it was not > good enough to be incorporated into the pool when Kristian wrote the code. > Now, it seems to be in the same ballpark as SKS. > > Asking Kristian to remove the Hockeypuck ban resulted in him explaining that > he does not plan to change the code or accept changes; instead, we should set > up our own fork of his code. > > I think this leaves us with the following ways to progress: > > a) We leave it as is, Hockeypuck is fine, but just not in the pool. > b) We create a second pool, where Hockeypuck is acceptable (and probably SKS > as well). > c) We agree that Hockeypuck lying to be SKS is accepted in the pool, and > maybe even recommended. > > I would favor (c), plus keeping the version number in the 2.x range, so that > experts still can tell the difference. > > Opinions? > -Marcel
signature.asc
Description: Message signed with OpenPGP
