For diagnostic reasons: could you try with Kleopatra as well?

Thanks for asking again, I did not remember that GPGex was missing from the
compendium.

It works similiar to GpgOL, see
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gpgex.git;a=blob_plain;f=README;hb=HEAD
and in German:
http://lists.wald.intevation.org/pipermail/gpg4win-users-de/2013-
August/000593.html

Hi Henning,
thanks for your feedback on Gpg4win and of trying the new Gpgex.

Can you help us further by trying to get some more diagnostic output?
See the link in the last section of http://gpg4win.org/reporting-bugs.html

Best,
Bernhard

For completeness, this fix has been published as part of the regular Gpg4win
releases since 2.1.1-beta1. It is also included in 2.1.1. There is no need to
download the dll directly, just move to the recent Gpg4win version.

I strongly suggest to have an official recommendation how to solve this issue.
The currently available information does not help packagers and application
developers enought to get it right. Probable most distributions should prevent
gpg1 and gpg2 to be installed with their dependency handling.

I agree with Ralf that we need a solution for this.
I can be a multi-step solution.

But right now, most GNU distributions are not putting much effort in
the GnuPG installation and setup help. For example: With Debian squeeze
you cannot deinstall gpg1 because the dependencies would drag down other
software. Yes, this is partly a packaging problem with should be solved on
Debian's side (as well), but if we want GnuPG to be successful we need to offer
users and packagers best practice and clear recommendations.

My suggestions:
a) Make the suggestions more clear that gpg2 only should be recommened only in
almost all installations
b) offer some safety nets if there are both installed and gpgconf is used.

I agree that adding a better message is helpful.
What about something along the lines that says:

"cannot sign with or decrypt with key XYZ"

and explaining:

  "even when trying to decrypt with a different key, 
  the default signature key gets checked."

Certainly it would be much better if decryption would just try to
decrypt with the available keys, no matter of what status the
certificates to this or other keys are. I am worrying most about the
applications that are using Gnupg in this way, they probably will
not be able to either explain this properlto user or offer good
assistance. The reason you give why this is done is only an implementation
artifact and not logical for a user that has learned or tries to learn
about public key cryptography.

Without a real example file, I don't think that the problem can be
reproduced. Thus I'm closing this issue because of the lack of activity
for more than 12 months.

Matter: Thanks for the report! As Werner suggested: Please ask on the
mailinglist if you continue to have problems, until we can somehow produce a
test case and then somebody is able to file a new report.

Thanks for the answer.
What is the solution right now?
Not use libgcrypt 1.5.0 with GnuPG <= 2.0.17?
Or patch GnuPG?

Tested System was Debian Lenny, XEN Instance.
Used command was

gpg2 -b testfile.txt

Dirmngr 2.1.0-gitde7cfc0 also stays active.

Testing the fix:

Werner, where is the patch for dirmngr 1.1.0?
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/?root=Dirmngr only goes up to rev346,
while you say rev347 has the fix. Maybe a missing sync on the svn repositories
on your part?

Haven't had a chance to test it, I was somehow waiting for a new release.
Just made sure I get a 1.1.0 patched package to test next.

Testing pinentry-qt Version: 0.8.0.svn234-0kk1 (the changelog indicates
that the change is in) on Debian Lenny with KWin from KDE 3.

It is okay for one request to take a long time or possibly even to block.
But it is not okay, if other, simultaniously made requests are blocked to wait
for this slow request. Especially if those parallel requests could be answered
easily and quickly, like ping.

To me this, issue makes dirmngr unsuitable as a system service
and it currently allows denail of service attacks on gpgsm based email
applications.

Hmm thinking about this, it is almost like a denail of service attack, because
dirmngr will block other clients.

Should probably beretested with Gnupg 2.1(beta or later)
because agent startup might have changed.

• Weitergeleitete Nachricht ----------

Datum: Montag, 26. Juli 2010
Von: Sebastien Lumineau <sebastien.lumineau@ac-grenoble.fr>
An: "g10 Code's BTS" <gnupg@bugs.g10code.com>

I believe we have two seperate issues
here, though of course they might be caused by the same defect.

There is also an T1251 (GPGOL creates broken attachments in Outlook 2007)
about creating encrypted messages. I believe we have two seperate issues
here, though of course they might be caused by the same defect.

Resolved after adding info to T1110.

Am Freitag, 23. Juli 2010 23:59:41 schrieb Sebastien Lumineau via BTS
issue1257:

I confirm that critical issue in Win7. Here is my config:

Windows 7
Outlook 2007 + MO SP2 (do not work without SP2 ether)
Gpg4win 2.0.3
GnuPG 2.0.14
GpgOL 1.1.1
GPA 0.9.0

Message body is decrypted correctly while there's no way to handle
attachment: try "view, open, save as" crashes outlook.

Duplicate of T1110

D116: 298_pinentry-qt-fix-1162.diff

Am Dienstag, 8. Juni 2010 12:29:40 schrieb Marc Mutz:

so I've attached the diff to current
pinentry SVN here. Works for me. Kwin/qt3 from etch for Qt3-version,
Qt-4.4.3 (self-compiled) + kwin/qt3 for Qt4-version.

The docs say on some X11 WM's, this flag will have no effect when not also
WX11BypassWM is passed, but the latter robs pinentry of it's title bar and
borders, so I left it out.

Werner, again see my tests with Kwin (default windows manager of KDE).
I believe that we should solve the issue for very common window managers.
KWin is very common for pinentry-qt3. Maybe we can ask some KDAB folks for help
on this one, should not be that hard I guess.

Might be related to T1203 (gpg-agent/pinentry does work on certain ttys
(/dev/pts/?)) so it should be checked if the number of tty has an influence
on the symptoms.

Testing pinentry Version: 0.8.0.svn231-0kk1
with window manager kwin from kdebase Version: 4:3.5.9.dfsg.1-6+lenny1.

(this is a regression we should fix for the customers.)

Just for completeness doing a

GPG_TTY=$(tty)
export GPG_TTY

http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/dirmngr.texi?rev=334&root=Dirmngr&view=markup
@node Dirmngr Protocol
still misses LOADCRL and others as far as I can see.

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.

There is GpgOL 1.0.1 coming with Gpg4win 2.0.1. Can you give that a try?
Please also state the precise version of Windows and Outlook you are using.

Werner or Emanuel, any updates on this issues?
Still reproducable witn 2.0.1 (aka GpgOL 1.0.1)?

BTW: There is another short old report about exchange problems here:
http://wald.intevation.org/forum/forum.php?thread_id=624&forum_id=20

seems related to the use of --enable-hmac-binary-check