tl;dr: We have a new Keysign release with support for exchanging keys via the Internet.
I am very proud to announce this version of GNOME Keysign, because it marks an important step towards a famous “1.0”. In fact, it might be just that. But given the potentially complicated new dependencies, I thought it’d be nice to make sort of an rc release.
The main feature is a transport via the Internet. In fact, the code has been lurking around since last summer thanks to Ludovico’s great work. I felt it needed some massaging and more gentle introduction to the code base before finally enabling it.
For the transport we use Magic Wormhole, an amazing package for transferring files securely. If you don’t know it yet, give it a try. It is a very convenient tool for sending files across the Internet. They have a rendezvous server so that it works in NATted environments, too. Great.
You may wonder why we need an Internet transport, given that we have local network and Bluetooth already. And the question is good, because initially I didn’t think that we’d expose ourselves to the Internet. Simply because the attack surface is just so much larger and also because I think that it’s so weird to go all the way through the Internet when all we need is to transfer a few bytes between two physically close machines. It doesn’t sound very clever to connect to the Internet when all we need is to bridge 20 centimetres.
Anyway, as it turns out, WiFi access points don’t allow clients to connect to each other 🙁 Then we have Bluetooth, but it’s still a bit awkward to use. My impression is that people are not satisfied with the quality of Bluetooth connections. Also, the Internet is comparatively easy to use, both as a programmer and a user.
Of course, we now also have the option to exchange keys when not being physically close. I do not recommend that, though, because our security assumes the visual channel to be present and, in fact, secure. In other words: Scan the barcode for a secure key signing experience. Be aware that if you transfer the “security code” manually via other means, you may be compromised.
With this change, the UX changes a bit for the non-Internet transports, too. For example, we have a final page now which indicates success or failure. We can use this as a base for accompanying the signing process further, e.g. sign the key again with a non-exportable short-term signature s.t. the user can send an email right away. Or exchange the keys again after the email has been received. Exciting times ahead.
Now, after the wall of text, you may wonder how to get hold of this release. It should show up on Flathub soon.
