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.

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.

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

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.

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.

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

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.

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?

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:

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

BTW, to use the keyboard's integrated PINpad you need to use GnuPG's internal
CCID driver and not pcscd.

Old or new card (v1.1 or v2.0)?

Continued testing has shown that this behaviour is only exhibited when
using standard sockets. When not using them I have, so far, been
unable to replicate this problem.

Thanks for asking. ARM Thumb is a separate instruction set within the ARM CPU. The
charachteristics are that each instruction is 16bit (instead of 32bit of a classical RISC
design). The basic idea is that with smaller instruction size, the binaries are smaller, the
"i-cache" magically has more room for them...

Please give me short explanation what the thumb mode is and under what
circumstances it is used.

D127: 286_long-long-thumb.patch

D126: 284_clear_passphrase.patch

Thanks.

The patch seems working

Sorry, I mixed that up with something else. It is indeed a bug in 1.4.10 but
not in the current 2.0 code. I developed a fixed for this which detects a v1
card and forces sha1/rmd160 only in for these cards.

D123: 283_bug1194-fix.diff

Thanks.

That is not a bug. If you are interested in learning more about this, please
search the ML archives or ask on gnupg-users.

From the user's view, I would say this is still a bug, no matter how complicated
it is to be fixed. :)

Given that the FAQ is entirely out of date, I will add this to the BUGS section:

You may disagree but it is a matter of fact that changing this is quite troublesome.

Thank you for your reply, werner, but I disagree with you on this.

1.0.0 is not supported and long outdated. Even the 1.2 version has reached end
of life a couple of years ago. DO NOT USE THESE OLD VERSIONS. You should also
not use --cipher-algo etc. options if you are not sure what they do - please
read the manual.

This is a different thing. 644 is about serialization of pinentry pop ups.

In card edit it is:

Changed in all branches (svn rev 5256).
The prompts are now:

Just for completeness doing a

GPG_TTY=$(tty)
export GPG_TTY

There is further a grammar:

Taking a look at the code, it would require to adjust