considering monkeysign retirement
Ever since GTK2 was abandoned (#21), I have wondered what to do about Monkeysign. Rewriting the GUI with another toolkit is a big challenge, and there is already another project that does much better on the GUI side (GNOME Keysign) that was originally built on top of Monkeysign (but now flies on its own, on top of GPGME).
So in #21, I thought of just removing the GUI from Monkeysign completely. That would leave us with the commandline. But then the state of that code is not much better: it relies on a custom GPG library I wrote on a whim when none would do the job back when Monkeysign started. To have Monkeysign work well in the future, we would need to port Monkeysign to another library, either GPGME or PGPy, probably the former considering the latter is still missing some key functionality. But that would mean there would be very little code from Monkeysign left.
Considering all this, I am not sure what's left of Monkeysign I want to keep. It's really showing its age: Monkeysign was started in 2010 at a time where Python 3 was just a funky acronym and still a bad idea. Python was really different back then: pytest didn't exist so the Monkeysign test suite is heavy and unreliable.
Everytime I pick up Monkeysign, it's a huge pain: the test suite fails because my key expired or some other weird situation. I can't stand looking at
gpg.py anymore. Fixing this would mean basically rewriting Monkeysign from scratch, and while I might be up for that, I don't have time to do that right now, and I'm not sure it's worth it, as there are viable alternatives that are better maintained (GNOME Keysign for the GUI and pius or caff all have more recent releases than Monkeysign).
It was a great ride, and Monkeysign was a great prototype for ideas that have been embraced by other projects like OpenKeychain and GNOME keysign. It popularized the idea of facilitating keysigning with qrcodes and made its point. I think it's time to retire it.
This means, in effect, the following:
- I will make one last point release for 2.2.x
and 2.0.xfor stretch and jessie, as there are some critical bugfixes there pending, along with a (minor) security issue (done)
- propose a 2.2.4 stable update for stretch when it is accepted in unstable (in progress, SRU filed as #901814)
- once the discussion here resolves (~2 weeks) I will file a release critical bug to kick monkeysign out of Buster. this will allow other DDs to use and maintain Monkeysign if they so wish
- I might release another 2.3.0 final release to unstable to bundle the stray commits on the 2.x branch
In any case, I am definitely considering stepping down from the project even if someone shows up. If the energy is there, I might be available to review patches and comment on issues, but I've dragged this project for too long and I'm tired of it. I'm also too concerned of the reliability of the GPG library that I can commit to any sort of security promises anymore. It has been very difficult to (basically) reverse-engineer the "proprietary" (as in "custom") protocol GnuPG speaks over its various file descriptors, partly because the documentation is limited and confusing but mostly because it is so unusual. So I will try my best to stay away from implementing stuff on top of GPG in the future and will look towards native interfaces like PGPy. That's not to say OpenPGP itself is not a good idea, but we need a better tools to deal with it as something that is too hard to use is inherently insecure, regardless of its theoretical security properties.
Comments are very welcome, of course.