Please try current master where I hopefully fixed T2451. This may also fix
this issue.

Fixed in master:

0cc975d dirmngr: Use "pgpkey-hkps" and "pgpkey-hkp" for SRV record lookups.
c2cbe2f dirmngr: Do not use a SRV record for HKP if a port was specified.

This seems to be closely related to T2451.

The ML discussion started during my fall vacation and thus scrolled out of my
sight :-(. While doing some unrelated SRV experiments yesterday, I figured the
problem myself and K_F pointed me to the discussion.

The actual cause for the bugs might be that I missed to forward-port David's
patch from 2009 for changing the service name to the 2.1 branch. I will further
investigate. The move to libdns introduced other bugs and covered the actual bug.

We should use the wrapper as long as we don't have full control over libldap
(select, timeout, etc.)

We don't see that on our Sierra box.

Workaround is to use --passphrase

The tests framework has anyway been reworked and thus I doubt that this is still
a bug.

A major problem with gpg FILE-WITH-KEYS is that its behaviour was never well
defined and it is more a side effect than a a reguarl feature.

It should be fixed, however.

From the ML:

Hi there,

Some keys are found on the keyserver network with non-self signatures
incorrectly attached to a subkey instead of a UID (cf. Issue2236).

Since 2.1.13 it's possible to reorder fix these keys by running the
‘check’ command of the gpg shell. However the procedure currently has
to be repeated after refreshing the keyring, since each --refresh-keys
command downloads the badly ordered key again.

In T2236 (wk on May 06 2016, 08:18 PM / Roundup) Werner wrote that “We will eventually call that reorder
function during import. But let's wait for bug reports with the
--edit-key triggered code.” This code has been working fine for me
since 2.1.13, so I was wondering if it could be activated for --import
(and --recv-key) in 2.1.18? (So we get this in the next Debian stable
:-)

Moreover, as Neal pointed out to me privately, there is no overhead for
keys that don't have incorrectly placed signature packets.

Thanks!

Cheers,

Guilhem.

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