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

For the records: What distro is this?

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

I meant to write DSO (shared library).

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.

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.

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

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. :)

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.

I am sorry but this is really misfeature rather than a feature. So you basically
say, that if caller of libgcrypt does not want to having it mess with uids and
capabilities it has to copy over about 600 lines from the secmem.c just to
delete the few calls?

This is not a bug but a feature. If an application does not want this behaviour
it needs to register its own allocation handler.

You want see those '-' because gpg detects them after removing the ascii armor
(base 64 encoding). The ----END line is part of the ascii armor and thus not
relevant for gpg. You may strip the ascii armor yourself by using "gpg --dearmor".

You are using an gpg-agent too old for the used gpg version.
In case you are intrested in what is causing the problems, add the line

debug 1024
log-file somefile

to the ~/.gnupg/gpg-agent.conf and restart the agent. You should see all the
commands traveling between gpg and gpg-agent. It wmight also be on the scdaemon
part; then put the same option into scdaemon.conf.

We need to hook into ondelivery because that is the only way which allows us to
change the message class before OL starts processing it. The change you see is
probably due to more elaborate message checking to catch more cases; in
particular we need to cope with the old-stylish cleartext PGP messages and also
handle other buggy messages here. This requires looking at the message body.

Hi Werner,

Hi Werner,

ok, please enable s/mime support by default for next release.

It can't do that for technical reasons. We should enable S/MIME support by default.

As time permits I should be able to check this out myself. Actually I will need
to do this because Iswitched to a kreebsd kernel on my laptop with a cm4040.
FWIW, I received the Design and Implementation of FreeBSD today.

When using GnuPG2 you need to add the option to ~/.gnupg/scdaemon.conf.

Note that I am talking about gnupg2, which does not have this option, at least
it says

I close this issue, thanks again

I can now make gpg key backup during generated key directly on the opengpg V2
smartcard.

Okay - So I installed as you specified. Upon running and creating the key and backup of the
key I had another error that called my VS debugger. I'm not very current on assembler so I have
attached the output trace in a text file.

Well that is gpg4win ;-).

I've forgotten, just for your information, I've no cherry or omnikey support
request answer at this time.

I've said that on T1094 (tsndcb on Jul 30 2009, 12:35 AM / Roundup), when I generate directly my keys by the smartcard, It
ask me if I want to backup it, if I answer yes => failure (and no generate keys
are done), If I answer no, my key are generated but I've no keys backup.

I am not sure I understand this. Do you mean a failure while writing an
off-card generated key to the card? That is fixed with 03-opgp-writekey.patch .

Do you've also a patch for backup failure when generate key on smartcard ?

I have not seen that card yet. Thus I can't tell.

I've done a support request to cherry and omnikey, but actually I've no answer
about it ... :-(

I'd say the problems are due to the Cherry XX44. We need to contact the vendor.
I'll try it again this week.

I see. Your plaintext needs to be zeroized after decryption and processing by
you. gpgme does not directly support this. What you can do for data objects
hold in memory is:

In fact, with more tests, I can't read on Windows XP my keys generated on my
linux ...
I can only see the fingerprint nothing else.

Forwarding for Bill.

I've some good news for you and me :-)

I've make again my package gnupg2 and installed it, this time all patchs was
applied, but I've always the same error :

Wrong title. It is not that the password is visible but that the clear text
from the gpgme_opt_decrypt function is visible. Another developer with more
knowledge of the scenario in this issue will respond shortly.

To solve the third error I've done that :

1. cd scd (I've delete cd scd && on 06-opgp-sign3072.patch file)
2. sh ./06-opgp-sign3072.patch

patching file iso7816.c
patching file app-openpgp.c
patching file iso7816.h
patching file app-dinsig.c
patching file app-nks.c
patching file app-p15.c

Yes I've do it, but I've an error for the third :

static int scrub_stack()
{
char arr[8192];

So you are using the passpharse callback of gpgme and don't make use
ofgpg-agent. In that case you need to take care of zeroing the passphrase.
gpgme has no provisionhs for this because the passphrase callback is a feature
obnly useful in certain environments. gpgme_data_t has nothing to do with
passpphrases.

Did you applied the patches?

I've done news tests on a "fresh" debian install, I've installed gnupg2 2.0.12,
gpg-agent 2.0.12, gpgsm 2.0.12, pinentry-curses 0.7.5-3 and pinentry-gtk2 0.7.3-3.

[In may previous message I meant "gpg does not _wait_ for the end ..."]

When I've done my tests yesterday, pinentry-gtk2 (0.7.5-3) was installed, and
version 2.0.11 of gnupg2 worked fine with it.

I noticed that the status of this issue was changed to resolved and was
wondering if that meant that it will work in a future version of gnupg or if
it means that nothing will/can be done for the Windows version, i.e. a disk
write will be required each time, and the issue is just closed?

You need to install the pinentry package as weel.

I've compiled and installed the new 2.0.12 gnupg version.

Thanks, werner for patchs, I'm on debian, so I think I need it.
Windows xp was just to tested, because generate key doesn't work on my debian,
I'm work on debian squeeze.

These are the non Windows patches we are going to use in gpg4win 2.0.0. They
can be applied to a plain 2.0.12.

I posted them to the mailing list but there are no direct links. Thus I add
them to this bug report.