💾 Archived View for rawtext.club › ~sloum › geminilist › 007432.gmi captured on 2024-02-05 at 10:41:58. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

A proposal to freeze the Gemini specification

Rohan Kumar seirdy at seirdy.one

Tue Oct 26 09:46:41 BST 2021

- - - - - - - - - - - - - - - - - - - 

On Tue, Oct 26, 2021 at 06:44:23AM +0000, Robert "khuxkm" Miles wrote:

I'm of the opinion that TOFU is perfectly fine in this scenario. The
only thing I think would be good as an addition to Gemini is a way to
deprecate a certificate. As it stands, if your capsule gets compromised
there is no way to stop clients from recognizing the compromised
certificate as valid. That being said, as you mentioned, that's more of
a thing that can be decided out-of-band and doesn't really require the
Gemini spec to change.

The initial request can also be MITM'd, which can be mitigated by verifying the key "out-of-band". This "out-of-band" thing shouldn't be Gemini itself but ideally something completely different and possibly generalizable to non-Gemini scenarios.

I feel like that's a mischaracterization of Spartan. In the past, I've
described Spartan as "gemini - tls + uploads", because that's basically
what it is (barring some things like the =: line type for input links,
and the one-character status codes). It's more its own protocol that
happens to take design cues from Gemini (Sean, if I'm completely
missing the point here, please do tell me, but this is the impression
I've gotten so far). Perhaps you meant Titan?

Oh, I was thinking of Titan. Another project I'm liking better is Iapetus.

-- /Seirdy-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 898 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211026/80447739/attachment.sig>