Well, it will be some work to parse the description of policyConstraints and
policyMappings and see who it fits into the GnuPG system.

I don't think this is a proper solution. --default-key has the same problem as
--local-user. What we can do is to fail if a key has been specified in a
non-unique way. Selecting one by chance is a Bad Thing.

These bug reports are sometimes mixing two different issues: The
debian-keyring and r/o keyrings for other purposes.

Thanks. Commited to branches/STABLE-BRANCH-2-0/.

Requested information has been sent by e-mail.

Forget my previous comment. All checks should be there. Can you please send me
your config.log file by PM (wk at gnupg.org)?

estream-printf has been taken from gnupg 2.0 which includes the required macros
due to a side effect of using otehr gnulib functions. I missed to add the
required tests.

Aihhh. The failure mode depends on the malloc implementation. We are only
shrinking memory and thus some implementations simply return the same pointer.
Obviously not in BSD.

What do you mean by VTn? Some kind of virtual terminal in KDE, a virtual
console of your OS? I don't known. It seems to be more KDE related than gpg.
You may want to check whether some process (e.g. a shell) still has ~/.gnupg as
its current working directory - which might explain the problems your VT
application has.

Dear Mr. Koch,

Dear Mr. Werner,
thank you for your prompt replay. I will try out your workaround to solve the issue.
Thanks a lot!

(I have not looked up the description of these policyConstraints.)

Hi Werner,

FWIW, note that tools/gpgsm-gencert.sh already uses mktemp.

Hi Werner,

Hi Werner,

Unfortunately mktemp is not a standard tool. I see what I can do.

We don't support the keypad with pcscd.

Commited to all branches. Thanks.

The patch fixes the segmentation fault:

Please try this patch.

It is easier to allow them than to deprecate them. Frankly there is still some
code which handles the - despit ewhat I wrote to the ML.

We can implement that in 2.1 after having replaced the current keyring based DB
with the Keybox based one. The latter is far more efficient and does not
require sequential scans all the time. Some breakage will anyway happen and
thus a new selection strategy, i.e. a well defined one, won't harm either.

Sorry, didn't mean to change status with previous message, just confirming that
the issue I raised is resolved. Will try to set it back now.

These changes fix the problem as reported (retested gpg versions 1.4.10 and
2.0.13-svn5147). Thank you!

D103: 251_gnupg_2_spell.diff

Patch for 2.

D104: 250_gnupg_2_spell.diff

Patch for 1.4.

D105: 249_gnupg_1_4_spell.diff

Fixed for 2.0 - svn 5147.

Wen can look into this during the development of 2.1.

This is now a known problem. The likely reason is bug in the card's code. The
workaround is to forget about card based 3072 bit encryption keys.

We will do this in 2.1 and maybe backport it later

Marcus: I this still a problem with the SVN trunk?

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.

We need to review the purpose of gpgkey2ssh. It might be easier to integrate
this into one of the other tools.

No response - assuming that it has been fixed.