Oops, I accidentially deleted iwm's message accompanying the attachment when
trying to remove my own duplicate. Sorry for that. Here is his original
message in full, you can also find it at:

Hi iwm,

AC_HEADER_TIME is only useful if sys/time.h and time.h shall both be included,
but sys/time.h includes time.h already *and* time.h is not protected against
double inclusion.

Marcus can you please check whether we should use AC_HEADER_TIME and see what
header to include for time.h. Our requirement for unistd.h is just fine: any
toolkit aiming for at least a bit of POSIX compliance should come with one.

Fixed for trustlist_next as well.

Daiki Ueno confirms this fix but asks whether this is also needed for
trustlist_next.

I think that is fixed in revision 1183 with this change:

I am running FreeBSD 4.8-RELEASE. It is running on a Intel Celeron 900MHz
Gateway computer. I have gnupg-1.4.5 and gpgme-1.1.2 installed from source.

Thanks for the logs. Unfortunately, they don't reveal any secrets. The errno
35 is bogus, because the write() succeeded, so errno is not valid.

I have uploaded to files. 139_bad and 139_good. 139_bad is a log when BADSIG
is returned and 139_good is a log of the same message that return a good signature.

Thanks for reporting this. There are a couple such issues where gnupg does not
issue an error message, and thus the operation will silently fail in GPGME as
well. In the past there used to be some heuristics in place which tried to
catch such situations, but they were causing other problems, so they were not
much of an improvement, and for 1.x I removed most of them.

I fixed this in CVS. Thanks for reporting it!

Might this be the reason that we somewhere have a complaint on Sylpheed eating
up the memory?

D29: 90_gpgme_log_errno.patch

Hi Michael,

What level of GPGME_DEBUG do I need to use to get the output you are looking for?

That is because as a Provisional User (which is the default) he can only comment
on his own bugs. Michael: I have set you to regular user, so you should now be
able to comment.

The reporter of the problem in S-Claws bugtracker, Michael Hughes, registered
here (mdh) but he says he can't comment on this issue. Anything he could do?

That's really weird. Maybe the user could expand the DEBUG output that prints
the -1 return from write() to also print the strerror (saved_errno) to see what
the failure is (this should really be in there, but I didn't yet get to clean up
the debug output to be more informative).

Hopefully fixed with this change, but I can't test it:

Today, all checks passed. Without further information about the gpgsm version
used, we can't do anything about it. Closing the report.

Closing this report. No feedback for a year, and no similar reports.

This is by design. In general a standard location is the best
solution. However for testing etc a way to override it is usefule.
Thus we still support gpgProgram to locate the gpg binary.

Not a bug and no reason to change it.

We have by now created the gpg4win project, which contains binaries not only for gnupg and gpgme, but also for a couple of other packages. Please see www.gpg4win.org. Unfortunately, it is not easy to extract just the gpgme DLL from the package, but it is automatically installed if you install gpa or sylpheed. Not sure if this is sufficient for you.

Thanks for the report.

Andreas, can you please try out the current GPGME CVS version, either HEAD or the 1-0-branch? There was a problem that could under some circumstances stall or hang GPGME, because it would call read() on a non-readable file descriptor. You want this change:

The bug is against very old versions of GPGME. The key
cache has since been removed entirely.

Marcus, please check this.

libtool problem. No responses for 3 months.

We won't do that for security reasons and due to other ways
of providing a passphrase (cf. gpg-agent,
gpg-preset-passphrase). No reponse for 3 months either.

Another way to use make use of an environment variable is by wrtinig an appropriate passpharse callback for gpgme.

Outdated versions and no more responses for 3 months.

Outdated versions and no response for a year.

No confirmation of fix for 3 months, so closing

Cryptplug is discontinued. Kmail now accesses GPGME directly.
Thanks for your contribution!

I think those problems have been fixed in the meantime. Can you confirm that using the latest version? Thanks.

Is this still an issue for you with the latest versions of everything? If yes, please provide the config.log file and relevant output.

Do you think gpg-agent and its passphrase-caching is adequate? You can even pre-store the passphrase on startup and never expire it. I think this is a much better solution. Please let me know if you still see the need for this feature given the superiority and completeness of gpg-agent.

I think the first problem - missing -Wl, must be reported to the libtool maintainer, and fixed in libtool proper. Then if you let us know which version of libtool fixes it, we can update the included libtool and bump up the libtool requirement.

This was fixed in GPGME 1.0.1. Thanks for your contribution!

Upgrade to a stable version