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!

As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/

The patch seems to have fixed it.

I removed the not-working checkbkupkey subcommand in
44aee35e69540510617aea4b886ef845590960fe

Also fixed the bkuptocard subcommand in: 40959add1ba0efc1f4aa87fa075fa42423eff73c

Fixed in aecf1a3c.

Thank you again.

It is likely that the token itself doesn't work well after wakeup from sleep
mode. In this case, all that we can do is re-inserting the token manually.

I'm not sure how PC/SC service handles USB reset after wakeup.

Sorry to say, but mapping the error to "no reader" doesn't help. The first
reset event doesn't get handled. Later it trys to remove the reader but it's
not getting correctly resetted/reinserted again.

I've attached the debug log again

Thank you for further testing.
I think that current code doesn't handle the case when card goes inactive/reset
while reader keeps working. Current code only goes to the reset sequence for a
card again when it detects reader failure. So, although the concept is
different, I think mapping PSCS_W_CARD_RESET to SW_HOST_NO_READER (for now) will
work. Given the situation we don't yet support multiple cards, this workaround
would be OK for a while.

Nope. Neither mapping the "reset card" event to SW_HOST_CARD_INACTIVE or
SW_HOST_NO_CARD helps. It seems that somewhere in the code the return code
SW error codes are not being handled correctly and the card doesn't get
resetted.

I've attached a small log where you can see that pcsc returns the error
reason "reset card" which then gets remapped to "Card reset required" (was
general error before). I also can see that the error is getting mapped to
GPG_ERR_CARD_RESET (because of the error message "Card reset required")
leaving the daemon around with no working card and reporting general errors
again (0x100b).

Additional Info: This bug only happens when you put your computer/laptop
into sleep mode while the smartcard/reader (yubikey) is plugged in. If I
remove the reader before putting it to sleep and attaching it after getting
out of the sleep mode, the scdaemon works fine.

D338: 740_0002-scd-map-card-reset-event.patch

Maybe it's more appropriate to map the PSCS_W_CARD_RESET event to the
SW_HOST_CARD_INACTIVE error code which later gets mapped to GPG_ERR_CARD_RESET
error code.

I've attached the patch file. It would make sense to backport this mapping as
well. Right now it's not yet tested.

I found another problem with the smartcard service under windows. Putting
the system into sleep mode and waking it up again creates an 0x80100068
error code (aka PCSC_W_RESET_CARD).

I'll test if it helps to map the RESET_CARD event to the same REMOVE_CARD
event to get the card reactivated after sleep mode.

Logfile:
2015-12-21 22:16:57 scdaemon[10040] DBG: send apdu: c=00 i=CA p1=00 p2=C4
lc=-1 le=256 em=0
2015-12-21 22:16:57 scdaemon[10040] DBG: PCSC_data: 00 CA 00 C4 00
2015-12-21 22:16:57 scdaemon[10040] pcsc_transmit failed: reset card
(0x80100068)
2015-12-21 22:16:57 scdaemon[10040] apdu_send_simple(0) failed: general
error

I was using "gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)", and then I
just updated to "gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)". Sadly,
no change.

Okay, Feel free to re-open if you see it again.

Fixed in 1.4.20 (and 2.0.28).

Thanks, I can confirm that this solves it.

That fingerprint looks more like gibberish than something which should be
compared by the user. In that regard a SHA-1 fingerprint looks much more
serious and IMHO will be more secure than a base-64 fingerprint where you have
to explain that the users also need to match the case - if they are at all able
to compare that fingerprint.

We should take this to the mailing list.

Fixed with commit af14285

pkg-config weirdness.