Opened 19 months ago
Last modified 11 months ago
#14873 assigned Bug/Something is broken
shutting down SKS on zimmermann.mayfirst.org
Reported by: | Daniel Kahn Gillmor | Owned by: | JaimeV |
---|---|---|---|
Priority: | Medium | Component: | Tech |
Keywords: | zimmerman.mayfirst.org keys.mayfirst.org decommission | Cc: | Jamie McClelland |
Sensitive: | no |
Description
given the issues with the SKS keyserver network, and how MF/PL is moving away from relying on keys.mayfirst.org
for its own internal use, i propose shutting down the SKS instance running on zimmermann.mayfirst.org.
This means keys.mayfirst.org
will go away, and there will be one fewer server in the SKS pool. It will affect everyone who has keys.mayfirst.org
listed as their default keyserver.
Some things to do for this shutdown to happen responsibly:
- think about what to do with requests that still come in. should we provide an HTTP 301 redirection to the HKP interface on a well-managed, constrained, abuse-resistant keyserver instance like
hkps://keys.openpgp.org
That could probably be implemented with an nginx or apache configuration snippet. Alternately, we could configure nginx to act as a reverse proxy and cache to an abuse-resistant keystore. Other ideas? - send mail to sks-devel announcing the plan
- mail the SKS peers of zimmermann individually to let them know that they should de-peer it
- announce it in some more formal way; I don't really know how to manage such an announcement, and would love help planning and publicizing it.
Change History (10)
comment:1 Changed 19 months ago by
comment:2 follow-up: 7 Changed 19 months ago by
Thanks dkg for starting this ticket. I got the notice on IRC - but you can also cc: me so I get a notice via email which is the most reliable way to alert me to a ticket.
I think the http permanent redrect would be the best option, since I don't think we should plan to keep keys.mayfirst.org alive forever and it sends a signal that any client connecting should know that this change is considered permanent. I'm not sure how many humans will actually get that signal, but it still seems like the most techically correct approach.
I also wonder if we can fashion such a redirect to exclude connections to https://keys.mayfirst.org/ (e.g. with no path component), so we could display a page with the announcement on it? Would this interrupt the redirection of a regular request for a key?
Lastly... I'm trying to work on an announcement about this entire situation for the full May First membership, and I think shutting down keys.mayfirst.org could be part of it. Our public announcement about shutting down keys.mayfirst.org could include a link to this more broad announcement to help provide context (or vice versa?)
comment:3 Changed 19 months ago by
Thanks for weighing in here. btw, i'm also fine with making this ticket non-sensitive whenever you all are, because i think it is good for the community to see these deliberations.
jamie, i'm not sure why you think we shouldn't keep keys.mayfirst.org
alive forever (before i opened this ticket, i thought indefinite maintenance of keys.mayfirst.org
was the plan). can you say more about why you think that keys.mayfirst.org
ought to go away? like it or not, MF/PL is a known and relied-upon part of the OpenPGP ecosystem at least in some corners. Do we want to step away from that role?
some thoughts re: reverse proxy vs. 302 redirect:
- if we do the 302 redirect, we'd need to ensure that dirmngr (and other possible keyserver clients) will actually follow such a redirect. i've run into weird problems with redirects from dirmngr in the past.
- if we do a reverse proxy, we would in some sense be operating as an anonymizing proxy for our users w.r.t. the data available to
keys.openpgp.org
about its clients. I'm not convinced that that role is hugely meaningful, but it does provide an initial layer of defense against at least some part of the concerns about re-centralization that are represented bykeys.openpgp.org
.
I think i'm currently leaning toward a reverse proxy at least for the HKPS and VKS interfaces, along with an updated "landing" page, but i could certainly be convinced otherwise.
comment:4 Changed 19 months ago by
Note also that keeping hkps://keys.mayfirst.org
as an at-least-somewhat-useful (non-redirecting) endpoint suggests an opportunity to participate in (and help shape) any future federation that arises from the ashes of SKS.
comment:5 Changed 19 months ago by
Owner: | set to JaimeV |
---|---|
Status: | new → assigned |
I also like the idea of preserving keys.mayfirst.org as a sign that we still support and promote the use of OpenPGP standard based encryption. Shutting it down now would send the opposite message at a time when some people , especially the non technical sector of the movement may be on the fence about abandoning OpenPGP encryption altogether in their daily use.
There have been some major setbacks for the proliferation of OpenPGP usage for sure. But for all of its problems I don't think we have anything as versatile and widely supported at the moment and I don't think we should abandon it.
I'm also fine with making this ticket public.
comment:6 Changed 19 months ago by
Cc: | Jamie McClelland added |
---|
comment:7 Changed 19 months ago by
Replying to Jamie McClelland:
I also wonder if we can fashion such a redirect to exclude connections to https://keys.mayfirst.org/ (e.g. with no path component), so we could display a page with the announcement on it? Would this interrupt the redirection of a regular request for a key?
I thought of the same, regardless of whether we are doing the proxy or redirect I think it may be as simple as using a location = /
directive in nginx that points to an html page with information about whatever it is we finally decide to do.
We could test the above and the proxy/redirect to keys.openpgp.org with a new domain for now.
Lastly... I'm trying to work on an announcement about this entire situation for the full May First membership
I'd also like to help with this.
comment:8 Changed 19 months ago by
Sensitive: | unset |
---|
Sounds like we are all good with making the ticket non-sensitive so I'm making the change.
jamie, i'm not sure why you think we shouldn't keep keys.mayfirst.org alive forever
Now I'm confused! I think, dkg, you are talking about the domain, right?
I read the this in the ticket:
This means keys.mayfirst.org will go away, and there will be one fewer server in the SKS pool. It will affect everyone who has keys.mayfirst.org listed as their default keyserver.
And thought you were proposing that we make keys.mayfirst.org go away permanently.
However, now I think your proposal is a bit more nuanced.
I'm in favor of keeping keys.mayfirst.org if we have some ideas on how it can continue contributing to the ecosystem. My preference for a permanent redirect was based on the assumption that it was going away, not based on a preference for it to go away.
comment:9 Changed 11 months ago by
Owner: | changed from JaimeV to Daniel Kahn Gillmor |
---|
OK, this discussion has been basically idle, so i think everyone has probably weighed in who cares to weigh in.
I'll start setting up an nginx reverse proxy to keys.openpgp.org on zimmermann.
JaimeV, i'm taking "ownership" of the ticket just because someone needs to do it, but i would not object if you wanted to take it over again! i'm not trying to step on any toes.
comment:10 Changed 11 months ago by
Owner: | changed from Daniel Kahn Gillmor to JaimeV |
---|
I've got no toes left in this and no fingers to spare. I really appreciate your help dkg. If we can review the nginx config together when you're ready I can try to be involved in the upkeep.
Please login to add comments to this ticket.
I like the idea of the nginx reverse proxy or the redirect if this will save some people from abruptly having their workflow or automatic key updates break.
I can help with drafting an announcement. Do we expect any kind of reaction from sks-devel or SKS peers if/when do this?.