I believe I have also seen this issue (or something very similar) on my Windows
7 64bit machine. I am running gpg 2.1.11. I hope this isn't redundant, but it
seems that I need to restart scdaemon anytime I unplug/replug my yubikey or
suspend/resume my computer.

Sometimes it doesn't recover even after restarting scdaemon. In those cases, I
am able to fix it by stopping scdaemon, removing the yubikey, starting scdaemon,
and finally reinserting the yubikey.

Bug system broke the link URL. Here is a shorter one:
http://security.stackexchange.com/q/115230/16036

As Dashamir Hoxha in the mailinglist gnupg-users mentioned, even with the
--quiet flag enabled, there still is logging output after/during the validation
of the trust-db.

When the user enables the --quiet flag, there should be no log_info output to
the stdin. At most points in the code its managed like in ./g10/trustdb.c:970
(Commit b752d2c93778e6a1c1de3eddf8fc725b0ddd354e in master from the public Git).
But after the silenced output there, it goes into the validate function, where
still is a log_info output in ./g10/trustdb.c:2057 (Same commit as mentioned
above).

relevant to T1424

I have not tried this on 2.1.

To reproduce

% gpg --recv-keys 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

74D1153FB159BB3D1BAC641CAC504BE650012B98

    % gpg --edit-key 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
    tsign with 2 (I trust fully), depth 1, domain "aclu.org"
    Check validity of 74D1153FB159BB3D1BAC641CAC504BE650012B98

If you make the trust signature without a domain specified,
74D1153FB159BB3D1BAC641CAC504BE650012B98 will appear as "full". With the domain
specified, it appears as "unknown".

That's excellent! I tried with no luck to find a roadmap on when 1.7 could be released;
do you have any ETA? How could I help to make it happen?

Thanks!

It is fully supported but you need to link agains libgcrypt 1.7 which has not
yet been released.

Hi Clint,

Out of curiosity, have you tried this on 2.1?

I realize this is probably very easy to reproduce, but could you nevertheless
list the commands that you used to show the bug?

Thanks!

Updated patch to check that the requested key usage is SIG before checking for a
secret key.

D296: 793_sign-fix.patch

Werner pointed out that the quick integrity check is not used due to an attack
by Mister and Zuccherato. However, this attack does not make use of any
information from the PK-ESK packet. It just uses the session key. As such, the
quick integrity check should not be done in the dek->symmetric case either.

I think it is possible to fix this issue so that we can use the quick integrity
check in the future. My post about this to the openpgp group is here:
http://mailarchive.ietf.org/arch/msg/openpgp/A_r93YIukOqzvrmd44F-Jl3dHbc .

My suggestion is a not-backwards compatible change. For messages that currently
exist, it is acceptable to do the quick integrity check if we can rate limit the
oracle (to recover the first two bytes from N blocks costs (N+1) * 2^15
decryption attempts). This is definitely safe, as Mister and Zuccerato point
out, in the interactive case. Do we have a way to reliably detect this?

Sorry, I was using --check-trustdb as a shorthand for the actual function.

bkuptocard had been not implemented, but it was finally implemented in 2.1.11.
If any problem, please let us know.

I cannot reproduce this with current master and a Yubikey4. Can you please
retry with the current master?

Also, are you sure that you are not mixing GnuPG components you compiled with
the ones provided by your operating system? Also, what made you try to compile
GnuPG in the first place?

Please open a separate bug for the other issue. No 'by the way's in bug reports
please.

Fixed in eea139c.

On Sunday 06 March 2016 at 15:18:54, Neal Walfield via BTS wrote:

is for --check-trustdb

Thanks for reporting this. The right solution is for --check-trustdb to ignore
legacy keys.

If i remove the com-certs I get the exact same behavior as I'm seeing on windows.

aheinecke@esus ~/a/e/src> export GNUPGHOME=$(mktemp -d)
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keybox '/tmp/tmp.hyElMR6oUi/pubring.kbx' created
aheinecke@esus ~/a/e/src> gpg2 --import
~/arbeit/gpg4win/zertifikate/testuserA-pub.asc
gpg: /tmp/tmp.hyElMR6oUi/trustdb.gpg: trustdb created
gpg: key 6CFBC912: public key "Test UserA <testusera@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keydb_search failed: Invalid argument

From the debug output it looks to me that gnupg is using keyring functions to
work with the keybox.

I can reproduce this now without Kleopatra and on GNU/Linux:

export GNUPGHOME=$(mktemp -d)
gpgsm -k

< imports /opt/gnupg/share/gnupg/com-certs.pem >
(this is not done on windows so maybe the errors differ because of that)

gpg2 --import ~/arbeit/gpg4win/zertifikate/testuserA-pub.asc

Result:

gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_get_keyblock failed: Value not found
gpg: [don't know]: invalid packet (ctb=00)
gpg: /tmp/tmp.f5ub2ZRYC0/pubring.kbx: copy to
'/tmp/tmp.f5ub2ZRYC0/pubring.kbx.tmp' failed: Invalid packet
gpg: error writing keyring '/tmp/tmp.f5ub2ZRYC0/pubring.kbx': Invalid packet
gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_search failed: Invalid packet
gpg: key 6CFBC912: public key "[User ID not found]" imported
gpg: [don't know]: invalid packet (ctb=00)
gpg: error reading
'/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc': Invalid packet
gpg: import from '/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc'
failed: Invalid packet
gpg: Total number processed: 0
gpg: imported: 1

gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.7.0-beta307

I'll try now with git master.

The debug output from gnupg for an import that caused a corruped keybox.

It's not for the attached pubring.kbx but I have the file that was generated If
you need it.

What I did in the log was to start kleopatra (The output of process is 2428 is
likely the debug output of the initial keylisting kleopatra did)

Then imported a test key and afterwards closed kleopatra.

D344: 787_fix-2235.patch

I believe your problem is fixed in 9f0ba508. With that change I was able to
build gnupg-2.1.11 using speedo in a very minimal Debian jessie chroot.

To test this change, please apply the attached patch (generated using 'git diff
gnupg-2.1.11 dirmngr/Makefile.am' from gnupg master).

If the problem persists, feel free to reopen this bug.

That particular problem is fixed in 9a1778ab. Can you be more specific on the
other problem(s)?

Thanks for the patch, but I decided to fix it by skipping the test instead.

Fixed in a883d4c0.

The reason that we encrypted the SED packet with AES256 is that is the preferred
cipher in my public key. I think that the cipher for the s2k function should be
chosen similarly.

Merged, thanks!

Fixed in 3e1b451c.

Marking as resolved since this is available in 2.1 and we are not going to
backport this to 1.4 or 2.0. Thanks.

I assume that this patch solved the problem. Thanks for reporting!

Attached a patch to call agent_probe_secret_key() during finish_lookup().

This partially solves the problem by not trying to use subkeys that have no
secret key present. This does not unexpectedly change the existing behaviour
because GnuPG will currently return an error if the automatically selected
secret key is not present.

It does not solve the issue of having multiple potential signing subkeys on
different smartcards, because these are always considered to be present (if the
subkey has been associated with a smartcard).

D297: 785_sign-fix.patch

Hi Neal,

Thanks for the patch, works great on the couple of keys I tried it on.
Unfortunately I'm unsure how to build OpenPGP keys with deliberately wrongly
ordered packets, so my tests are probably not exhaustive :-( But looking at
your code (from an outsider's perspective), I can't see how revocation
certificates etc would be handled differently from certificate signatures.

I found two issues though:

+ ndataa = pubkey_get_nsig (a->pubkey_algo);
+ ndatab = pubkey_get_nsig (a->pubkey_algo);

I guess it should be "b->pubkey_algo" on the second line.

Also, since the "check" command of the GnuPG prompt can modify the keyblock, it
should set "modify" accordingly:

-8<----------------------------------------------------------------------------------->8-
diff --git a/g10/keyedit.c b/g10/keyedit.c
index d7c2a4b..ede350a 100644

• a/g10/keyedit.c

+++ b/g10/keyedit.c
@@ -2190,8 +2190,9 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t
locusr,

         break;

       case cmdCHECK:

• check_all_keysigs (keyblock, count_selected_uids (keyblock),
• !strcmp (arg_string, "selfsig"));

+ if (check_all_keysigs (keyblock, count_selected_uids (keyblock),
+ !strcmp (arg_string, "selfsig")))
+ modified = 1;

         break;

       case

cmdSIGN:-8<----------------------------------------------------------------------------------->8-

I understand that by default only selfsigs are reordered for performance
reasons. May I suggest to also consider the key to sign with (for instance
specified with "--local-user")? This can be useful, otherwise in order to avoid
potential duplicates signers might have to type "check" before signing a key.

Also (repeating what we discussed about on IRC so it gets indexed on the web :-)
Due to the append-only nature of keyservers, an uploaded badly ordered key
can't be fixed on the keyserver. As a consequence, with the current algorithm
each refresh would undo fixing the packets' order and removing the duplicates.
Ideally keys would be reordered upon import, and the merge algorithm would avoid
duplicate (for instance it could assume the local copy to be properly ordered,
and not add a packet to the local copy if said packet was found elsewhere on the
keyblock).

For what it's worth, with the following trivial patch the decryption works:

diff --git a/sm/decrypt.c b/sm/decrypt.c
index a560272..aa6e874 100644

• a/sm/decrypt.c

+++ b/sm/decrypt.c
@@ -74,9 +74,9 @@ prepare_decryption (ctrl_t ctrl, const char *hexkeygrip, const
char *desc,

    log_printhex ("pkcs1 encoded session key:", seskey, seskeylen);

  n=0;

• if (seskeylen == 24)

+ if (seskeylen == 24 || seskeylen == 16)

{

• /* Smells like a 3-des key. This might happen because a SC has

+ /* Smells like a 3-des or AES key. This might happen because a SC has

          already done the unpacking. */
     }
   else

I am not sure this is a good solution, though, it is probably better to somehow
pass along the information whether the padding is already stripped or not.

Kind regards,

Lorenz

I've tested it with pubring now too and it works.
Justus mentioned in jabber that he noticed some more errors after this patch in
the scheme tests. I've not tried them.

Okay, so I can backport this to 2.0 ?

Tested this with keybox and it appears to be working. When running a keylist
while importing the import holds for a bit and continues after the keylist.
Not tested this with keyring yet.

Thanks! I'm mark this as resolved.

I've pushed a slightly different version of this patch (2d1d795). Please test
not only that --edit-key detects duplicates and reorders out of place
signatures, but also that revocation certifications, self-sigs, etc. are
correctly checked. Thanks!

D363: 781_gnupg_test_with_portable_shell_commands.patch

D362: 780_gnupg_do_not_run_gpgtar_test_when_not_built.patch

Yes, that patch fixed the problem for me.

I've pushed this.

The branch neal/issue2236 contains an initial fix. It does two things:

• It identifies duplicate signatures (based on their message digest) and removes

duplicates.

• Instead of blindly moving signatures around, this systematically tests each

signature against its alleged component (= primary key / subkey / user id) and
if it is bad, it tries the other components in the key block and moves it if
appropriate. (If it doesn't belong to any components, then the sig is just left
where it is and GnuPG will ignore it).

I've tested this with a few keys and it seems to work well. Lucas' key just has
a lot of duplicate signatures.

Starting program: /home/us/neal/work/gpg/build/gnupg/g10/gpg2 --check-key
0x06EAA066E397832F
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gpg: WARNING: unsafe permissions on homedir '/tmp/luca'
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: Ignored 852 duplicate signatures (total: 2079).
gpg: public key E397832F: timestamp: 2009-07-01 14:44:59 (1246459499)
gpg: user id: Luca Capello <luca@pca.it>
gpg: sig: class: 0x10, issuer: 109E6244, timestamp: 2013-02-05 02:24:16
(1360031056), digest: eb c3
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2009-07-01 14:44:59
(1246459499), digest: 93 7a
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2009-07-01 14:58:17
(1246460297), digest: 53 4f
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2010-10-10 21:44:51
(1286747091), digest: be d5
gpg: Good signature over last major component!
gpg: user id: Luca Capello <gismo@debian.org>
gpg: sig: class: 0x10, issuer: 109E6244, timestamp: 2013-02-05 02:24:16
(1360031056), digest: 4e 92
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2009-07-01 14:57:12
(1246460232), digest: 9c 3d
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2010-10-10 21:52:18
(1286747538), digest: 54 c1
gpg: Good signature over last major component!
gpg: user id: Luca Capello <luca.capello@infomaniak.ch>
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2016-01-24 14:44:42
(1453646682), digest: 79 a4
gpg: Good signature over last major component!
gpg: user id: Luca Capello <luca.capello@infomaniak.com>
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2016-01-29 22:49:59
(1454107799), digest: 43 19
gpg: Good signature over last major component!
gpg: subkey 2BB95F4B: timestamp: 2009-07-01 14:55:55 (1246460155)
gpg: sig: class: 0x18, issuer: E397832F, timestamp: 2009-07-01 14:55:55
(1246460155), digest: 4b d9
gpg: Good signature over last major component!
gpg: subkey 3BE9F36D: timestamp: 2009-07-01 15:09:03 (1246460943)
gpg: sig: class: 0x18, issuer: E397832F, timestamp: 2009-07-01 15:09:03
(1246460943), digest: c2 f9
gpg: Good signature over last major component!
gpg: Couldn't check 1216 signatures due to missing issuer keys.

Interestingly, your key contains a bad signature (the hash has been corrupted).

The reason that I haven't pushed this to master is that I need to work our how
the output should look. Also, this functionality will probably only be
available via the --edit-key menu. This patch includes an argument --check-key,
which will probably be removed.

If you have an opportunity to test this, I'd appreciate it.

fwiw, i've now got most of GnuPG cross-building for win32 from a debian platform
using win-iconv. win-iconv doesn't seem to be a terrible choice to me.

Great

I guess you are reporting for GnuPG 2.0 or 1.4.
We already implemented your suggestion in 2.1.

Yes, that patch works for me.

Given how trivial the fix is, I applied that.

The following simple patch works for me and make check still passes. I think it
makes sense to apply this patch given that this workaround is no more
complicated than an existing workaround for something similar (immediately
preceding my change). Can you please test to make sure it works for you?