integrate pgpy as a new (possibly default) backend

[hpk42]

There is a separate https://github.com/juga0/pyac effort which implements Autocrypt and is based on https://github.com/SecurityInnovation/PGPy instead of gpg like this repository. Here are a few things i'd like to see before investing myself into trying to merge pgpy support:

• pgpy successfully decrypts all messages in several real-life inboxes (containing pgp-encrypted mail, large and small)

• pgpy successfully encrypts cleartext messages of in real-life inboxes which can then be decrypted properly (with at least some light manual testing if K9/enigmail/delta can process the pgpy-encrypted message)

This encryption/decryption stability with real-life messages is needed for server-side integrations #30, mutt integrations #31 and bot integration #14.

Once this base stability is ensured, the internal API needs to change such that a pgpy crypto module can used instead of the current bingpg.py one. It's likely that people will still need support for storing keys in the gpg system key ring, so we need to have a uniform API for the two modules, independently tested. Eventually it'd be cool if we could use pgpy as a default backend and not require a "gpg" binary for basic Autocrypt operations.

For the record, my own efforts first half 2018 mostly focus around other issues and thus i can only spend very limited time helping with pgpy things.

[juga0]

I'd love to have automatic tests for encrypting/decrypting "real-life" messages. When this is done in py-autocrypt we can do the same in pyac

[hpk42]

testing against real-life inboxes i consider more a question of a custom helper script that walks through all messages and attempts decryption through the respective APIs. I thus don't plan to make it part of the automated test suite.

[hpk42]

Heart from @j08ny that https://pgpy.readthedocs.io/en/latest/progress.html summarizes where pgpy stands. Reading partial-length packets works but writing them does not. For encrypted e-mail processing that's probably sufficient. Now what remains is trying out if pgpy deals well with messages from real-life inboxes. I still want to have more certainty about this before relying on pgpy. As we introduced an account.decrypt_mime and account.encrypt_mime tested helpers recently i think muacrypt API could be used to write a little script to process mbox or maildir messages with not too much effort.