1467 has an improved check.

libassuan is a hard requirement for gpgme since version 1.3. And yes, configure
should complain about it.

Marcus, can you please take care of this.

D124: 282_gpgme-ctx-nullfix2.diff

Marcus, plase have a look at it.

D122: 280_gpgme-callbacks-example.patch

Marcus, please add a note that the GnuPG documentation is the only specification
for key parameters. And change the example so that it works with the new
default feature of gpg.

Ah right. Apologies for my ignorance.

Anyways, I can provide a gpgme trace at level 9 if you consider it necessary.

Hello Werner.

Frankly, I can only guess what you are doing. Is that a seahorse action to add
another user id or an existing key? A backtrace does not help at all here.

Marcus, not yet so far. I would appreciate a test on your end, as I might not
get to the issue for a while. There should be enough information to reproduce
the issue.

Hi Bernhard,

ping

Please give a detailed report, I can't do much with the brief comments in your
repo. Note that gpg1 and gpg2 are slighly different and thus in corener cases
you may get different error codes.

fixed in rev 1442, thanks for reporting it

Closing the report, if it is still an issue it can be reopened.

I've tried to reproduce the fault with 1.2.0 but could not so it seems to be
fixed.
Thanks.

Is there any way we can make process on this one? Is it still an issue?

I think that this is probably fixed in the gpgme 1.2.0 release. The following
patch by Werner has a similar effect to the patch provided by the submitter:

Why "make it fail"; why not "make it run"?
I guess (did not test) that the bug can be fixed by replacing

#if @NEED__FILE_OFFSET_BITS@

with

#if @NEED__FILE_OFFSET_BITS@ - 0

or by making configure always setting a nonempty value;
depending on your preferred style of programming.

Marcus, please make it fail more gracefully.

Is there any chance of getting this fixed? The problem is very annoying as it
causes the library to disturb the application using it and I can't think of any
simple workaround for it.
The patch is just three lines so it should be easy to include, right?

It's more complicated, as the same code works when engine is set explicitely to
gpg2 but the gpg1 engine return a no error data.

You passed no data to the fucntion. Please ask on gnupg-users for help.

Marcus: I recall that you recently changed something in the cancel code - is
that his problem?

D102: 246_gpgme-1.1.8-closefiledescriptor.patch

Quite right, claws actually does invoke AC_SYS_LARGEFILE.

Sorry, typo in the URL, (there was one "kolab/" too much, but you could have
gotten to it via the main page. :) )
https://www.intevation.de/roundup/kolab/issue3583 (offline s/mime signing
without CRL for secret key gives unkown system error)

Sorry for the delay. I can not access the kolab tracker (404), has the link
changed? Errors for individual keys in a keylisting are not available in
detail, but only the invalid flag is set. When using an invalid key, a more
detailed reason may be available. There is currently no way to get more
detailed reasons about why a key in a key listing is invalid.

I see. Your plaintext needs to be zeroized after decryption and processing by
you. gpgme does not directly support this. What you can do for data objects
hold in memory is:

Forwarding for Bill.

Wrong title. It is not that the password is visible but that the clear text
from the gpgme_opt_decrypt function is visible. Another developer with more
knowledge of the scenario in this issue will respond shortly.

static int scrub_stack()
{
char arr[8192];

So you are using the passpharse callback of gpgme and don't make use
ofgpg-agent. In that case you need to take care of zeroing the passphrase.
gpgme has no provisionhs for this because the passphrase callback is a feature
obnly useful in certain environments. gpgme_data_t has nothing to do with
passpphrases.

I will have access to a MacOS system soon and will take care of ttyname_r then.
Leaving this open as a reminder until then.

Marcus, I think we can close this now.

Marcus, can you please have a look at this?

I looked at the code and it seems that you assume that a setuid(2)
changes more than just the UIDs of the current process. In particular,
you assume that environment variables change - that is not the case:
Like any envvar HOME does not change by calling setuid() or any other
system function. To change the envvars, your code needs to do this.

fixed, thanks!