In addition I’ve got an interesting story, last time I seen the SKS keyserver pool mentioned outside this group was recently when I got acquired by one of the Linux Distros and one of the first steps they wanted all of us to do was create PGP keys off our old corp email and submit em to the SKS pool so they could start sending us our credentials encrypted w/PGP.. which unfortunately the day we all did it the SKS pool was in terrible shape, so I helped the majority of my co-workers find a working server because there was like 1 node in the pool that day and it was struggling w/the load, it took a few attempts to get a key in if you were lucky.
This was only about 5 months ago.. and I knew then the SKS pool was doomed if nothing changed ASAP.. unfortunately the same event has made life really busy since and I’m only now getting some unallocated space in my head to think about this situation and what needs to be done about it. -Ryan > On Mar 22, 2021, at 4:16 PM, Martin Dobrev <mar...@dobrev.eu> wrote: > > > On 22/03/2021 22:02, Ryan Hunt wrote: >> 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. > I stand by this idea. We need to keep the pool running until an improved > version gets rolled out. >> - 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. > Where are they going? If all major software and OS vendors start running > their own keyservers then finding a key becomes harder. >> - 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. >> > +1 >> 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 >>> <mailto: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 >>> <http://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 >> > <OpenPGP_0xCAAAE2B8C198C9AE.asc>
signature.asc
Description: Message signed with OpenPGP
