On my Mac here the GPG Keychain app now defaults to hkps://keys.openpgp.org <hkps://keys.openpgp.org>, Ubuntu is using their own HP servers now that are not joining the pool, and these searches on Github is a bit depressing, lots of commits setting the same server as default and/or removing the SKS pool: https://github.com/search?q=keys.openpgp.org&type=commits <https://github.com/search?q=keys.openpgp.org&type=commits> https://github.com/search?q=sks-keyservers+removed&type=commits <https://github.com/search?q=sks-keyservers+removed&type=commits>
> 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
