I agree, these are problems we should address, they might be the symptoms of a
race somewhere. I bet they are in GnuPG though.

D369: 860_0001-Core-Add-file_size-support-to-gpgme_data.patch

Since Kleopatra is using data callbacks the total is always 0 so I can't use the
way to calculate percent.

Previously kleopatra used the filesize as total value. This does not work if
total is always 0 and the progress switches based on the current file size. E.g
for a large file the prgress decreases after 1024*1024 bytes have been processed.

I could probably add some weird "if gnupg > 2.1.14 and the file size is >
1024*1024 and the progress is < 1024*1024 expect it to be bytes and otherwise
expect it to be kilobytes." But this is not nice to use API.

My attached patch solves this by giving data callback users the opportunity to
provide GnuPG with the information how much input size it can expect. This makes
total / current workable from the start and everything is fine.

But as we jabbered about you do not like this patch :'-(

Problem not resolved for me as I think the weird handling currently imposed by
GnuPG is definitely not "Easy"

I think that the charset header in the armor is not a good idea. In fact gpg
does not consider it at all. The armor headers are not protected and thus they
should not not chnage the semantics of the encrypted message. There is also no
way to keep this information after removing the armor or to re-create the header
from a binary message.

I consider a new flag for the Literal Data Packet to indicate theat the content
is a MIME message to be better. Standard MIME methods can then be used to
describe the content. Right now we only have an 'u' flag to indicate UTF-8
encoding (which to some interpretation of OpenPGP is anyway the default).
An 'm' flag would make it explicit that the content is MIME encoded and there
would be no more need to derive that info from the context.

I also created a set of examples messages. They are in
gnupg/tests/openpgp/samplemsgs/

interested in this, too. Especially since you always tell me assuan is so easy
to use because it's all in gpgme :-)

Fix for the difference in detection of armored vs. binary detached signatures
was trivial so I've pushed it with rev. 570bf2a

Looks good to me know. I'll start using it in Kleopatra and we will see what
breaks :-)

Have not tested different S/MIME messages yet.

Thanks.

I've created some examples to test it. They are all done with alfa@example.com
test key. Found an issue through that.

-ba (detached ascii armored signature) is detected as PGP-Signed and not as
PGP-Signature.

examples/plain.txt.asc: PGP-signed

A discussion about KMail handling PGP/Inline encodings [1] also makes me wonder
if data_identfiy should also return the output charset of text messages if it is
provided in the Armor Header. Afaik there is currently no API in gpgme to check
this and semantically It would make sense to me to parse this in identify, too.
But this is more of a question wether or not you think it makes sense to do this
directly. I'm not strongly opinionated about this.

1: https://bugs.kde.org/show_bug.cgi?id=248058

Done with commit cf37a57.
Note that only the first 2k are inspected.

Binary PGP messages are now detected. Not well tested but the run-verify test
tool can help to check the feature.

I need to implement a partial OpenPGP parser to decide what a certain PGP
Message is about and also bot all binary OpenPGP files. Please have some patience.

Would it be possible to also detect if data should be decrypt_verified or just
verified?

I'm having trouble with PGP MESSAGES that can be either encrypted or Opaque
Signed, or nothing.

If I do a decrypt_verify I get a No Data error in the result because decryption
failed. Should I just ignore No Data error and check for the status of the
signatures in that case?

poll is not available on all platforms and has other semantics. Thus we will
introduce new bugs. We are planning to move some of the lower level I/O stuff
to libgpg-error and in the course of this we will fix this problem.

Just curious, why can you not start using poll() instead of select()?

We can't easily solve this. For now I pushed a fix to return an error instead
of crashing. (commit 8173c4f). Thanks for reporting.

Do you mean "unusable public key"? That might be due to an expired or revoked
subkey of that key.

No, I'll do a Version check in for the GnuPG Version in Kleo master and I won't
backport any changes to the KDE4 / Gpg4win stable variant.

I'm assigning testing to me, I'll test it by using it in Kleo :-)

Done with commit 6c957c3.
Do we need to backport this?

The best solution I can see is to keep CURENT and TOTAL in gpg below 2^31.

Ok, this would work for me, too.

Actually the specs does not say anything about the valid range of the values.

However, gpg uses unsigned long for CURRENT and TOTAL in the progress status
lines for decryption. Unfortunatley the WHAT value is set to the filename and
thus there is no easy way to determine in GPGME how CURRENT and TOTAL are used.

The best solution I can see is to keep CURENT and TOTAL in gpg below 2^31. This
can be done by switching from bytes to KiB and MiB before the 2^31 limit is
reached. I checked GPA and it should not chnage anything, due to

    gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (pbar),
				   (gdouble) current / (gdouble) total);

CRL detection is not really important. But detection of binary data is so that I
can properly handle .pgp and .gpg file extensions.

Detached signatures are also important so that I can look / guess for the signed
data and setup the verify operation accordingly or handle it in the GUI if no
Data is found. Maybe we can use flags for this so we don't break the current
behaviror that does not distinguish between detached signatures?

Fixed in 4711a1e1.

Quoting Ben McGinnes (2016-05-11 19:54:21)

On Wed, May 11, 2016 at 12:44:00PM +0000, Justus Winter via BTS wrote:

Justus Winter <justus@g10code.com> added the comment:

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

No, simply because other (abandoned) attempts at writing wrappers for
GPGME already exist in the Python ecosystem. If we rename a module to
match the name of an existing one this will break things somewhere.
It also makes us no different from poor Isis Lovecruft who selected
the name gnupg for her fork of python-gnupg, but the original was
always imported as just gnupg so when she increased the version number
of her fork she broke a *lot* of things in other people's code.

That's also why the entirely new thing I've called GPyGME, not just to
play word games with Pygmy, but also because the name is not used by
any existing Python module.

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

• (API) One has to hand 'bytes' objects to pyme where 'char *' is expected. We

should make SWIG magically encode strings as utf-8 instead.

• Documentation. Needs to be build, likely updated, and installed. Ben was

thinking about using another tool for this. Needs investigation.

• No test suite.
• 'lang/python/examples/simple.py' segfaults.

Hmm, it is not about the maintainer mode...

Justus, can you take care of this?

Thank you! All set.

GnuPG 2.1.11 will print PROGRESS lines which allows in connection with
--exit-on-status-write-error to use that correctly. We should add that option
to gpg invocation of gpgme, though.

I've just disabled the unit tests in Kleopatra that expose this bug.
The tests should be renabled depending on a version check for a version of gpgme
where the problems are fixed.

I've searched for the context in question and it turns out the last 1000 lines
are not nearly enough to follow it.

So here is the full log of that run.

I can still see the asserts and segfaults when running the tests in gdb or with
logging enabled. So it's not a heisenbug ;-) (Although I was never able to get a
backtrace from kleopatras unit test. That test passed when running in gdb)

Do you want me to provide you with logs?

Here is an example segfault:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffe50f01700 (LWP 25135)]
0x00007ffff7babfe3 in _gpgme_wait_on_condition (ctx=ctx@entry=0x7fff6c0070e0,
cond=0x6a8844002920, cond@entry=0x7fff6c007f20,

op_err_p=op_err_p@entry=0x0) at wait-private.c:155

155 if (cond && *cond)
(gdb) bt
#0 0x00007ffff7babfe3 in _gpgme_wait_on_condition
(ctx=ctx@entry=0x7fff6c0070e0, cond=0x6a8844002920, cond@entry=0x7fff6c007f20,

op_err_p=op_err_p@entry=0x0) at wait-private.c:155

#1 0x00007ffff7bb3236 in gpgme_op_keylist_next (ctx=0x7fff6c0070e0,
r_key=r_key@entry=0x7ffe50f00ef8) at keylist.c:996
#2 0x00000000004010de in start_keylist (arg=<optimized out>) at
t-thread-keylist-verify.c:62
#3 0x00007ffff798c0a4 in start_thread (arg=0x7ffe50f01700) at pthread_create.c:309
#4 0x00007ffff76c104d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Attached is the corresponding gpgme-log (issue-2092-gpgme-log-1.txt)

Needs to be run under GPMGE_DEBUG but I bet that this well defeat the bug.

Sorry, we can't change the type because that would be an ABI break. Well, on
platforms with sizeof(time_t) == sizeof(long) we could use time_t there but for
the application programmer that does not help because assigning to a time_t var
first will still be required for portability.

You are right that this is a bug because internally we use time_t and at least
for Windows we will evntually run into problems.

Back in 2003 we went with long int because that is on all 32 bit platforms
sufficient to express OpenPGP timestamps which are 32 bit. Fortunately on
almost all 64 bit Unix platforms a long int is 64 bit and would also allow us to
express timestamps after 2106 and avoid ABI problems due to different time_t
like we have with off_t. Later, when we came up with gpgsm we gave up our hope
for a 64 bit time_t on 32 bit glibc systems and started to use a string instead
of a scalar. With 64 bit Windows things got even more complicated becuase tehre
a long is still 32 bit. Thus there is no clear way forward even if we decide to
break the ABI: Use time_t or a string?

With the current gpgme and gnupg master things should be a bit better.

Can you please ask on gnupg-devel for help?

ANy news?

Debug message are for debugging and thus you need access to the source.
I'll see what I can do regarding better error messages for signing.

Ok I found why it did not work on a system:

[pid 6507] write(7, "OPTION pinentry-mode=loopback", 29) = 29
[pid 6507] write(7, "\n", 1) = 1
[pid 6507] read(7, "ERR 67108924 Not supported <GPG Agent>\n", 1002) = 39
[pid 6507] brk(0x7f87645c0000) = 0x7f87645c0000
[pid 6507] write(2, "gpg: setting pinentry mode 'loopback' failed: Not
supported", 59) = 59

This is caused by a gpg-agent running with DISPLAY=... set.

Imho there's room for improvement regarding error messages/trace messages:
'general error' is unusable.
Also all those hex-codes in the tracing with no explanations and pointers to
objects that tell you nothing is not helping.

Werner Koch <wk@gnupg.org> added the comment:

A brief check shows that the pinentry mode is passed to the egine for decrypt
and sign. Please double check your code that you set the pinentry mode for

the

conext before signing. You should also set GPGME_DEBUG=4:/foo/bar/logfile for

a

log.

I found that on some systems it works and on some it doesn't.

working:
ii gnupg 1.4.18-7
ii gnupg-agent 2.1.4-1
ii gnupg2 2.1.4-1
ii libgpgme++2 4:4.14.2-2+b1
ii libgpgme11:amd64 1.5.5-2
ii libgpgme11-dev 1.5.5-2
ii python-gnupginterface 0.3.2-9.1

failing:
ii gnupg 1.4.18-4
ii gnupg-agent 2.1.6-1
ii gnupg2 2.1.6-1
ii libgpgme++2 4:4.14.2-2+b1
ii libgpgme11:amd64 1.5.5-3
ii libgpgme11-dev 1.5.5-3

Tested it on 3 different debian systems.

When doing an strace, I see the following:

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

...ad infinitum

So it looks like gpg2 tries to send more data to gpgme but maybe it
closed the file descriptor? Maybe some timeout?

The trace also speaks about an error but I don't know what the number
means:

GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: enter: r_ctx=0x7ffce1a86a18
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: leave: ctx=0x6a2b40
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_set_passphrase_cb: call: ctx=0x6a2b40,
passphrase_cb=(nil)/(nil)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_set_pinentry_mode: call: ctx=0x6a2b40,
pinentry_mode=4
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_set_passphrase_cb: call: ctx=0x6a2b40,
passphrase_cb=0x4130c0/0x6a6488
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: enter: r_ctx=0x7ffce1a869b8
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: leave: ctx=0x694a30
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_start: enter: ctx=0x694a30,
pattern=9101D24C869F57E712BCB6BC435F59B679A28EB6, secret_only=0
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x694a30, fd
5, dir=1 -> tag=0x697670
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x694a30, fd
7, dir=1 -> tag=0x6977d0
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 0, type_data (nil)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_start: leave
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_next: enter: ctx=0x694a30
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x697800,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x697800,
handler (0x6a3bd0, 7)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = (nil), line = tru::0:1437598451:1438634760:3:1:5
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = (nil), line = pub:u:4096:1:435F59B679A28EB6:1437562181:::-
:::scESC::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
fpr:::::::::9101D24C869F57E712BCB6BC435F59B679A28EB6:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
uid:u::::1437562181::67B02486BE612BD1F799DD1EF250DA9FDB9C601C::pgf test key (pgf
test key) <test@vanheusden.com>:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
sub:u:4096:1:3B7DB05915752DE2:1437562181::::::e::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
fpr:::::::::1D4A144B830EBD875B3A17D73B7DB05915752DE2:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
pub:u:4096:1:435F59B679A28EB6:1437562181:::-:::scESC::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 2, type_data 0x697830
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
fpr:::::::::9101D24C869F57E712BCB6BC435F59B679A28EB6:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
uid:u::::1437562181::67B02486BE612BD1F799DD1EF250DA9FDB9C601C::pgf test key (pgf
test key) <test@vanheusden.com>:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
sub:u:4096:1:3B7DB05915752DE2:1437562181::::::e::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
fpr:::::::::1D4A144B830EBD875B3A17D73B7DB05915752DE2:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_next: leave: key=0x697830
(9101D24C869F57E712BCB6BC435F59B679A28EB6)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_release: call: ctx=0x694a30
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call: data=0x697670,
setting fd 0x5 (item=0x6976a0) done
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call: data=0x6977d0,
setting fd 0x7 (item=0x697800) done
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_signers_clear: call: ctx=0x6a2b40
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_signers_add: enter: ctx=0x6a2b40,
key=0x694bc0 (387FB9C2DE84B200436962A0207A035AD316FA65)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_signers_add: leave
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_encrypt_sign: enter: ctx=0x6a2b40,
flags=0x1, plain=0x695240, cipher=0x696290
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_encrypt_sign: check: ctx=0x6a2b40,
recipient[0] = 0x697830 (9101D24C869F57E712BCB6BC435F59B679A28EB6)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_sig_notation_get: call:
ctx=0x6a2b40, ctx->sig_notations=(nil)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x6a2b40, fd
5, dir=1 -> tag=0x693e10
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x6a2b40, fd
9, dir=1 -> tag=0x693f70
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x6a2b40, fd
12, dir=0 -> tag=0x693fd0
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 0, type_data (nil)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
handler (0x695240, 12)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: enter:
dh=0x695240, fd=0xc
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
handler (0x695240, 12)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: enter:
dh=0x695240, fd=0xc
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call:
data=0x693fd0, setting fd 0xc (item=0x694000) done
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
handler (0x696290, 9)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: enter:
dh=0x696290, fd=0x9
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
handler (0x696290, 9)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: enter:
dh=0x696290, fd=0x9
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_cancel_with_err: enter:
ctx=0x6a2b40, ctx_err=117440513, op_err=0
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call:
data=0x693e10, setting fd 0x5 (item=0x693e40) done
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call:
data=0x693f70, setting fd 0x9 (item=0x693fa0) done
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 1, type_data 0x7ffce1a86910
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_cancel_with_err: leave
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_encrypt_sign:178: error: General
error <GPGME>
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_release: call: ctx=0x6a2b40

Huh?
GPA uses GPGME and allows to delete and import keys.

A brief check shows that the pinentry mode is passed to the egine for decrypt
and sign. Please double check your code that you set the pinentry mode for the
conext before signing. You should also set GPGME_DEBUG=4:/foo/bar/logfile for a
log.

Did an strace (with fork-follow) of my code and saw the following:

The first is a sign + encrypt:

[pid 19904] execve("/usr/bin/gpg2", ["gpg2", "--enable-special-filenames", "--
batch", "--no-sk-comments", "--lc-messages", "C", "--lc-ctype", "C", "--status-
fd", "4", "--no-tty", "--charset", "utf8", "--enable-progress-filter", "--
display", ":0.0", "--encrypt", "--sign", "--always-trust", "-r",
"E96F346A94A761F898F9DA35D8CD7D21B2A93EF9", "-u", "D8CD7D21B2A93EF9", "--
output", "-", "--", "-&7"], [/* 30 vars */]) = 0

The second is a decrypt:

[pid 19907] execve("/usr/bin/gpg2", ["gpg2", "--enable-special-filenames", "--
pinentry-mode=loopback", "--no-sk-comments", "--lc-messages", "C", "--lc-ctype",
"C", "--status-fd", "4", "--no-tty", "--charset", "utf8", "--enable-progress-
filter", "--display", ":0.0", "--command-fd", "5", "--decrypt", "--output", "-",
"--", "-&9"], [/* 30 vars */]) = 0

Now the decrypt does a --pinentry-mode=loopback while the sign, which also
requires password interaction, does not!

I had not. But when I do:

2015-07-10 12:10:07 (gpgme_test) my_key: D8CD7D21B2A93EF9
encrypt: 0
error: gpgme_op_encrypt failed: General error (117440513)

folkert@travelmate:~/Projects/PGF/trunk$ cat ~/.gnupg/gpg-agent.conf
allow-loopback-pinentry