💾 Archived View for gemi.dev › gemini-mailing-list › 000138.gmi captured on 2024-08-18 at 23:32:15. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hey folks, I'm preparing to finally do a 1.0.0 release of AV-98 this weekend and would appreciate people helping me kick the tyres. Once the release is made you'll be able to install it with pip, but for now you need to clone the repo: https://tildegit.org/solderpunk/AV-98/ There's a setup.py in there if you want to install it yourself, but it has no essential third party dependencies and it's all in a single file so you can just run av98.py from right where you clone it, easy peasy. The release is mostly for the sake of easier installation, and for everyday use you won't notice much new if you are already used to how AV-98 works. But there have been substantial changes to the TLS-side of things. Firstly, you can now toggle between two methods of TLS certificate validation (AV-98, until now, did no verification whatsoever, an embarrassing reminder of it's "hacked together quickly in response to the surprise experience of an actual, live Gemini server" legacy). With `set tls_mode tofu` (the default), you get the TOFU validation mode I initially envisioned for Gemini. When you first visit a server, the received certificate is blindly trusted. An SQLite database is maintained with the fingerprints of trusted certificates, a count of how many times they've been seen and the dates they were first and most recently seen. If you ever subsequently see a different certificate for that host, you get a warning with details on how often the previous cert was seen and when it is/was due to expire, to inform your decision on whether or not to accept it. Note that it's not required, but the TOFU mode works beter if you have the `cryptography` module installed - certificates won't be blindly accepted if they are expired, or not yet valid, or don't have a common name or subject alternate name matching the expected hostname. Python's standard `ssl` module doesn't let you check this for self-signed certificates (really!). In TOFU-mode there's a lot of creation of files and directories and this is largely what I'm hoping to discover bugs in by getting people to try this out. With `set tls_mode ca` (which you can stick in an RC file to make your permanent setting), AV-98 will do typical CA-based validation using your platform's default trusted certificates, and will refuse to accept self-signed certificates. For now I'm still wimping out on setting a hard requirement on TLS cert validation in the spec (which allows whatever the client likes - but clients really should be extremely upfront with users about what they are doing!). But for my part I am pretty committed to experimenting with less centralised and less commercial alternatives to the CA system and I'll probably end up building a lot more options into AV-98's TOFU mode to reduce the risk associated with the initial acceptance. I'm taking a lot of inspiration and ideas from DNS-based solutions like DANE, and from projects like Perspectives and Convergence. I'm happy to discuss them with interested folks. Secondly, there is now a "client certificate manager" which is accessed via the `cert` command. Use of client certificates in Gemini is currently under-specced and (perhaps as a partial consequence) under-used, and I want to correct this in the near future. So I threw some stuff together in AV-98 to give us concrete ideas to discuss and test. None of how this functions is "canonical" yet - I'm embracing the notion of AV-98 as an experimental client where we test stuff out. For now, the client certificate manager relies on the `openssl` command line tool being available to run with `system()`, because this is a whole world of pain less than doing it in Python. When it receives a 60, 61 or 62 status code, AV-98 will pop up a notification and give the use the option to generate a client certificate to use when re-requesting the resource, or to load a previously generated (non-transient!) certificate from the filesystem. When client certificates are *not* being used, the AV-98> prompt now appears in a happy, friendly lime green colour. As soon as a client certificate is loaded, the prompt becomes a scary deep red and displays as "AV-98+cert>". If, while a client cert is loaded, you try to navigate away to a different domain, AV-98 will warn you and give you a Y/N dialogue to deactivate the cert before continuing, to avoid "identity leak". If you subsequently navigate back, during the same session (I mean AV-98 session here, i.e. you haven't exited and restarted the program), to a domain where you previously used a client cert, you'll be asked if you want to load it again. You can use the `cert` command to explicitly end a client certificate session any time you like. It's all a bit clunky and explicit for now (although to some extent that's a good thing because people should be *aware* of how they use client certs), but it's definitely a huge improvement over previous options for occasionally keeping an eye on your astrobotany plant! I will make a separate more detailed post later about client certificates and the things we should think about with regard to them. That's about it! Thanks to anybody who tests out, bug reports welcome via email or at https://tildegit.org/solderpunk/AV-98/issues. Cheers, Solderpunk
On Sat, May 23, 2020 at 01:28:39PM +0000, solderpunk wrote: > I'm preparing to finally do a 1.0.0 release of AV-98 this weekend and > would appreciate people helping me kick the tyres. Once the release is > made you'll be able to install it with pip, but for now you need to > clone the repo: Just to follow up on this now "overdue" release: I've been getting lots of helpful bug reports, pull requests and suggestions from people, which is great. Thank you all! I decided to put off the release until a few days went by without any such thing coming in, which will hopefully happen soon. Cheers, Solderpunk
---