💾 Archived View for rawtext.club › ~sloum › geminilist › 007553.gmi captured on 2023-11-04 at 12:20:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Drew DeVault sir at cmpwn.com
Mon Nov 8 10:08:45 GMT 2021
- - - - - - - - - - - - - - - - - - -
Off the bat, I'm not so sure that gmnisrv or gmni really is all thatpopular. I use it myself, and I know several other who also use it, butI suspect that we are in the minority. To be honest, it's not even thatgreat, it crashes fairly often and is pretty unreliable as a result. Themain appeal is that it is simple and has few dependencies, which aretraits that BearSSL directly contributes to.
Another goal of gmnisrv is to be easy to maintain and reliable over thelong-term, which is something that BearSSL offers and something thatpinning ourselves to bleeding-edge technology witholds. I am very busyand I don't have the time to invest in, for example, overhauling the SSLstack for my Gemini software. Gemini is designed to be simple toimplement, and my hope is that it is also simple to maintain.
The advantages of TLS 1.3 are fairly trivial in my opinion. Encryptingthe client hello is nice (though, as you pointed out, not broadlysupported), but what you call "grassroots CDNs" is just another word forcentralization - these are in conflict, and I tend to cast my lot withdecentralized governance more so than ideal privacy. This is fixing itat the wrong level, anyway - overlay networks like yggdrasil or Toractually obsfucate who you're talking to properly (and provide transportencryption, which is why I would have liked to see optional TLS forGemini under certain circumstances...).
As for the other two changes you mentioned: Padding is an improvement.Performance is not important.
In short, the benefits are marginal, using BearSSL provides us withgreater advantages than disadvantages, and BearSSL better serves theproject's goals. What's more, I don't think I can easily spare the timeto make the necessary changes myself, and these projects are explicitlydesigned to be low-maintenance. I can hardly find time for theimprovements I *want* to make, like automatic cert generation based onMichael Forney's x509 library.
That said, if someone does feel strongly enough about this to put in thework, I would be willing to accept patches which address the problem. Ivery much do not want to use LibTLS, but maybe mbedTLS is a good option.Any patch would have to provide justification that the alternate TLSstack is simple, robust, and will be easily maintained in the long term(and, for what it's worth, OpenSSL is not any of these!).
Also, in the long term, I plan on writing a Gemini stack in my newprogramming language, which will probably make gmnisrv and gmniobsolete. However, we have to make our own crypto stack from scratchfirst, so I wouldn't expect to see that any time soon.