That is not a bug. --with-colons is the machine interface and it does not
return abbreviated information as the human readable output does.

We had some other reports on the ML about similar problems. Really time to go
after it.

So, I understand this can't be fixed in software?

There is no cache for smartcards; depending on the type of smartcard they
remember their PIN until they are powered down. With the OpenPGP card you may
use the gpg forcesig subcommand to force a PIN entry for each use of the
signature key.

I've now switched from gcc4.3 to gcc4.4, and this warning is no longer emitted.

That is a limitation of the keyservers.

Sure, you import all the keys store in secring.gpg. What you need to do is to
export the keys you want to import:

Because it is a user program and not a daemon.

there was no crash or disc problem. also logs are clean. only ram+swap was a few
times nearly full (so perhaps not enough for gnupg). why gnupg don't reports
problems to syslog?

This due to a system crash or a disk problem (out of space). GPG uses a
copy,change,rename scheme for any updates of a keyring file. If a problem
occurs the old keyring is still available as .tmp file. If there was a disk or
permission problem, gpg even tells you about this backup file.

That's not a bug.

FIPS requires anyway a specific machine and a specific built binary.

That must be a problem of the FreeBSD ports. GnupG comes with a man page. On
my system I can do

man gpg

for th1 1.4 GnuPG and

man gpg2

for the 2.x gpg. Please report to freebsd.

This is not a bug but expected behaviour: We want to show the pinentry on the
correct xserver or tty and thus gpg-needs to know which one it is. The manual
has even a hint how to show the pinentry on the client machine:

That is a problem of your scanner software.

No, it is an error. See option --preserve-permissions.

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.