Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#10385 closed defect (fixed)

Replace BridgeDB's use of python-gpgme with python-gnupg

Reported by: isis Owned by: isis
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: bridgedb-email, bridgedb-0.3.0
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Due to concerns which I've pointed out in #5463, we should assess the effort needed to replace BridgeDB's use of the python-gpgme module with python-gnupg (full disclosure: I wrote and maintain it). I'm recommending the one I maintain because I've auditted most of the GnuPG Python module/wrappers out there and they are all terrible. If someone else knows of another one which doesn't completely suck, feel free to use that instead.

Before starting work on this, someone should assess the effort required so that we can decide if it's worth it to go through with the switch.

Child Tickets

Change History (5)

comment:1 Changed 6 years ago by isis

Parent ID: #5463
Priority: normalminor

I fixed the issue where GPGME was loading keys from the process owner's $HOME directory (see #5463). I still think we should eventually switch, although I'm not prioritizing this right now.

comment:2 Changed 5 years ago by isis

Priority: minornormal

Another reason to switch is that (now that Twisted works with PyPy) our use of PyPy for running BridgeDB is blocking on not using pygpgme (which won't ever run with PyPy). (Switching to running BridgeDB with PyPy with a compiled-in JIT as the interpreter would provide speed increases by something like a factor of 1000.)

comment:3 Changed 5 years ago by isis

Keywords: bridgedb-0.2.5 added
Resolution: fixed
Status: newclosed

This is fixed in my fix/10385-python-gnupg_r1 branch. The changes were surprisingly simple, and the new code works much more reliably than GPGME.

comment:4 Changed 5 years ago by isis

Keywords: bridgedb-0.3.0 added; bridgedb-0.2.5 removed

comment:5 Changed 5 years ago by isis

There is a minor fix on the above branch, and it is in my hotfix/10385-init-gpg-ret branch.

The fix concerns the return value of the bridgedb.crypto.initializeGnuPG() function when that function's test signature creation code (towards the end of the function) fails.

When the test signing in bridgedb.crypto.initializeGnuPG() fails, the return value would be None, rather than the gpg interface and the signing function, (gpg, gpgSignMessage), or (None, None) as it does with the other failure modes. This would cause the EmailServerContext to raise a TypeError because None is not iterable, and cannot be assigned to two variables.

We now return (None, None) when the test signing fails.

Note: See TracTickets for help on using tickets.