The problem itself has been fixed. Please open another bug for the UX problem.

We wont fix that because it has been fixed in 2.1 and backporting make no sense
given that an easy workaround is available.

Please given an example.

I don't count win-iconv a small helper.
We can solve this problem more easily by moving the ut8conv.c code to
libgpg-error which alread has some of the conversion code.

I change the category to whis because this is not a bug but a build requirement.

I am not sure about which code part you are talking. Please can one of you
explain. If this is what I assume, please have a look at commit 25f0f05.

FWIW, we do not copy to create the backup but use atomic renames:

  lock(pubring.gpg.lock)
  read(pubring.gpg) -> process -> write(pubring.tmp)
  rename(pubring.gpg, pubring.gpg~)
  rename(pubring.tmp, pubring.gpg)
  unlock(pubring.gpg.lock)

Thus the worst case is that another non-updating process sees no pubring.gpg
during the time between the two renames.

Note that under Windows we don't have inodes :-(
See also T2135 .
As I remarked several times in the past the only solid way to handle these
problem is to allow access to the keyrings only via a dedicated processs.

We have never seen a real-world bug here. Thus I change this to a minor-bug.
You solution is not that easy becuase we need to maintain that order for all
time and we can't cope with older gpg versions which are still in use on the
same ~/.gnupg - they would have a different lock order and that would indeed
lead to a deadlock. As of now this is mitigated by all gpg versions using the
same config file and thus the same order of keyrings.

Fix will be in 2.1.11. Thanks for testing.

I have pushed chnages to master to fix this problem. One drawback is that
during an import another process "gpg -k" may rarely see no keys at all. A full
fix would either require that we lock the keyrings during all read-only
operations, which would severely hit on the performance of all common
operations, or change the whole system to use a new key access daemon.

If this works the changes need to be backported to 2.0.

Actually this is a copy of the web site version. I fixed both versions. Thanks.

Please ask on the gnupg-users mailing list for help. This is a bug tracker and
not a help forum, sorry.

It would be different issue, but we have similar problem for 'fetch' failure
with an error message like:

gpg: key B00DC692: rejected by import filter" followed by "gpg: Total number
processed: 1

Finally, I confirmed the problem. Sorry for taking long time. My understanding
was bad. I'm going to fix this.

OK, thanks for the response Werner. Perhaps this bug then is to update the website
docs to reflect what I gather may be big changes to this feature as compared to earlier
gnupg releases.

It seems that everything that can be found here (the best source I have found for using
gnupg w/ DNS) is now outdated and will no longer work:
http://gushi.org/make-dns-cert/HOWTO.html

I wanted to learn more about the new changes but I was only able to find the following
references which I'll document here in case someone else comes across it.
Unfortunately, I won't be able to test out the new method as I don't run my own bind
server and like many of us rely on a DNS provider that doesn't allow me to create the
form of DNS record output by --print-pka-records.

I only found three references to the new '--print-pka-records':

2.1.3 Announce:
https://lists.gnupg.org/pipermail/gnupg-announce/2015q2/000365.html

"* gpg: New option --print-pka-records. Changed the PKA method to use

   CERT records and hashed names."

gnupg docs:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html

"--print-pka-records
Modify the output of the list commands to print PKA records suitable to put into DNS
zone files. An ORIGIN line is printed before each record to allow diverting the records
to the corresponding zone file."

And finally an announcement from you in gnupg-devel from last year where you state that
all of the old functionality for PKA has been removed and replaced with something
entirely new (which is just for key 'validation' and not for key installation?):
http://marc.info/?l=gnupg-devel&m=142488047809150&w=2

This was implemented for 2.1. We won't backport it to 1.4 or 2.0.

That website is outdated. The format of the PKA records changed. Use

gpg --print-pka-records -k <userid>

to create a record.

You also need to build gnupg with a proper DNS resolver library and make sure
that you are using the matching dirmngr version.

For further questions please resort to the gnupg-users mailing list so that
others may help or learn from the replies.

That is no bug. gpg clearly states this. The factory reset is an optional
feature of the OpenPGP card specs.

Right, getkey_next had a somewhat surprising semantic. I fixed that with commit
b280aa6.

It also works with ECDSA keys.

Current master b2da3951 segfaults on me.
Btw. I think this is likely because i have a local ID without an Authentication
subkey for aheinecke@gnupg.org

(gdb) run --export-ssh-key aheinecke@gnupg.org
Starting program: /opt/gnupg/bin/gpg2 --export-ssh-key aheinecke@gnupg.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: memstat

Program received signal SIGSEGV, Segmentation fault.
lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116

3116 *ret_keyblock = keyblock; /* Return the keyblock. */
(gdb) bt full
#0 lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116
    rc = 0
    no_suitable_key = 0
    keyblock = 0x0
    found_key = 0x701980

#1 0x0000000000415bb6 in getkey_next (ctx=0x6dd940, pk=0x0, ret_keyblock=0x0)
at ../../g10/getkey.c:1636

rc = <optimized out>
found_key = 0x0

#2 0x000000000045713a in export_ssh_key (ctrl=0x6dd810, userid=0x7fffffffe420
"aheinecke@gnupg.org") at ../../g10/export.c:1437

getkeyctx = 0x6dd940
keyblock = 0x6fd160
desc = {mode = KEYDB_SEARCH_MODE_SUBSTR, skipfnc = 0x0, skipfncvalue =

0x0, sn = 0x0, snlen = 0, u = {

name = 0x7fffffffe420 "aheinecke@gnupg.org", fpr = "

\344\377\377\377\177", '\000' <repeats 17 times>, kid = {

4294960160, 32767}, grip = " \344\377\377\377\177", '\000'

<repeats 13 times>}, exact = 0}

curtime = 1452288169
pk = 0x0
identifier = 0x6ddb80 ""
mb = {len = 0, size = 4096, buf = 0x6e5d70 "", out_of_core = 0}
fp = 0x6dd810
b64_state = {flags = 7199040, idx = 0, quad_count = -153676256, fp =

0x10, stream = 0x6dd800, title = 0x6ddb80 "",

radbuf = "\000\000\000", crc = 0, stop_seen = -1, invalid_encoding =

0, lasterr = 0}

fname = 0x7fffffffe420 "aheinecke@gnupg.org"

#3 0x000000000040dc00 in main (argc=1, argv=0x7fffffffdfe8) at ../../g10/gpg.c:4193

pargs = {argc = 0x7fffffffdb9c, argv = 0x7fffffffdb90, flags = 32769,

err = 0, r_opt = 0, r_type = 0, r = {ret_int = 0,

ret_long = 0, ret_ulong = 0, ret_str = 0x0}, internal = {idx = 2,

inarg = 0, stopped = 1,

last = 0x7fffffffe420 "aheinecke@gnupg.org", aliases = 0x0,

cur_alias = 0x0, iio_list = 0x0}}

a = 0x6dd800
orig_argc = 0
orig_argv = 0x6ddb80
fname = 0x7fffffffe420 "aheinecke@gnupg.org"
sl = 0x0
remusr = 0x6ddb40
locusr = 0x0
nrings = 0x0
afx = 0x7fffffffe420
configfp = 0x7fffffffe420
configlineno = 27
parse_debug = 7198720
cmd = aExportSshKey
malloc_hooks = {malloc = 0x405ee0 <gcry_malloc@plt>, realloc = 0x406d40

<gcry_realloc@plt>, free = 0x406290 <gcry_free@plt>}

ctrl = 0x6dd810

D343: 751_0001-doc-Fix-typo-gen-full-key-in-whats-new-in-2.1.txt.patch

Here's a patch produced with git format-patch.

Done with commit 4970868 to be released with 2.1.11.
This uses a new command and not an export option so that export options can be
kept in the conf file.

ECDSA keys (NIST keys) do not yet work.

Sorry, I can't see any problem here.

The "priotr-old" key is actually the newer key because an expiration date was
added to that copy of the key (2012-07-09) and that key has meanwhile expired.
Thus you can't encrypt using this key.

When you import the "piotr" key that is actually the same key but w/o the update
with the expiration date. Thus gpg does not chnage the exiting in key because
the existing key has a newer self-signature (where the expiration date is
stored) than the new key. So nothing changes, which is correct.

If you delete the .gnupg directory you don't have the newer key and by importing
the key w/o the expiration date you can encrypt to that key.

Right, this is what I actually had in mind. Using the "<keyid>!" notaion it
would also be possible to export any primary of subkey in ssh format.

Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.

1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.

No Kleopatra does not open the pubring. Let's leave kleopatra out of this.

This bug is about multiple GnuPG processes that conflict with each other. See
msg7466 for an example.

Do you mean Kleo opens the pubring file itself?

Commit e70f7a5 fixes this for 2.1.
Should be backported.
Thanks.

Renamed the issue to my current understanding of this problem. Locking on
Windows does not work properly.

Yesterday I had a failed Keygeneration while GpgOL's certificate selection
dialog in Kleopatra was open. Tried again and it worked. I did not get Debug
output but the pattern suggests to me that the Certificate selection dialog
looked for changes in the pubring while generating a key and the locking broke
again.

This problem is rising in my priority of Windows Issues as it causes random
failures. There is also a load of similar reports on various channels to be
found through google https://www.google.at/search?q=pubring.bak

I've tested to generate an rsa2048 key with backup on a v2.0 card and it works
now. I have not tested restoring from backup etc. But as this report was about
the failed generation, this issue is resolved imo.

Thanks!