Tetsing on Solaris showed the problem. Now fixed in SVN.

Not quite. It does not work on Solaris when build on a NFS mount.

Fixed in the current SVN.

The problem is that gpg now requires the agent to learn the suggested iteration
count. However, if no agent is running the test fails. The fix is to wait for
2.0.16. It features better support for on-demaning starting of the agent. I
already changed the test environment to make use of this new feature.

Here's the link to the GTK+ 3 transition:

D129: 294_0002-Add-gseal-gtk-compat.h-from-gedit.patch

Compat with older GTK+

D130: 293_0001-Make-DSEAL-safe.patch

This still affects 0.8.0.

1467 has an improved check.

libassuan is a hard requirement for gpgme since version 1.3. And yes, configure
should complain about it.

Let me know if I shall do a 0.8.1 release.

Fixed in the current svn. At least it works for me on Debian GNU/Linux sid and
Debian GNU/kfreebsd sid. The pinentry nows sticks to the the top and you should
not be able to change this - it is in the responsibility of the WM, though. I
am using xfwm.

We did not checked the direct key signature during import. The problem is that
during the import we try to detect duplicate signatures by comparing the
signature but not the signed material. With the bogus signature already in the
keyring, importing a good signature will sort the latter out as a duplicate.

I can't replicate this with pinentry-qt 0.8.0 but still with the gtk2 version
with or without the Debian keyboard race fix.

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

No worries regarding delay - just keen to ensure not over-looked.

I understand (and exactly it is why I do not want use some weak RNG but use
something robust in crytsetup).

No, this would violate the design of the RNG. It is already hard enough to come
up with good random and we don't want to weake it anymore.

gpg-agent won't create a core dump; see disable_core_dump(). However it is
still possible to read the memory of a process you own using ptrace or
/proc/PID/mem.

Duplicate of T1216

Seems to be duplicated in 1216.

No the warning will stay. I will add a comment to show that this is an optional
part of the API.

I see, so there is no immediate action needed and I can release a full
features libassuan 2.0.0 even without this feature, and in a future version
this warning will be gone, right?

I recognise that gpg-agent is a user process - if it wasn't this issue wouldn't
apply at all.
And naturally this won't protect the user from themselves entirely - why if they
wanted, they could even start gpg-agent from gdb and skip the prctl call and
after entering his passphrase could then dump it from gdb. Or maybe they could
use an alternate "gpg-agent" that does not disable ptrace. Or they could wrap
gpg-agent and disable the call with LD_PRELOAD. Hell, if they wanted they could
probably even post their private keys unencrypted on a public webserver.

It is liklely that we remove gpgkey2ssh entirely. It used to be a test program
for the gpg-agent implementation. I never used it.

Sorry, we are very busy these times.
Marcus, if you ahve a bit of spare time, can you please look at it?

The libassuan provides this feature and we don't want to remove it. GnuPG
however does not use it antmore. In fact, in the development branch we are
working on replacing all use of stdio by our estream code which features an
fopencookie like fucntion and thus it will be possible to use features like
logging to sockets aso on system without a native funopen/fopencookie.

You can't protect a user from himself. gpg-agent is a user process and not a
system wide daemon.

Ticket created a month ago and not allocated to anyone.

Traces submitted to Marcus now attached to ticket.

Traces submitted to Marcus now attached to ticket.

Traces submitted to Marcus now attached to ticket.

Tested with different mailer of sender:
An OpenPGP encrypted (or encrypted/signed) email sent by OL2007/GpgOL1.1.1 and
Kontact e35 (GNU/Linux).
Same problem for both emails: OL2007 crashes after opening an attachment.

Still the same problem with gpg4win 2.0.2 (aka GpgOL 1.1.1).

Thanks

That was of course the first thing I checked. I have a udev rule that sets the
permissions. It doesn't work as root either. I also tried to install some
(proprietary, I think, but there was no licence file) Cherry driver from their
website, but this didn't change anything either.

Check the permissions of the the device /dev/bus/usb/.... or /proc/bus/usb - you
need read and write access to the device.

I tried to set cherry_mode to 0 and build GnuPG including gpg-agent and
scdaemon, but I couldn't get it to work nonetheless. Any further ideas?

Right now pld libassussan 1.x uses libassussan1.so.0 as soname:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/libassuan1/libassuan1-
soname.patch

I now tried to disable pcscd and run scdaemon with the debug-ccid-driver option.
It seems scdaemon simply does not find the reader without pcscd:

For the records: What distro is this?

If you are not using gpg-agent and scdaemon, you find that code in in
gnupg/g10/ccid-driver.c. It is also helful to enable ccid driver debugging by
using the option debug-ccid-driver in gpg.conf or scdaemon.conf.

According to the descriptor as shown at
http://pcsclite.alioth.debian.org/readers/CherrySmartTerminalST2XXX.txt
The reader should not suffer from the Omnikey based problem (as the Cherry
keyboards do) because it uses TPDU level exchange.

The card is version 2.0. The USB device ID of the reader (it's not a keyboard,
but only a reader with keypad) is 046a:003e ("Cherry GmbH SmartTerminal
ST-2xxx"). I tried to run gpg --card-status without pcscd running, but then I
got this error: gpg: selecting openpgp failed: ec=6.108

Whoops, that was disto patch it seems. Sorry for the noise.