Hi!

I am using a GPG smartcard and a YubiKeyNEO. And with GnuPG 2.0.xx it was
possible to
add the private keys' reference (on the card) to the keyring by calling:

gpg --card-edit

fetch

gpg --card-status

But now with GnuPG 2.1.17 this seems no longer be possible.
After fetching the public key for the card and calling "gpg --card-status"
the keys
are listed as public keys only but not as private keys. So I cannot set
their trust
level to ultimate or use them to encrypt my mails. :(

gpg --card-status

Reader ...........: SCM Microsystems Inc. SCR33x USB Smart Card Reader 0
Application ID ...: D2760001240102000000000000020000
Version ..........: 2.0
Manufacturer .....: test card
Serial number ....: 00000002
Name of cardholder: Thorsten Reichelt
Language prefs ...: de
Sex ..............: männlich
URL of public key : http://pgp.kleiner-androide.de/0xCCF6EF60.asc
Login data .......: shinji
Signature PIN ....: nicht zwingend
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry
counter : 3 3 3
Signature counter : 26
Signature key ....: 2545 D3E3 0C41 32EE 3A25 B663 5892 4EF3 CCF6 EF60

created ....: 2016-10-15 21:20:40

Encryption key....: BAE5 99FF 4F3D AB19 60C0 B0B8 0984 52C3 1AFA A499

created ....: 2016-10-15 21:20:40

Authentication key: 9293 BD4E 9BD9 CCC9 6221 8AB0 0E98 95D4 E7AD 8B07

created ....: 2016-10-15 21:23:09

General key info..: pub rsa2048/58924EF3CCF6EF60 2016-10-15 Thorsten
Reichelt
<XXXXXX@thorsten-reichelt.de>
sec# rsa2048/58924EF3CCF6EF60 erzeugt: 2016-10-15 verfällt: niemals
ssb# rsa2048/098452C31AFAA499 erzeugt: 2016-10-15 verfällt: niemals
ssb# rsa2048/0E9895D4E7AD8B07 erzeugt: 2016-10-15 verfällt: niemals

gpg -K

gpg -k

C:/Users/shinji/AppData/Roaming/gnupg/pubring.kbx

pub rsa2048 2016-10-15 [SC]

2545D3E30C4132EE3A25B66358924EF3CCF6EF60

uid [ unbekannt ] Thorsten Reichelt <XXXXXXX@thorsten-reichelt.de>
sub rsa2048 2016-10-15 [E]
sub rsa2048 2016-10-15 [A]

I was wrong about Tor and IPv6 -- Tor has had IPv6 support for years, so
something else is wrong...

Attached: repeated using 2.0.3 and keys imported from armored backup.

More details:
The issue arose recently, after the subkey had been used for many months
(but IIRC before the subkey expired). The issue affects both the headless
keychain and the master keychain. The restored "backup" was an armored
export, not a whole keychain.

If werner hasn't heard of something like this, I'm doubling my bet on user
error. Maybe my key storage process is the culprit? These keys were
accessible on different TC encrypted partitions, but there is an unencrypted
backup drive elsewhere. I'll try restoring from that.

2.0.12 is a 7 year old version you should not use it at all.

The secring and the pubring in versions < 2.1 can go out of sync for various
reasons. I can't tell from the lising why this is the case, if you can repeat
that with the 2.0.30 version, we can be sure that it is not one of the hugs
fixes in the last 7 years.

Issue: I get a different list of secret keys when using gpg -K than gpg -
edit, and the missing keys can no longer be used to decrypt. I'm using
Gpg4win on Win10 with the latest stable build, but downgrading to previous
versions doesn't help. Adding new keys and removing newer keys doesn't help.
(There was once a [Debian?] bug which only listed the latest key, but this
appears to be different.)

User error is a possibility.

The attached file (gpg_K-vs-edit.txt) shows the results from gpg -K and gpg
--edit with the keys substituted for easier reading. You'll notice that
44444444 and 55555555 are missing from gpg -K.

A title or an URL does not make up a a proper bug report. Please describe your
bug here. tia.

Fixed this morning with
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b200e636ab20d2aa93d9f71f3789db5a04af0a56

1.25 or 1.26 does not matter. In 1.25 we improved the nPth support and made the
mutex used by Libgcrypt's RNG actual work as expected.

However, this seems to reveal another problem and thus I upgraded this to a real
bug.

Sorry, this is not a help line. Please ask on the gnupg-users mailing list for help

Note that ff you have the secret key you can set the preferences.

Can't be fixed in 1.4 or 2.0. Has been fixed in 2.1.

Steps to reproduce:

1. raspberry pi: create one master keypair(Certify) and three subkeys (Sign,

Encrypt, Authenticate). (I will still refer to these three subkeys as just subkeys)

2. raspberry pi: backup ~/.gnupg
3. insert hardware token yubikey1 and keytocard subkeys and eject the yubikey1
4. raspberry pi: delete ~/.gnupg and restore ~/.gnupg from backup
5. insert hardware token yubikey2 and keytocard subkeys and eject the yubikey2
6. repeat steps 4, 5 for remaining gnuk, nitrokey or yubikeys.
7. Now keep yubikey1 with you, give yubikey2 to your spouse, yubikey3 to your child.
8. encrypt backup with gnupg using symmetric cipher.
9. export public key.
10. wipe ~/.gnupg
11. Insert new formatted usb drive and copy public key.
12. shared family laptop: import the public key from usb. insert yubikey1 and

fetch the subkeys to let gnupg know that the private keys are on hardware token.

13. shared family laptop: encrypt and decrypt a file successfully with yubkey1.
14. shared family laptop: insert spouses yubikey2 try decrypt the file encrypted

before. gnupg will not just ask but insist to insert card with a yubikey1 serial
number while you have yubikey2 which in this case also has the same subkeys that
can be used to decrypt the file.

Bug: gnupg does not let shared key usage while using hardware tokens on a shared
laptop.

expected: gnupg should be able to decrypt using any of the yubikeys having
required subkeys.

Please consider: not all hardware tokens have serial numbers printed on them,
consider gnuk or nitro key. It is smart to put a stiker or use permanent marker
to mark keyid on the token incase of having multiple tokens. Another plus about
gnuk is that choose/change my serial number at will.

So, Please ask for a card with a keyid than serial number.

Thank you for thinking on this.

Can user be asked "Please insert hardware token containing 0xXXXXXXXX key". I
guess users are smart enough (considering they are using gnupg) and would write
the keyid on their tokens if needed. If they only own one token which is most of
the time they just insert that. If they own multiple they will recognize by
color or a persoanlized sticker on the key or a permanent marker markings on
their card.

Sorry, I used the word ccid just to mean a hardware token.

I believe many want to have backup hardware tokens. Again this allows a family
share a laptop and still own the shared key in their own hardware tokens.

Here is the version information:
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

I'm using libgpg-error 1.26, though I'm sure it also happened with 1.25 (I get
libgpg-error from Debian unstable, which went to 1.25 on Nov 16th, and then 1.26
on Dec 24th, and I saw the symptoms at both of those times). I'm happy to
experiment with another version if you have suggestions.

See also T2895 (nimbius on Dec 27 2016, 04:49 AM / Roundup)

Duplicate of T1828

Please comment on T1828 (I just granted you permissions)

Are you using libgpg-error 1.25 ?

Please describe your bug including version numbers of the software and which
card you are using.

The serial number is printed on the card and thus the only useful thing a user
can be asked for.

I am not sure what you mean by ccid backup tokens. CCID is a commonly used
protocol between host and card reader

The initial motivation for looking into this is that Git's test suite, which
uses gpg --import to set up some test vectors, was taking longer to run.
There's some additional analysis on the Git list, especially:

http://public-inbox.org/git/20161228160520.dsybuqljzkzsik2d@thunk.org/

D405: 934_libdns.patch

would this patch[0] be acceptable for inclusion in branch?

note from patch composer:

"""
Comment by Gaetan Bisson (vesath) - Friday, 23 December 2016, 07:22 GMT
So I came up with a fix that does two things:

• fallback on the old, standard resolver code
• if no SRV record is found, use CNAME (as expected but some weird error code

apparently broke this)
"""

[0] fetched from
https://git.archlinux.org/svntogit/packages.git/tree/trunk/libdns.patch?h=packages/gnupg

From my network, when I input:

KEYSERVER --clear hkps://oteiza.siccegge.de

It results the error, because the network to the host is unreachable.
It is likely that it is an error of the network or the server.
And --standard-resolver thing is fixed by my commit.

I think that this bug is related to libdns. Unfortunately, it is not
reproducible for me.

Well, somehow related, I pushed my change:

commit d26c51825e2255fe58305cbc1cd74fa43f80d93e

In my environment, compiling with --disable-libdns or --standard-resolver at
runtime for dirmngr, it works fine. Before the fix, I confirmed that it failed
with --standard-resolver.

I tested some more and found out problem is bigger than only move. Copy also
doesn't work, but save message as .msg or exporting to pst folder doesn't work
also. So it seems nothing can be done with message to save or archive it
somewhere else then orginal folder. Tried official stable version of gpgol, but
this has the same problems. Also tried this stuff on android with K9 client and
openkeychain, whereas these problems do not exist, it simple works as expected.

Thanks for the report.

This is fixed in commit 6e96cdd41a0e55b672309431062f37c4a4a9f485, but there is
no release with that version. Sorry for the inconvenience.

D402: 933_01-rijndael-ssse3-fix-compiling.patch

Attached patch should solve LTO problems with rinjdael-ssse-amd64.c.

'memcpy' problem seems to be because of bad interaction between -flto and
#pragma "no-sse". Strangely switching memcpy to buf_cpy solved problem, even
through buf_cpy itself just uses memcpy (on x86).

With this issue solved, I ran in to problem with rijndael-ssse3 assembly code
blocks going missing with -flto and link failing. So rest of the changes in
patch are for fixing lto visibility of assembly.

FWIW, I doubt that 2.1.17 fixes the issue. But, I've improved the debugging
out, so if you would try to reproduce the problem, it would still be useful.
Thanks!

2.1.17 has been released. I would suggest to try it first so that we do not
need to evaluate an older version.

Yes, sure.

That seems to be a regression due to commit 02eb9fc9d5863abcfed6af704e618f8cac7cc2e8

    If the user's CFLAGS include -Werror, then some configure tests fail.
    To avoid this, we only add the user's CFLAGS after all of the
    configure tests have run.

That patch was obviously wrong because configure now has a different picture on
the build system than make. A better solution to the -Werrror problem would be
to pass -Werror only to the make invocation - or more robust to add an
--enable-werror configure flag.