<-- back to the mailing list

Regarding `gemini://` over NaCL (replacing TLS)

Sean Conner sean at conman.org

Tue Mar 3 04:55:57 GMT 2020

- - - - - - - - - - - - - - - - - - - ```

It was thus said that the Great Michael Lazar once stated:
> 
> It was thus said that the Great Bradley D. Thornton once stated:
> 
> 
> 
>
> 
> 
> On the other hand, I recall quite clearly, Michaels encyclopedic
> 
> 
> lamentations on the vagaries of attempting to acheive successful results
> 
> 
> in Python, with regards to TLS and client/transient certs, due to the
> 
> 
> horrendous state of Python libs in that regard :)
> 
>
> 
>   Do you have any links to this?  I don't remember seeing any of that, and
> 
> I'd be interested in reading it.
> 
> I believe this is referencing this post that I made a while ago [1].

  Ah, thanks.

  I'm beginning to think it's a shame that libtls isn't used more often.  Iknow of only one other TLS implementation that has implemented libtls, andthat's bearTLS (which hasn't implemented everything in libtls as of yet).It really does make using encryption with TLS easier.

> Personally, I would rather have gemini:// not be encrypted at all. I know
> there is a subset of privacy conscious users who are super dogmatic about
> security and E2E encryption. This much is clear from watching the gopher
> community. But I am not one of those users, and that is not what excites me
> about the gemini protocol.

  I hear you.  I'm not overly fond of the whole "encrypt all the things"movement myself.    But hey, the only constant is change.

> [1] gemini://mozz.us/journal/2019-08-21_transient_tls_certs.gmi

  -spc