I meant to write DSO (shared library).

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)?

ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-1.0.5.tar.bz2 has libassuan.so.0
ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.0.tar.bz2 has ALSO
libassuan.so.0 (while it should be libassuan.so.1 (aka incremented soname))

2.0 is the first SO. There has never been a libassuan.so with version 1.x.

As said, I already implemented this. See T1201 (wk on Mar 12 2010, 06:17 PM / Roundup).

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.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20100317 16:00]:

Werner Koch <wk@gnupg.org> added the comment:

What pinentry version are you using (qt or another one)?

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.

What pinentry version are you using (qt or another one)?
Did you set the GPG_TTY envvar?

D127: 286_long-long-thumb.patch

Obviously not. If someone uses such a filename, it will of course be shown.

Obviously not. If someone uses such a filename, it will of course be shown.

There is no RFC. Hal merely posted a notice how PGP implements an Outlook
kludge. OTOH, PGP/MIME is a logn standing standard (rfc3156).

talking about the old 0.9 versions - they are not any longer maintained. Sorry.

Meanwhile I commited a fix to not encode these special filenames.

gpgol does not use the partioned format - it implements PGP/MIME. If you are
talking about the old 0.9 versions - they are not any longer maintained. Sorry.

Meanwhile I commited a fix to not encode these special filenames.

BTW, what version of GPA or Kleopatra are you using?

This is not a gpgex bug but one of GPA or Kleopatra. They set the filename to
be included.

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

Marcus, can you please take care of this.

D124: 282_gpgme-ctx-nullfix2.diff

D125: 281_gpgme-ctx-nullfix.diff

Fixed in all active branches with SVN revision 5264.

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:

Marcus, plase have a look at it.

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

D122: 280_gpgme-callbacks-example.patch

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

Marcus, please add a note that the GnuPG documentation is the only specification
for key parameters. And change the example so that it works with the new
default feature of gpg.

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.