remove pgpy support, point to pyac (separate pgpy effort)

[hpk42]

• there is a separate "pyac" effort aiming for implementing autocrypt
  with pgpy https://github.com/juga0/pyac and it probably makes
  sense to try merge/converge between the two efforts once pgpy is
  usable and stable enough there.

• the tests on py27 are currently broken due to the
  long pending issue new version of six (1.11.0) breaks pgpy with python2.7 SecurityInnovation/PGPy#217

• this autocrypt repository is not going to drop the dependency on
  and default of gpg or gpg2 any time soon (stability, missing keyring support)
  and there are a number of upcoming refactorings where i'd like to avoid
  having to refactor unused code (which anyway seems further developed with pyac)

[juga0]

It makes sense to me to remove pgpy here if pyac is not going to be merged any time soon and then it also looks good to me the PR.

If both projects are going to be merged soon, it'd make more sense pyac get reviewed and the code that uses pgpy here be replaced by pyac.

Note that so far, pyac is not even included in autocrypt organization just because i don't think we have a policy for that.

As a separated question that i'm not sure were should be formulated. Should it be included?

there is a separate "pyac" effort aiming for implementing autocrypt
with pgpy https://github.com/juga0/pyac and it probably makes
sense to try merge/converge between the two efforts once pgpy is
usable and stable enough there.

Can we point out were pgpy is not stable enough in the context of py-autocrypt?

the tests on py27 are currently broken due to the
long pending issue SecurityInnovation/PGPy#217

pyac dropped support for py27, so that bug (3 months old) doesn't affect pyac. Is there any reason to support py27 in py-autocrypt or pyac?

this autocrypt repository is not going to drop the dependency on
and default of gpg or gpg2 any time soon (stability, missing keyring support)
and there are a number of upcoming refactorings where i'd like to avoid
having to refactor unused code (which anyway seems further developed with pyac)

If py-autocrypt and pyac are going to be merged, gpg(2) dependency should then stay.

I'd wait for others opinion on this.

Thanks.

[hpk42]

thanks for your review and comments. a few reply points:

• I tentatively consider py27 support still neccessary as not everyone is using latest distributions which carry python3.5. pgpy has not released py27 support despite new version of six (1.11.0) breaks pgpy with python2.7 SecurityInnovation/PGPy#217 being open for a couple months.

• stability of pyac depends on pgpy and there still is at least the partial body length issue (Support partial body lengths SecurityInnovation/PGPy#95 ) along with other issues referencing it. Not sure how much it's a real-life issue but i'd think it is. In any case, ti'd like to see someone trying out pgpy decryption/encryption with all mails from real-life large mailboxes -- my interest in pgpy is currently not high enough to do that myself, compared to many other missing things in py-autocrypt. are you or is anyone using pyac for an actual personal mail setup? Using gpg does not carry this real-life check burden as much because gpg/gpg2 are the baseline when it comes to current pgp encryption.

• for projects i am participating in maintainig and developing i want to have good test coverage, also of the command line invocation and it seems pyac does not have that. btw, my test run both with tox and with direct pytest on py35 yielded errors, i opened an issue tox fails when using python < 3.6 juga0/pyac#1

summary: My priority with python autocrypt development lies with getting a stable tested package that i can use myself and others can and do use reliably for their own mail autocrypt integrations.

Maybe it's time for py-autocrypt (and other autocrypt implementations) to move out of the autocrypt organization. see also autocrypt/autocrypt#320 .

[juga0]

I tentatively consider py27 support still neccessary as not everyone is using latest distributions which carry python3.5.

ok, i guess we don't have a way to "measure" this

stability of pyac depends on pgpy and there still is at least the partial body length issue (SecurityInnovation/PGPy#95 ) along with other issues referencing it.

ok, this seems then this is the main issue for you with pgpy. See below

Not sure how much it's a real-life issue but i'd think it is. In any case, ti'd like to see someone trying out pgpy decryption/encryption with all mails from real-life large mailboxes -- my interest in pgpy is currently not high enough to do that myself, compared to many other missing things in py-autocrypt. are you or is anyone using pyac for an actual personal mail setup?

I don't think so, just because pyac is not a MUA. Same reason why i'm not using either py-autocrypt. If there's a way to easily plug-in py-autocrypt to MUA, it'd be the same for pyac and i'd be happy to hear how.

I thought that py-autocrypt was not inteded to be an "end-user" ready tool, but rather an "example" implementation for developers. Am i wrong?.

Using gpg does not carry this real-life check burden as much because gpg/gpg2 are the baseline when it comes to current pgp encryption.

Right, the downside is to have to mantain yet another gpg wrapper.

for projects i am participating in maintainig and developing i want to have good test coverage, also of the command line invocation and it seems pyac does not have that.

Yeah, it's a matter of implementing more tests. pyac is not finished and i was waiting to see if there was any interest on it to continue or not with it.

btw, my test run both with tox and with direct pytest on py35 yielded errors, i opened an issue juga0/pyac#1

Thanks, i'll have a look.

summary: My priority with python autocrypt development lies with getting a stable tested package that i can use myself and others can and do use reliably for their own mail autocrypt integrations.

See question above.

[hpk42]

i'd like py-autocrypt to integrate with my own mutt mail setup to seemlessly handle my encryption/decryption instead of the cumbersome current mutt/crypto stuff in my config, and also as something that can be used for server-side software that so far only does clear-text mail handling (e.g. mailman3), so doesn't have its own crypto facilities that py-autocrypt could make use of. py-autocrypt also does not implement crypto itself, but delegates it to gpg (a common approach with many MUAs) so integrating with that seems like a safe option. I'd feel uneasy advertising a library like py-autocrypt as an example L1 compliant implementation if i wouldn't use it somewhat for real (even if mutt has a limited userbase, i did get questions from serveral folks at 34c3 for how to do it).

[juga0]

I think mutt integration does not have anything to do with removing pgpy support (title of this PR).

[hpk42]

my previous comment tried to answer your question "I thought that py-autocrypt was not inteded to be an "end-user" ready tool, but rather an "example" implementation for developers. Am i wrong?.". I indeed use py-autocrypt for my setup and others consider it too, so it's not just an example implementation and that means that its crypto integration needs to be solid, process real-world stuff. See also what i posted with #32 related to the same topic.