Page MenuHome GnuPG
Create Task
Maniphest T2421

General error after update 2.1.12 -> 2.1.13 on gpgme_op_edit()
Closed, InvalidPublic
Actions

Description

After update from gnupg 2.1.12 to 2.1.13 pygpgme/gpgme/components which uses
those started failing with "General error" and "Bad file descriptor" on
gpgme_op_edit(). Looks like this is not problem of gpgme as I tried 1.4.3 and 1.6.0.

Attaching log which I got by setting GPGME_DEBUG=9

Details

Version
2.1.13

Related Objects

Event Timeline

ignatenkobrain added projects: gnupg, Bug Report.Jul 20 2016, 8:03 PM
ignatenkobrain set Version to 2.1.13.
ignatenkobrain added a subscriber: ignatenkobrain.

862_gpgme-debug.log431 KBDownload

ignatenkobrain added a comment.Jul 20 2016, 8:20 PM

Looks like other folks are experiencing same issues:
https://lists.gnupg.org/pipermail/gnupg-users/2016-March/055421.html

ignatenkobrain added a comment.Jul 24 2016, 10:18 PM

ff71521d9698c7c5df94831a1398e948213af433 is the first bad commit
commit ff71521d9698c7c5df94831a1398e948213af433
Author: Werner Koch <wk@gnupg.org>
Date: Fri May 13 16:24:59 2016 +0200

    gpg: Emit new status line KEY_CONSIDERED.
    
    * common/status.h (STATUS_KEY_CONSIDERED): New.
    * g10/getkey.c: Include status.h.
    (LOOKUP_NOT_SELECTED, LOOKUP_ALL_SUBKEYS_EXPIRED): New.
    (finish_lookup): Add arg R_FLAGS.  Count expired and revoked keys and
    set flag.  Check a requested usage before checking for expiraion or
    revocation.
    (print_status_key_considered): New.
    (lookup): Print new status.
    
    Signed-off-by: Werner Koch <wk@gnupg.org>

:040000 040000 33853092f4376553defb24e39a31bdcbc13c51d2
7da8083e3f39b2fabfe0c3beab0b9f43a2a2cc32 M common
:040000 040000 468469de2419e59efddd718b7b24d5a8cead3005
d2c77b1e1bbab29cd506b29dc359d44c841dbc99 M doc
:040000 040000 044148a54b854a31a0f6ad6605a50a57cc46dfcd
e229f5d63dc27377a7fa1d50ff512a040a389f1f M g10

justus added a subscriber: justus.Jul 26 2016, 10:21 AM

That is not a bad commit, that is Werner evolving our software. pygpgme is unmaintained since

  1. My guess is that it cannot cope with the new status code being emitted by GnuPG.

I ran the testsuite myself, and I can reproduce the issue, among many other failures: 24 if I'm
using the GnuPG components from Debian/unstable, 9 if I am using more recent components.

One of them is test_encrypt_to_signonly, which tries to encrypt a mail to a key only usable for
signing, and expects a general error, which all recent versions of GPGME return in this case, but
this was a bug, fixed in GPGME master, which returns the correct error.

Updating pygpgme is out of scope for us. If you merely need any binding, consider using the pyme3
bindings that we merged into GPGME proper, and will release with 1.7. You can also find it on
pypi, it requires GPGME 1.6.x to build.

The way I see it is that the pygpgme bindings and its test suite are way too unmaintained and the
test suite too noisy to demonstrate a bug in GnuPG or GPGME. Feel free to reopen this bug if you
have compelling evidence that we broke something, preferably a small test case not using pygpgme.

justus closed this task as Invalid.Jul 26 2016, 10:21 AM
justus claimed this task.
justus lowered the priority of this task from High to Normal.
justus removed a project: Bug Report.
ignatenkobrain added a comment.Jul 26 2016, 10:29 AM

how different pyme3 with bindings which we will get within 1.7 release? is there
any ETA on releasing 1.7?

justus added a comment.Jul 26 2016, 11:10 AM

The API of pyme3 is almost identical to that of pyme, the former being a port to Python3,
while the latter is for Python2. We also added a more idiomatic interface on top of that, but
porting pyme applications should be easy. It is different to the API of pygpgme though.

I don't know exactly when 1.7 will be released, but it is overdue, so I'd say next month.