Ok, if you agree that this is a useful feature then I will implement it.

Fixed in 81797af.

Fixed in 42d4c276. Thanks!

It is not trivial, but I guess we could create a temporary keyring and import
the key. But to be honest I don't understand why storing base64-encoded random
junk is somehow better than storing the junk itself, I mean it wont diff better
or something.

I approved you as a user, if you still cannot comment on the bug, please ping me
again.

Hello,

can you please run

$ make -C tests/openpgp check verbose=2

and attach the output?

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.

Fixed in ec412b9d.

Fixed in c7cb4008. This will take effect next the web site is published.

This is a feature of the org-mode export. I'm looking into this.

Yes you are using pinentry, and we need to know what kind of pinentry (there are
several flavors) and which version you are using in order to help you.

Please do 'pinentry --version' and report the output.

To see whether this pinentry is the one you are using, or to play around with it
and the variants, you can do:

echo -e "SETDESC Does this look like your pinentry window?\nGETPIN" | pinentry

You can try replacing pinentry with pinentry-qt for example.

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.

Merged, thanks!

Fixed in 3e1b451c.

I could reproduce this with gnupg-2.0.29. I will have a look.

Yes, that patch works for me.

It seems to be base64:

% ssh -V
OpenSSH_7.1p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E md5 -q
playfair.gnupg.org RSA MD5:cc:dd:46:8e:ef:3d:d9:34:97:f8:b8:5a:59:51:80:4a
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E sha256 -q
playfair.gnupg.org RSA SHA256:KCh034SD0rMKqCkJbdH2wx354s1278tqt9F+xb5cidg

Related issue: #1166.

Now that we have a dirmngr daemon, this should be feasible. I plan to implement
it like this:

Add two flags to the KS_GET command, --enqueue and --drain-queue. --enqueue
merely enqueues the key id and returns immediately, unless --drain-queue is
given.

This will also help us address issue #1827.

I'd be happy to implement this, but it is not clear to me how. Merely base64
encode the default representation? Or the canonical representation?

I generalized the ssh key fingerprinting code so that we can select the digest algorithm.

Now I'm a little unsure how to proceed. We can easily include both the MD5 and the SHA256 digest
in the sshcontrol file. But what shall we use for expanding '%F' in key descriptions? If we
transition too soon or too late, users might not recognize their key. Displaying both surely is
too verbose. We could make it configurable, or at least a compile time option.

What do you think?

Err, fixed in 6ac57a48.

Fixed in

Fixed in a8308ba5.

% g10/gpg2 --keyserver hkp://keyring.debian.org --search-keys dkg
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: error searching keyserver: Not implemented
gpg: keyserver search failed: Not implemented

The problem here is that the hkp client code folds all http status codes other
than 200 and 3xx into GPG_ERR_NO_DATA. This is also a problem for issue #1038.

I'm not sure, I reverted said change, and it still works for me:

% echo -e "KEYSERVER hkp://ipv6.pool.sks-keyservers.net/\nKS_SEARCH CADE3658\n"

dirmngr[10105.0]: marking host '[2a01:4f8:192:f5::3]' as dead
dirmngr[10105.0]: marking host '[2001:41d0:2:a8b4::10]' as dead
dirmngr[10105.0]: marking host '[2001:67c:2050:1000::3:4]' as dead
dirmngr[10105.0]: marking host 'hufu.ki.iif.hu' as dead

The log clearly states the problem:

2015-10-09 10:27:37 dirmngr[2516.0] TLS verification of peer failed: The
certificate is NOT trusted. The certificate issuer is unknown.

Please see https://sks-keyservers.net/overview-of-pools.php#pool_hkps for how to
configure gpg properly. With the CA for the pool, this works as expected.
(remember to kill the old dirmngr daemon):

% gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys
5EE1DBA789C809CB
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: key 89C809CB: public key "git-annex distribution signing key (for Joey
Hess) <id@joeyh.name>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Total number processed: 1
gpg: imported: 1

I can reproduce this without the proper configuration described in https://sks-
keyservers.net/overview-of-pools.php#pool_hkps:

% :> /home/teythoon/repos/g10/local/gnupghome/dirmngr.conf
% gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
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: error searching keyserver: General error
gpg: keyserver search failed: General error

But with it, it seems to work fine. Remember to kill the old daemon first:

% echo hkp-cacert /home/teythoon/repos/g10/sks-keyservers.netCA.pem >
/home/teythoon/repos/g10/local/gnupghome/dirmngr.conf
% pkill dirmngr
% gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
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: data source: https://jarvis.alpha-labs.net:443
(1) NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>

          2048 bit RSA key 33BD3F06, created: 2014-10-29, expires: 2016-10-28

You can talk to the dirmngr directly like this:

% echo -e "KEYSERVER hkps://hkps.pool.sks-keyservers.net\nKS_SEARCH 2071B08A33BD3F06\n" | dirmngr

If this still does not work for you, please paste the output of the above invocation.

'gpg-zip' is being phased out. It will be shipped with gpg-classic, and dropped
from gpg-modern. Furthermore, I just checked that we no longer install gpg-
zip.1.

Werner, in https://lists.gnupg.org/pipermail/gnupg-users/2015-May/053617.html you wrote:

The real bug is that dirmngr does not mark the v6 address dead and
retry anotyer server (or the v4 address).

I cannot reproduce this. I pointed dirnmngr to ipv6.pool.sks-keyservers.net and servers
got marked as dead as expected.

Fixed in c9f5aa15.

Fixed in a9e0b1dd.

Fixed in eb54fca.

Fixed in 1e3dbb15.