Hello Werner,
during running gpa --daemon in a shell I can use gpgex without problems. Does
this information help you to solve the problem with kleopatra?
Thanks
Martin

Oh, lost tarck of this one.

Implemented since 1.0.2

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.

Please try to use gpa instead of Kleopatra:

According to T1157 changing the locale does not help.

We need more input to figure out the problems. Please continue at issue#1125;
closing this one.

Duplicate of T1125

Well, should be implemented.

Marcus, please apply

You are using an gpg-agent too old for the used gpg version.
In case you are intrested in what is causing the problems, add the line

debug 1024
log-file somefile

to the ~/.gnupg/gpg-agent.conf and restart the agent. You should see all the
commands traveling between gpg and gpg-agent. It wmight also be on the scdaemon
part; then put the same option into scdaemon.conf.

This is not possible - pinentry is called from a background task and thus needs
a way to take over the current terminal. A simple command line input would be
too easy to fake by data to be processed. If you really want this, please write
your own pinentry.

many releases in the meantime thus I am pretty sure that this has been solved -
at least on the GnuPG side.

2.0.1 has been released quite some time ago. Closing.

2.0.14 released thus closing.

2.0.14 has been released - closing.

2.0.14 has been released, thus I am closing this bug.

We can't do anything about it.
Cards with manufacturer id 5 and serial numbers up to 346 (0x15a) are affected.
Newer cards work fine.

Thanks. Applied to SVN.

According to the error message this seems to be well and the message is probably
the result of a test for an valid UTF-8 char, but the stored file was creadted
from the same copy step via a second paste in the same step.

The content probably contains umlauts or accented characters for example in the
comment line or the text before the BEGIN PGP lines. We currently require the
clipboard to have valid utf-8 (or ascii) characters.

Fixed in 2.0 and 2.1 rev 5238.

Fixed in all branches. rev. 5236. Patch for 1.4.10 below:

fixed in rev 1442, thanks for reporting it

Done in trunk (2.1), rev 5233

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

We need to hook into ondelivery because that is the only way which allows us to
change the message class before OL starts processing it. The change you see is
probably due to more elaborate message checking to catch more cases; in
particular we need to cope with the old-stylish cleartext PGP messages and also
handle other buggy messages here. This requires looking at the message body.

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

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:

Hi Werner,

Hi Werner,