Do you mean "unusable public key"? That might be due to an expired or revoked
subkey of that key.

Duplicate of T2374

Duplicate of T2307

We need to look at the history of the patch which introduced the stricter
checks. The problem we have is that some packets are indeed malformed but must
be exported/re-packaged exactly in their original broekn format.

I don't know the reason, but User ID length is hardcoded.

diff --git a/g10/build-packet.c b/g10/build-packet.c
index 4bfc2ac..1353a86 100644

• a/g10/build-packet.c

+++ b/g10/build-packet.c
@@ -329,7 +329,7 @@ do_user_id( IOBUF out, int ctb, PKT_user_id *uid )

  }
else
  {

• write_header2( out, ctb, uid->len, 2 );

+ write_header2( out, ctb, uid->len, 0 );

    rc = iobuf_write( out, uid->name, uid->len );
  }
return rc;

Hi, I consider it a regular defect if unexplained, because the API somehow changed.

I ran into it while testing python3-gpgme on Debian Jessie.
Two testcases fail because of the changed gpgme behaviour to count more processed
"keys" than before.

pygpgme-0.3$ python3 -m unittest tests.test_import

F..F..

FAIL: test_import_concat (tests.test_import.ImportTestCase)

Traceback (most recent call last):

File "/home/bernhard/werkbank/2auto/pygpgme-0.3/tests/test_import.py", line 105, in

test_import_concat

self.assertEqual(result.considered, 3)

AssertionError: 5 != 3

FAIL: test_import_secret_file (tests.test_import.ImportTestCase)

Traceback (most recent call last):

File "/home/bernhard/werkbank/2auto/pygpgme-0.3/tests/test_import.py", line 58, in

test_import_secret_file

self.assertEqual(result.considered, 1)

AssertionError: 3 != 1

How to see the difference without pygpgme installed in Jessie with
Package: libgpgme11
Version: 1.6.0-99intevation1

Package: gnupg2
Version: 2.1.11-99intevation2

pygpgme-0.3/tests/keys$ LANG=C GNUPGHOME=~/tmp/dot.gnupg3 gpg2 --with-colons --import
key1.pub key1.sec key2.pub
gpg: Total number processed: 5

The same on wheezy:
Package: libgpgme11
Version: 1.3.1-0kk3

Package: gnupg2
Version: 2.0.25-99intevation2
ygpgme-0.3/tests/keys$ LANG=C GNUPGHOME=~/tmp/dot.gnupg gpg2 --with-colons --import
key1.pub key1.sec key2.pub

gpg: Total number processed: 3

See bug 2371, which has a backtrace attached.

Duplicate of T2371

By resolved, I meant that the man page now states:

  gpgv  assumes  that  all  keys in the keyring are trustworthy.  That does also
  mean that it does not check for expired or revoked keys.

Your wish is to change this behaviour. This would be an API break and thus I
hestitate to do this for 1.4 and 2.0. However, 2.1 has a lot of changes anyway
and I think it is okay to change it for 2.1.

Looks good...I can even build and run it using the ports version if I hand-patch
it after extracting:

[sonicyouth] /usr/ports/security/gnupg# make extract

> License GPLv3 LGPL3 accepted by the user

> Found saved configuration for gnupg-2.1.12

> gnupg-2.1.12 depends on file: /usr/local/sbin/pkg - found

> Fetching all distfiles required by gnupg-2.1.12 for building

> Extracting for gnupg-2.1.12

> SHA256 Checksum OK for gnupg-2.1.12.tar.bz2.

> SHA256 Checksum OK for gnupg-2.1.12.tar.bz2.sig.

[sonicyouth] /usr/ports/security/gnupg# cd work/gnupg-2.1.12/
[sonicyouth] /usr/ports/security/gnupg/work/gnupg-2.1.12# patch <
~ms/Downloads/gnupg-master-
20160527.diff
Hmm... Looks like a unified diff to me...

The text leading up to this was:

Patching file configure.ac using Plan A...
Hunk #1 succeeded at 787.
done
[sonicyouth] /usr/ports/security/gnupg/work/gnupg-2.1.12# autoconf
[sonicyouth] /usr/ports/security/gnupg/work/gnupg-2.1.12# cd ../../
[sonicyouth] /usr/ports/security/gnupg# make install
[snip]

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!
Reader ...........: 1050:0111:X:0
Application ID ...: D2760001240102000006036429670000
Version ..........: 2.0
Manufacturer .....: Yubico
[snip]

I did not work on this other than what I merged. What I did is to enhance our
fake pinentry program to allow it to supply different passphrases, make it write
a log so that we can quantify the pinentry interaction in test cases, and to add
an export test documenting the status quo.

Whether or not config.sub is up to date should be irrelevant as to whether
libgpg-error should be able to handle CPU variants and the second field of a
HOST. It is supposed to be treated as a freeform field (see
http://airs.com/ian/configure/configure_4.html). As to the precision of the r.e,
it is not supposed to fix or mimic the logic of config.sub. It is to
effectively pigeonhole some HOST strings to a valid header file. Can you give me
a scenario where arm*linux-gnueabi shouldn't map to
lock-obj-pub.arm-unknown-linux-gnueabi.h?

Also, what is the source of your assertion that armv7a-hardfloat-linux-gnueabi
is not a valid canonical triplet? Everything that I have ever read about HOST
strings such as "armv7a-hardfloat-linux-gnueabi" is that configure scripts treat
them as valid and parse them with case statements (as demonstrated here
http://airs.com/ian/configure/configure_4.html). They don't demand that the
end-user pass a generic version of HOST, like "arm-unknown-linux-gnueabi". The
only reason I chose to patch mkheader.c instead or configure.ac was to build on
the mapping logic already there.

config.sub is indeed intended to canonicalize triplets. Thus a an up-to-date
config.sub should fix this. In any case you can always override the guessed
value like this:

  -/configure --build=$(build-aux/config.guess) --host=arm-unknown-linux-gnueabi

I fear that a single r.e. is not precise enough; config.sub has more complicated
rules.

The question at hand is whether dkg's patch or Justus work is the way to go. I
have not yet reviewed dkg's patch, though.

dgk: You are right that Pinentry may be used even with --batch. In fact gpgme
uses --batch and a Pinentry is used nevertheless.

Right, there are no technical means right now to inhibit the export of private
keys. However, it would be easy to add this by not allowing gpg-agent to tell
the client the key used to encrypt the import/export command of keys.

A user migyt have used no passphrase for a key in the believe that an
unprotected key can't be exported.

No, I'll do a Version check in for the GnuPG Version in Kleo master and I won't
backport any changes to the KDE4 / Gpg4win stable variant.

I'm assigning testing to me, I'll test it by using it in Kleo :-)

Done with commit 6c957c3.
Do we need to backport this?

The best solution I can see is to keep CURENT and TOTAL in gpg below 2^31.

Ok, this would work for me, too.

Actually the specs does not say anything about the valid range of the values.

However, gpg uses unsigned long for CURRENT and TOTAL in the progress status
lines for decryption. Unfortunatley the WHAT value is set to the filename and
thus there is no easy way to determine in GPGME how CURRENT and TOTAL are used.

The best solution I can see is to keep CURENT and TOTAL in gpg below 2^31. This
can be done by switching from bytes to KiB and MiB before the 2^31 limit is
reached. I checked GPA and it should not chnage anything, due to

    gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (pbar),
				   (gdouble) current / (gdouble) total);

You can now. Thus is not a bug but a feature request.

Note that we do not use Microsoft compilers but use gcc and in cross build
environment.

D368: 838_gnupg-master-20160527.diff

Thank you for the report.
Indeed, the configure script has a bug.
Attached is a patch to fix this.

Also, index.html in https://www.gnupg.org/ftp/gcrypt/gnutls/ is not up to date:
it does not list v3.5 but the tarball is there:

https://www.gnupg.org/ftp/gcrypt/gnutls/v3.5/gnutls-3.5.tar.xz

I'm not convinced that this policy is effectively implemented in gpg-agent.

The patch series that starts here:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031121.html

resolves the export of secret key material stored as cleartext, and it does so
without modifying gpg-agent at all.

fwiw, I do not agree with T2324 (justus on Apr 18 2016, 05:22 PM / Roundup) that gpg --batch should not use pinentry at
all -- i think it's quite useful to be able to combine --batch with pinentry,
where the key is stored protected, or is otherwise marked by gpg-agent for
limited use.

I don't think this is actually resolved.

As noted in https://lists.gnupg.org/pipermail/gnupg-devel/2016-April/031032.html
, gpgv accepts signatures made from revoked or expired keys.

It should reject signatures made from keys it believes to be revoked or expired.

The attached tarball contains:

     pubkey.gpg -- a binary-format 2048-bit RSA OpenPGP certificate

     C47D9EDFF117EE2AA11B162D017D715B3D0C4AF2.key -- the corresponding
                                                     secret key (for
                                                     reference/experimentation
                                                     only)

     before.txt.asc -- clearsigned message made by the key before
                       certificate creation time

     during.txt.asc -- clearsigned message made by the key between
                       certificate creation and certificate expiration

     after.txt.asc -- clearsigned message made by the key after certificate
                      expiration

of these, gpg approves of during.txt.asc and after.txt.asc, but not before.txt.asc.

is there any way to get better debug output so this can be tracked down?

Thank you for the version information which worked.

Speaking of the code of scdaemon, there is no difference for unblocking (by
resetcode and by admin) between 2.1.11/12 and 2.0.30.

Please note that there are two subcommands.

    admin -> passwd -> 2: unblocking by Admin
    unblock: unblocking by resetcode

Latter requires setting resetcode beforehand.

This was possible on my mac with:

gpg (GnuPG) 2.0.30
libgcrypt 1.7.0
Copyright (C) 2015 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, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

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

Tracked at: https://bugs.kde.org/show_bug.cgi?id=363309

Issue is resolved

Done for new searches.

Thanks. I need a stack backtrace to find the location of the cause.
Please start gpg-agent using:

  gpg-connect-agent /bye

The figure out the PID of the gpg-agent process and run

  gdb /usr/local/bin/gpg-agent PID

At the gdb prompt enter

  handle SIGPIPE nostop noprint pass
  c

The "c" continues operation of gpg-agent. In another terminal run

  gpg2 --sign

as done in your example. GDB in the first terminal will eventually
stop due to the assert. Enter at the gdb prompt:

  bt

and post the output. I would also like to know which version of
libgpg-error you are using:

  gpg-error --version

should show this (or use gpg-error-config --version).

Here is another session after another three times failure.

This time, unblock by admin with Admin PIN.

$ gpg --card-edit

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> admin
Admin commands are allowed

gpg/card> passwd
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 2

[ Admin PIN ]
[ New PIN ]
[ Repeat New PIN ]

PIN unblocked and new PIN set.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? q

gpg/card>

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

$

My case with Gnuk Token.
First, I intentionally input wrong PIN for singing three times.
Then, I invoke gpg --card-edit (with 2.1.2 on Debian experimental) to unblock
the token by resetcode.

$ gpg --card-edit

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 2 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> unblock
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected

[ Resetcode ]
[ New PIN ]
[ Repeat New PIN ]

PIN changed.

gpg/card>

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> quit

Please note that 'unblock' subcommand is to unblock with resetcode.

After a release upgrade, in "gnupg 1.4.20-1ubuntu3 amd64", this typo disappeared
(I see "the").
For myself, this issue can be closed.

For some reason, I can't reproduce your problem in 2.1.x. Isn't it a problem of
your smartcard implementation?
Please describe the specific version number of GnuPG which is possible to
unblock this particular implementation of smartcard.

This is with gnupg 2.1.12, I don't have the same issue with gnupg 2.0.30

1.4.18-7ubuntu1

$ dpkg-query -l gnupg
Desired=Unknown/Install/Remove/Purge/Hold

+++-===================-==============-==============-============================================
ii gnupg 1.4.18-7ubuntu amd64 GNU privacy guard - a free
PGP replacement

Hi Werner,

It's Linux 3.10.0-229.4.2.el7.x86_64 and GnuPG 2.0.22 libgcrypt 1.5.3.
If you mean the commands to delete the test secret key that is now somehow
still showing up when I try to delete the new public key, just imported,
that's:
gpg --delete-secret-keys 'user ID...'

Trying to edit the newly imported key:
gpg -u 'user ID for the key that is used to sign/trust keys' --edit-key
'user ID of the new key'
also tried
gpg -u 'user ID for the key that is used to sign/trust keys' --edit-key
keyID...

I hope this helps, thanks.
Raf

Which GnuPG version?

Please report this to Debian. This is not a part of upstream Pinentry.