With 2.1 the keyserver access has been moved to dirmngr and this gives us a bit
of the framework to implement such a feature. The other missing part are meta
information in the keyring - that is also on my short list.

This has been fixed in master for quite some time.

Please let us know your operation system and the version numbers of gpg,
gpg-agent and pinentry. 2.1 is not a valid gnupg version.

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.

Ok, using TMPDIR is great. I hope that 2.1 still provides the --no-use-standard-
socket option. Stating that "an option to specify the socket name does not make
sense because other tools need to find gpg-agent" doesn't make sense, unless gpg-
agent stopped providing $GPG_AGENT_INFO.

This has been changed in the current version:

That's not a bug.

Hi Werner, David,

I suppose if we wanted to be needlessly pedantic, RFC-4880 actually specifies
JFIF (not JPEG as a whole).

I am not sure what to do. Do all the display tools in common use know about
non-JFIF encoded JPEGs?

For each test we write a log file. What is the content of conventional.test.log ?

By now, I'm running GnuPG 2.0.17 on Gentoo. The card reader completely stopped
working after upgrading to pcsc-lite 1.6.6. I tried to install GnuPG without the
pcsc-lite USE flag, but this didn't change anything either.
If somebody wants to work on the problem and needs a reader for that, I'm
willing to send it by snail mail.

Please don't report problems with a non-released development version to the
tracker. Bugs and missing features are expected. Use gnupg-devel@ instead.

As a good GNU citizen I spent some time on it and implemented PBES2 in
minip12.c. This is in master and I don't intend to backport it to 2.0.x.

Frankly, I'd prefer if gnutls would use the gnupg infrastructure instead of
duplicating everything. If they have time to add their new key derivation
feature to minip12.c; I will be glad to apply such a patch.

I appreciate that PKCS#12 is stupid and baroque, but if the goal is
interoperability with other software, it seems like other GNU tools would be a
reasonable target at least :)

That is quite possible. pkcs#12 is a stupid and baroque data format worse than
the usual X.509 stuff. There are dozens of variants.

Oh, and it's amd64.

I mean the J flag from malloc(3), which is in effect by default on -CURRENT:

J       Each byte of new memory allocated by malloc(), realloc(), or
        reallocf() will be initialized to 0xa5.  All memory returned by
        free(), realloc(), or reallocf() will be initialized to 0x5a.
        This is intended for debugging and will impact performance nega‐
        tively.

What do you mean by malloc debugging? The libgcrypt configure option
--enable-m-guard or some FreeBSD feature? The libgcrypt option does not always
work. If it is a FreeBSD feature, libpth might be the culprit. What system?
If it is a kernel feature will I be able to test it using 8.0 on ia32?

Fixed with with commit d0a9b8a

Oh well, we use an old copy of gpg-zip.1 from Debian for 1.4. I replaced it
with a texinfo generated file from master. Commit 75d62be.

Well, not a functional bug. I'll fix it in master.

Please ask on the gnupg-users ML or consult with a support company; see
http://gnupg.org/service.html

While working on a different part of the code, I found a bug in a function also
used by the ssh code. You may want to apply this patch:

Hello,
I have been checking on the status of this bug report once a week. Unfortunately
no progress was reported.

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.

FreeBSD 8.1 release :

man gpg

No manual entry for gpg

Huh? "man gpg" "man gpgsm" "man gpg-agent" ... all work perfectly for me.
For ages.

GPG needs to to run trial decryptions with all available secret keys; there is
no specific order for this. This can be improved by ordering the packets so
that those with known keys are tried first and only then the wildcard keys. The
wildcards could also be more optimized. This is a actually long standing wish
by myself but I didn't found the time to implement it. Instead I implemented
the --skip-hidden-recipients in 2.1.

g10/sign.c: Pretty obvious error. Not a really problem because DSA
key sizes must be multiples of 8 bytes.

This is just a warning.