Posts in category "Python"

Another little update to Wasat, this time bumping the version to v1.11.0.

After this morning's change, I made a start on the work I wanted to do on Rogallo and quickly realised that most of what I had planned was better done in Wasat itself. The short version is: rather than maintaining a just-this-session ignore list in the application, it made more sense to handle this in Wasat.

So this release adds an ignore_security_error method to the client that lets you -- for the current session -- ignore a particular type of error for a given host/port pair. This makes for a lot less work needing to be done by the application making use of Wasat. Now it's just a case of¹:

from wasat import Client, IgnorableSecurityError

client = Client()
uri = "gemini://expired.example.com/"

try:
    response = await client.request(uri)
except IgnorableSecurityError as error:
    client.ignore_security_error(uri, error)
    response = await client.request(uri)

Obviously, the code in Rogallo is a bit more involved than the above, but that's the gist of it: try the request, if it fails with an error that can be ignored, ignore it and try again.

Since getting into Gemini, one of my daily rituals has been to tend to my plant in AstroBotany. This morning, when trying to visit there with Rogallo, I was greeted with this:

In other words: the certificate has expired¹. At this point, the error dialog isn't that useful. It's pretty much designed for dealing with capsules that are using self-signed certificates -- where TOFU is being used and so it would normally make sense to just forget and re-establish trust. With an expired CA certificate, the act of forgetting does nothing, it'll just fail again.

While it's technically fine to simply refuse to progress, in this case, it's not exactly friendly to the user. What would be sensible would be to allow an "Ignore" option. This would, I imagine, ignore the problem for the current Rogallo session -- ideally with some sort of indication that the capsule is suspicious at the moment. Also, the dialog that gives you this option should show all the certificate details so the user can make an informed decision.

The issue here is that, until now, Wasat has dealt with security-type problems by raising a single SecurityError exception. Aside from dumpster-diving the description in the exception, there's no way of knowing the nature of the security issue. v1.10.0 addresses this by adding and raising many different exceptions:

• CertificateExpiredError
• CertificateNotYetValidError
• CertificateRejectedError
• CertificateRevokedError
• CertificateUntrustedError
• FingerprintMismatchError
• HostnameMismatchError

All of these inherit from SecurityError to maintain backward-compatibility.

While this change doesn't alter the way that Rogallo handles this situation right now, it does at least set me up for tackling the work I have planned.

I've just made a small update to GopherMap. While doing some work on Rogallo I noticed that, somehow, I wasn't showing a type "badge" for PNG files (p). I spent a moment or two trying to figure out what was wrong with the code in Rogallo, and then realised that I'd managed to miss out both PNG and RTF files in GopherMap itself.

So this release adds those types.

At this point I believe that GopherMap now knows about all the canonical and most useful non-canonical types.

At some point I should probably look at Gopher+, which I suspect will also mean some changes to Port70.

The work to add Titan support to Rogallo is going well, and I've been able to test it out fine on bbs, doing additions of "long text" and performing file uploads. In doing so, though, I was reminded that there is a proposed "edit" extension to Titan, which is supported there (and I believe on a couple of other capsules too). That got me thinking...

Wasat v1.9.0 is now available, which adds support for this extension. Of most use is the is_edit property which has been added to TitanURI, giving a well-defined approach to testing whether a Titan URI is for editing a resource. The Client class has also grown an edit method to handle the request for the raw content which will then be used as the basis for a subsequent edit by the user, before being uploaded.

All of this, of course, pushes back the work I'm doing on Rogallo, just a little. As I said above, the Titan support is pretty much there and working, but now I want to try and really dial it in and get it working "just so". While the edit support is probably pretty niche, it seems worth adding and, I hope, might delight someone one day when they try it out and it "just works".

Another quick little update to Wasat, bumping the version to v1.8.0. This version is in support of some work I'm about to do on Rogallo: Titan support.

This release adds TitanURI and makes a number of changes to handle such URIs alongside GeminiURI. A lucky side-effect is that a problem was uncovered and corrected with how Gemini URIs are sliced and diced in the library. This first showed up for me when I was having a look at the Scriptonite examples. None of them were working for no obvious reason. Eventually it became clear that parts of the URIs were being lost as they travelled through Wasat's code.

So v1.8.0 clears up that problem (fixing the bug in Rogallo by simply upgrading the library).

As of now, I can move on to actually adding Titan support.

I've just released the first version of another library in the collection of libraries that support the development of Rogallo: specifically, another one that helps convert text in other formats into Gemtext so Rogallo's display can be a little richer. In effect, this is a sibling to md2gemtext and html2gemtext.

This time it's a library to convert finger responses into Gemtext, where it makes sense. For the most part, finger responses are free-form plain text, but there are times when there's information in the response that would be of most use if you could interact with it. For example, if you get a user list from plan.cat¹, that's a lot of data that could be turned into finger:// URIs that can be subsequently followed.

With this in mind, finger2gemtext can take a body of text, look at it to see if it might be possible to convert it to useful Gemtext, and will convert it if that's the case. Given that there's no standard to be had here, and given that any given response could be of any form the author desires, I'm making the conversion pretty conservative.

What I have done, though, is make it so that the conversion process can be extended. The finger_to_gemtext function can be given a collection of additional filtering classes; if the built-in classes can't find anything to convert, the additional classes get a go. There is a base class to inherit from.

I've not fully planned it out yet, but the vague idea I have here is that Rogallo could, at some point, have "finger plugins" which will handle various special cases and site-specific formats.

For now, though, this gives me the basics that let me turn this:

into something where I can follow finger:// links without the need to copy/paste/edit:

Now I need to find a few more online finger resources that respond with things worth making linkable...

A small update to Port79, bumping up to v1.1.0. This release adds a resolve method to the FingerURI class.

I'm currently tweaking Rogallo's rendering of some responses from finger services and being able to resolve URIs relative to the underlying page is going to be very helpful.

A quick little update to Wasat, bumping the version to v1.7.0. In service of a feature I'm adding to Rogallo, I've added a forget method to the trust store class, so that a certificate fingerprint for a particular host/port combination can be forgotten.

This came about because, if a fingerprint does change for a Gemini capsule, I want a Rogallo user to be able to decide to either avoid it or forget it and re-establish trust. While the fingerprint mismatch should be a warning to distrust the capsule, there might be a legitimate reason why the certificate has changed, and I want to make that decision fairly frictionless.

While it might seem that it's been pretty quiet on the Rogallo front the past few days, I've been doing some work on it every day. There are a lot of changes and improvements coming. As I got the next release ready, I realised that some of the support libraries I've built for it were stuck with 0.x versions while, at the same time, having proven to be quite stable.

So I've just made v1.0.0 updates to the following:

• html2gemtext
• md2gemtext
• port1900
• sybaritic

There are no material changes in any of these releases, the only real change being the bump to v1.0.0, and so marking them as stable and, of course, guaranteeing that semantic versioning promises are now in place.

The client certificate management PR for Rogallo is very close to completion now -- although the thing has grown arms and legs and turned into a bit of a UI overhaul¹. Something I wanted to add was a quick and easy way for the user to view the details of a client certificate that's being used for the current page. Rogallo lets you do this for the server certificate, but not the client certificate.

It was at this point that I realised I'd never provided easy access to the ClientCertificate on the Response object. So v1.6.0 addresses this and provides Response.client_cert.

With this in place, I think I can finally get that Rogallo PR over the line...