It was thus said that the Great solderpunk once stated: > I would like to hope that it won't be *too* much longer before 4 just > kind of happens because networking libraries will have gotten to the > point where you have to actively go out of your way to write IPv4-only > code. > > Sorry that the Zaibatsu is doing a bad job of leading by example on > this front! I was fully prepared to accept the blame for this, since > the gegobi server was thrown togeher over a few evenings and I just > didn't think about IPv6. I thought I'd quickly patch it to support > serving on both IP versions at once before making this post, but... > > ...it turns out the quick and easy TCP server utilities in Python's > socketserver module are (still, in 2019 for crying out loud) > hard-coded to only work with IPv4. So it's not a quick patch, but a > slightly larger project. :( Maybe I was a bit optimistic in my first > paragraph. Sad. It's not that hard to support IPv6. In C, just by calling getaddrinfo() you can get both IPv4 and IPv6 addresses for a hostname (and it supports parsing IP addresses of either family), and socket(), bind(), listen(), connect(), etc. all support IPv6. > Since starting the Gemini project, this is the second time I've felt > disappointed in Python's standard library, which is a rare thing. At > gemini://mozz.us/journal/2019-08-21.txt, Michael writes about how the > ssl module can't accept a self-signed client certificate. Even worse > than that, while it's possible to accept self-signed server > certificates, you can't get direct access to the details of that > certificate (like, say, the validity start and expiry dates). With > CA-validated certificates you can easily get this data. If the cert > is self-signed, you can only get an x509 encoded representation of the > cert - and there's nothing in the standard library to decode it! The > ssl module really does seem to be designed to let people who don't > understand TLS very thoroughly write HTTPS stuff without shooting > themselves in the foot (the docs even talk explicitly about "Web > servers" instead of just "servers"!). And, of course, I understand > why it's useful for a library with that kind of interface to exist. I suspect this was done intentionall to disuade people from using self-signed certificates because dragons. Or hackers. Or something. Maybe people can't validate certificates properly. > Any way, perhaps the most interesting thing to come out of this > conversation is the matter of using URLs with IP addresses instead of > hostnames as Gemini requests. I'd guess a lot of existing servers > don't handle this well. Remove the TLS restriction, and it's not a problem at all. The problem is that during the TLS negotiation, the hostname of the server you are connecting to is sent [1] as part of the protocol. There is a way to extract which server is being referenced and thus, you can figure out which set of files (or handlers) to serve the request from. > And, as mentioned, in the case of > hostname-based virtual servers, it's not entirely clear what handling > this well even means. I wonder if it's worth explicitly disallowing > such requests? If you get foo.example.com as the host, service the request against this set of content (subdirectory, etc); if bar.example.com, out of that set of content. That's all it really means. The problem is getting the information from TLS. -spc [1] In my Lua wrapper for TLS, I have a function to connect to an endpoint using an address, and it's signature is: ios = tcp.connecta(addr,hostname,to,config) (the last two parameters are optional). You *have* to include a hostname. libtls won't work without it.
---
Previous in thread (4 of 8): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (6 of 8): 🗣️ solderpunk (solderpunk (a) SDF.ORG)