monkeysign removal from bullseye

[Antoine Beaupré]

On 2020-03-21 23:39:19, Andrew Gallagher wrote:
> It would appear that the python2/3 migration dumpster fire has claimed
> yet another good package[1]:
>
> ```
>> Hi,
>> Has there been further development? Otherwise I'd suggest to remove
> monkeysign
>> for now, it's blocking the removal of pygtk (and in turn a few other
> libraries)
>> and it can still be re-introduced by bullseye release if it gets ported.
>
> i'm sorry to say there has been no progress and must now admit this is
> the only short term solution.
> ```
>
> I cannot stress enough how awesome monkeysign is. I have a pet project
> that is only reasonably possible because of its existence, and which I
> will have to abandon if monkeysign becomes unmaintained.
>
> How much work would be involved in getting it back into production? I'm
> not a python programmer (the python2/3 migration catastrophe has put me
> off ever wasting my brain cells on it) but I might be willing to suffer
> it for this one project.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937066

TL;DR: a lot of work.

Hi!

Monkeysign author here.

I've been beating this drum for years now. In july 2018, I posted this:

https://0xacab.org/monkeysphere/monkeysign/issues/64

No one stepped up.

Then that issue was opened in the Debian bugtracker about the out of
date Python 2 and pygtk dependencies. Again, I said I didn't have time
to deal with it.

No one stepped up.

Then I was pinged again on friday, and was told my package was keeping
everyone else from moving on, away from pygtk and python2. I gave it the
green light, with the understanding that someone could re-introduce the
package later in the bullseye release process.

Within less than 24 hours, I get this email offering help.

While I'm flattered and happy to hear people say "how awesome monkeysign
is", I must say it's a bit frustrating to hear that only after years of
silence and only a handful of people providing any sort of help to the
project. I know this is typical for free software projects, but at this
point, it's a bit disheartening.

There's a lot of work to do to bring Monkeysign back into Debian. First,
ideally, it would need to be ported to GTK3:

https://0xacab.org/monkeysphere/monkeysign/issues/21
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885517
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935335

But that's so much work that it might be better ripping out the entire
GUI code and just remove the GTK dependency. It would be the first step
to a port anyways: I don't think it makes sense to "rewrite" from gtk to
gtk3. It's basically "write a new UI", so removing the code would at
least remove this hurdle in the path to Debian inclusion.

Besides, if people want a GUI to sign keys, GNOME keysign is pretty much
the state of the art there, as the issue above documents.

Then the other part of the challenge is to port to Python 3. @simonft
already did an awesome job there porting from our custom stderr logging
to the logging module. It takes care of a huge chunk of the porting (as
we were using old-style print statements!). But there's still more work
to be done to port to Python3:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937066

I have a dev/python3 branch that is the latest work on this, if people
want to take a look. Right now tests hang and I doubt the thing actually
works.

Part of the problem with monkeysign is it was written before gpgme
gained support for signing keys and dealing with keyrings (and I'm not
sure its support is still good enough). I also didn't find out about the
python-gnupg python library before writing the first spike on a train,
so I ended up rewriting my own wrapper around `gpg --status-fd`, which
was a terrible mistake.

In retrospect, I consider it's a mistake to write *anything* that talks
with `gpg --status-fd` now. That protocol is brittle, changing,
minimally documented and extremely hard to use. It's better to use
gpgme, but it feels really strange, from a developer's perspective, to
talk to a C library that talks to the gpg binary. I can't help but think
there are many bugs (if not security issues) lying underneath those many
layers.

If I would be seriously resuming work on monkeysign (ie. if I had time
for it at all), I would just start from scratch, without GnuPG. I would
use a library like PGPy (probably forking it, because so far upstream
has not been very responsive) and implement what's missing (mostly
HKPS/WKD, ECC, keyring management, and GnuPG interoperability).

But I don't have time for this, at all. So someone else will need to do
it. Otherwise, I'll just do like everyone else does and use pius or
caff.

I'm sorry about this. I know it sucks to have a piece of software you
use on a daily basis just disappear from under you. But there are real
people, mostly volunteers, behind those projects, and they need your
support. A little "thank you" goes a long way, already, and it's
something anyone can do. But we also need real work and hours into
projects, otherwise they will die, just like that.

I hope that clarifies, again, the situation with monkeysign and wish you
the best of luck in your future endeavors.

A.

-- 
To understand how any society functions you must understand the
relationship between the men and the women
                        - Angela Davis