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

Asg: send me an email saying:

Asg, could you test 2.0.1rc1?

Just for completeness, there have been more fixed in dirmngr
and the symptom seems to also have happened because an http proxy
behaved
strangely.http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/crlfetch.c?root=Dirmngr&rev=323&r1=320&r2=323

Werner needs to try something to make sending MIME emails with Exchange
for the first time.
(So this problem will still be in 2.0.1rc1.)

Asg, could you test 2.0.1rc1?