Fixed today, thanks.

Fixed today, thanks.

Seems to be fixed in gpg4win 2.1.0

Clearly gpgsm outputs to stdout and gpgconf is confused by that.

There is a configure check now. I am still not happy that we sleep at all, but
thats a bigger issue.

I merged it into gnupg where dirmngr now resides. The cs.po file there is
probably out of date anyway though and may need some massaging.

I can not reproduce this on Snow Leopard, I guess it has been fixed in the meantime.

Scute 1.2.0 is very old. It should be fixed in 1.4.0.

FWIW, pth_connect is part of the regular interface.

Hi Bernhard,

fixed in rev 1442, thanks for reporting it

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

I don't think it is wise to change results returned from the backend engine too
much in GPGME. It makes it more confusing to see what's going on by giving
different results for essentially the same operation.

I have not tried with differnt volumes, but the current gpg4win release works
fine with regards to admin and normal user. Harry, can you please test if this
is still an issue, or if you have moved on from Windows 2000, I will just close
the report.

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

I put it in (r213)

This is way too old a report to act on it, so I close it. If you still have
issues with the latest gpg4win, please file a new report.

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:

2009-04-02 Till Adam <till@kdab.net>

I don't see a reason to apply the patch, there are no po files generated for
pinentry. Is this to sync our copy of gtksecentry of another project? I
checked krb5-auth-dialog in Ubuntu, and it does not have this patch.

Quite right, claws actually does invoke AC_SYS_LARGEFILE.

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.

Thanks, I put it in (rev206).

In GPGME, I made some changes to libassuan to avoid the need for sleeping in all
asynchronous cases (these have yet to be backported into libassuan proper). The
only place where it is left is process_request, which is supposed to be
synchronous. But I wonder if process_request can't do with just setting the
socket to blocking (if it isn't already).

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.

I put in a patch similar to that (g_malloc0 was now unnecessary, and I left in
the GMALLOC_SIZE macro). Thanks for taking the time to reporrt this.

Thanks for the report, I removed the dead entry. allow-pka-lookup was changed
into a verify option quite a while ago. Fixed in rev 5010:

The right way to delete an option is:

fixed, thanks!

Ok, I can understand that now if you use GPGME 1.1.5. This was fixed a long
time ago:

I can not reproduce this. Can you please run this with a gpgme library with
debug symbols so we get a full backtrace out of valgrind?

In my case the actual key is on an openpgp card. That may explain the
difference we are seeing.

quite right, I didn't check the code. I guess this can be closed then?

The links don't work from the Internet. Closing the report.

Link works now.

Resolved.

Fixed.

I think this is resolved.

Closing this ancient report. What's a netscape?

Done, thanks for your help.

Could be the installation to H. In the last 2.5 years we fixed many bugs that
could have caused this. We should test this with current versions and close if
not reproducible.

There is still the issue that one might in some circumstances use a different
XAUTHORITY, and it is not passed through.

This bug is discussed at:

The first version of dirmngr that worked on any Windows reasonably well is
1.0.2. Versions before that had a multitude of issues, so I am closing this
report. If there are particular problems with current dirmngrs on 64 bit Vista,
please report them with the appropriate level of details.

With current SVN you get at least a proper error message. Could be done better,
though: We should probably have only one button for verify+decrypt that does
always the right thing.

GPGME has now been thoroughly tested in a multi-threaded environment (Kleopatra
on Windows), and it seems to survive. Closing this vague report.