💾 Archived View for rawtext.club › ~sloum › geminilist › 001439.gmi captured on 2020-09-24 at 01:52:56. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Martin Keegan martin at no.ucant.org
Tue Jun 9 03:35:35 BST 2020
- - - - - - - - - - - - - - - - - - -
On Mon, 8 Jun 2020, Sean Conner wrote:
My implementation is that $REMOTE_USER is set to the common name in the
cert subject. I think this is a good idea, but I don't think it's common
practice in the Gemini universe.
Of the dozen Gemini servers (software) out there, five (a little under half)
support CGI. Out of those, blizanci, GLV-1.12556 and getforce (a little
over half) set REMOTE_USER to the common name of the certifiate. The other
two don't set REMOTE_USER at all.
I stand corrected.
The CGI standard (RFC-3875) states that REMOTE_USER is set only if
authentication is used. blizanci sets is reguardless ("" if not there),
GLV-1.12556 and jetforce only set it if a certificate is used.
I see no reason not to follow the spec on this point, so I have justchanged this behaviour.
(I remain skeptical about whether SSL is the right choice - I reckon
Gemini's simplicity goal is going to run up against the practice of
trying to reuse as much existing infrastructure as possible.)
Okay, what encryption system would you have us poor non-cryptographer
programmers who write servers use and poorly implement? Feel free to bring
to the table a working server and client to show us how easy it is [1].
Something similar to CurveCP. I am loath to suggest it though, because it associated with being a djb fanboy, which I am decidedly not. I don't havea concrete proposal. What I'd say is that it'd be good not to hardwire SSL too strongly into Gemini, in case the tooling around an alternative improves sufficiently in the future and we'd like to swap.
[1] If this comes across as too snarky or mean, this has come up at
Not a problem whatsoever. I'm fairly thick-skinned.
Mk
-- Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/