Hi, thanks for testing master.

I can semi reproduce this. For me it works the first time but a second call to
getpin fails.

$ ./pinentry-gtk-2
OK Pleased to meet you
getpin
D hello
OK
getpin

• (pinentry-gtk-2:29090): CRITICAL **: could not grab keyboard

ERR 83886179 Operation cancelled <Pinentry>

And indeed this goes away with f4b5049c68a79d5e4faba06447db5440936cefeb~1

Looking at the code I don't see a reason for this. Maybe the dialog?
The code without the dialog 71b51e02cf20174ba7144765e985f7e889eaa429 also allows
me to repeatedly call getpin.

Werner: Any idea? I'm a bit clueless which change in the patch could have caused
that.

In 1.4 and 2.0, --import just copies the block, so the bug doesn't hit. In 2.1,
when it tries to write to keybox, the bug hits.

The check what Neal introduced is somehow orthogonal to the change of mine.

The key in question, there is a User ID packet of length >= 256 (because he
include ssh key string in his User ID).
In the code of build-packet.c, gpg assumed the length of User ID is < 256 and it
is hard coded to have header length 2.
With the check (in gpg 2.1), it causes an error. I think that, in gpg 1.4 and
2.0, gpg creates malformed packet with incorrect length (LSB of the length).

fwiw, i first encountered this by doing a full-keyring refresh from the
keyservers. Dying rather than adjusting or accomodating the malformed header
meant that all keys after this one failed to refresh.

In general, dying outright seems likely to make an observed problem worse than
it needs to be.

I can confirm one defect with 2.1.11:
The ability to export a secret key without passphrase available in gnupg2.0
is gone. My use case is to write a testcase that automatically imports the key.

Duplicate of T2324

I am resolving this issue as duplicate of T2324
in the case of intented empty passphrase for the exported key.
(the export-reset-subkey-passwd flag should be taken to an entirely different
issue.)

Both 2.1.11 and 2.1.12 are not in the index, so the update
was missed during the release process.
Werner, you probably know best where to place it in the release process,
so that it is not forgotten. An alternative would be to use a directory listing
module of the webserver which does this more dynamically (and caches the result).

Let us use T2305 for the index update.

FWIW, I added the stricter check. Previously, we specified the header size, but
didn't check that it was respected. When discussing this with Werner, he said
that respecting the header size was important, which is why I chose to die
rather than silently change the header size.

Ian may have a different opinion on that (now) but the GNU build system defines
it in the way I described it.

$ gpg mBank17044.asc
pub rsa2048/375EB336C8086B9E 2015-01-19
uid AR17044 <XXXXXXXXXXXX@mbank.pl>
sub rsa2048/75E684B9017985DF 2014-12-29 [expires: 2016-01-20]

[uid redacted]
As you can see, the encryption subkey expired in January. Thus the holder of
the key does not want you to encrypt to this key after that date. We know that
GPA should give a better error message. I'll change your report to a wish to
implement this.

Bernhard: Please do not assign bugs to me without my consent.

Yes "unusable public key" (original message was not in English and obviously I
failed at translation...).
The key is valid (created at 2015-01-19, no expiration date) - you can see it
yourself, it's attached to this thread.

This is not a bug; gpg tells you that this card is not supported:

  gpg: OpenPGP card not available: Not supported

In case this is an X.509 based card gpgsm _might_ be abale to use it but in most
cases dedicated support for eID cards needs to be added to the scdaemon component.

FWIW, PKCS#11 is not a certificate but a protocol on how some software
interfaces with each other.

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