I don't see that as a bug. The created conf file depends on your local
installation and thus may or may not include a keyserver option.

Sorry, without a detailed derror escription we can't help you. There are a
couple of known problems but gpg4win 1.1 is in any case not anymore under active
development.

This a feature and not a bug ;-)

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.

Thanks

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 :