This is not a post about why TLS is a part of Gemini, nor about the benefits of TLS. Let's assume TLS is a good thing¹, and use it to get a document from the Gemini network.
TLDR: I am lazy, impatient, and not smart enough (very likely) or the state of TLS libraries is an embarrassment to the human race. I vote for both. Don't take it too seriously, though.
Easy, you say, because you use Go, or Rust, or Python... It's like extra 10 lines, you say. No, it is not. It is a giant library that pulls in numerous other Python or Go libraries out of thin vacuum and stores them in hidden directories on your computer, (often making them really hard to delete, by the way). What do these libraries do? No one knows, but some guy on the internet says they are safe. Eventually, they pull in a TLS library written in C (more likely you already have it on your machine). Some other guys on the internet OK'd it too.
Everyone takes these things for granted, but I do not. Because eventually the entire stack (haha) depends on some library below that swaps byte order (or something else equally trivial that for some reason required a library), and the guy who who wrote it ten years ago is sitting in his underpants in Cleveland, scratches his ass and accidentally removes his library from the repo, and it takes a month to restore order as every application on the web behaves 'anomalously'. Also, it makes me a little sick to use languages with arbitrary design constraints, especially those pushed by large corporations operating in the data collection field. And I don't need to.
If you use a 'modern' language, it's turtles all the way down until there are no more turtles, and there is some C code, and sometimes, assembly code -- with a surprising number of turtles above. You are standing on the shoulders of giants -- or more accurately, really fat, deformed homunculi, who are squishing even fatter ones below them flat. A disgusting puddle or rotting flesh below is obscured by rolls of fat spreading as far as the eye can see.
So let's go straight to that library below.
As we know, crypto is not something to take lightly, and rolling your own pretty much guarantees failure. So needless to say, there are not many TLS libraries that are used by _EVERYONE IN THE WORLD_ to do really important tasks, such as banking, running stock exchanges, moving corporate documents around, conducting drug deals, not to mention growing your imaginary plants. Surely these must be incredibly good libraries, right? Meticulously documented? Easy to find?
OpenSSL, right? Or is it LibreSSL? LibreTLS? LibTLS? Surely there is an easy way to at least identify the right library.
A short while ago, as a Gemini noob, I had a real itch to compile a toy client to fetch a simple Gemini page. Not much to ask for. Except I wanted to do that in C, because, in spite of it being a really shitty language, you can pretty much see (haha) what the compiled code will do, and because it's low level, and it does not make me _as_ sick as other languages. And once I have a simple C example I can make a quick FFI library for Common Lisp. But I digress.
So, where is a reference C client that you can write in a couple of hours as the story goes? I mean, connect to a socket, make a request, read the data, close the socket. Where is that example? It does not exist. Why?
There is `gmni` which is a simple command-line utility that does what I want, but it is much more complicated than the 30-line thing I am talking about. Looking at the source for 3 minutes did not satisfy me.
I know a bit about coding, but haven't dealt with TLS (and never wanted to, really). Let's figure out which library to use... According to the webs,
libreSSL is forked from OpenSSL (to fix Heartbleed) in OpenBSD and contains
Reading more... libretls, is based on LibreSSL port of libtls to OpenSSL. What the dickens are they talking about? And why can't I figure out what I should use for this trivial TLS client?
@omar-polo, the creator of wonderful telescope, tried to educate me in September 2021:
Unfortunately, neither libressl nor libtls are packaged on Debian-derived distributions AFAIK.
(I know for sure Fedora, arch, void, alpine, gentoo have it packaged.)
Telescope needs openssl and a library called "libtls", which is provided by either LibreSSL
or LibTLS (it's easy to get confused with these similar names.)
If libtls or libretls are not available for you distro, you have tree options I think:
manually install libtls: https://git.causal.agency/libretls/about/
I have a friend that uses debian and has installed libtls using checkinstall, he posted
a guide some time ago: gemini://gnuser.land/gemlog/2021-07-02-telescope-part-one.gmi
I trust this guy, but I haven't personally tried the procedure explained.
use guix: it's a package manager that can run on top of other distro and telescope
is available there https://guix.gnu.org/en/packages/telescope-0.5.1/
use the provided binaries: in the release page you'll usually find telescope.linux.amd64
and telescope.linux.aarch64 which should run on all distribution (the .amd64 is for x86_64
computer, the aarch64 for armv8, such as the raspberry pi 3 or 4)
Not exactly the right words to build my confidence in this TLS business.
That was in response, btw, to my question about how to get libretls or libtls on Ubuntu:
I can't find it, even with Google! I have openssl-1.1.1 and was concerned about LibreSSL stepping on it. Any help is appreciated, and I can't wait to give telescope a try.
I managed to get libretls somewhere. Or was it libtls? I compiled some examples from the various libraries and tried to connect to a Gemini server, getting weird errors. I dicked around for a bit. I screwed up my system a bit. I got many more errors. I looked around some more and asked questions. After a few days I realized that:
It is not exactly trivial to connect to a Gemini server without relying on many megabytes of code and a language written by Google or someone else I have no respect for. I think my time is better spent elsewhere.
These are the libraries that run the world. God help us all.
[1] We all know what happens when you 'assume'...