Should be fixed with commit 6d50eeb for 2.1.19.

My idea on how to do a general fix turned out to be too complicated and thus I
fixed just the Polish translation

Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?

D409: 954_0001_gnupg-2.1.18_allow-original-timestamp-on-keysig-update.patch

Thanks, i've pushed this back to python-gnupg folks, and they've accepted it:

https://bitbucket.org/vinay.sajip/python-gnupg/commits/d0375e034da3efa6fbda713cb4bde0fbb6d3b158

so i think we can consider this issue resolved, at least from 2.1.14 and onward,
where import-show was introduced.

That is definitely a bug.

I guess that is because the prompt has not been translated but the answer string
is translated.

msgid "NnCcEeOoQq"
msgstr "IiKkEeDdWw"

Thus using 'i' should give you the prompt for name.

A fix for this would be to use a different answer string for --gen-key - the one
we use if from --full-gen-key (i.e. with "(C)omment". This would the also work
for other incomplete translations, which will have the same problem.

dkg thank you. One of the user reporting the issue has confirmed that fixes it:
https://github.com/Homebrew/homebrew-versions/pull/1527#issuecomment-280667350

gpg --version

gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
libgcrypt 1.6.6
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: C:/Users/<username>/AppData/Roaming/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

Yes...seems old! But this is what latest gpg4win packages. :(
It is also the latest stable gpg release...so normal, I guess.

I've installed gpg on various recent Windows 10 builds (~10 machines/builds)
and noticed the behavior on all of them. For example builds 14939, 14986, and some
others.

Thanks for these fixes! I'm not sure i understand why ptr lookups are needed
for keyserver --hosttable. Can we drop those too?

This sounds like issues we were seeing in debian, which i believe have been
fixed in git already.

we're shipping the following two patches in debian against 2.1.18:

https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/0028-scd-Backport-two-fixes-from-master.patch/
https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/0029-scd-Fix-use-case-of-PC-SC.patch/

We have Homebrew users reporting this problem to us.

https://github.com/Homebrew/homebrew-versions/commit/bece3fdbb732bcf646589c051f2f882e2bbf0875#commitcomment-20846337
https://github.com/Homebrew/homebrew-versions/commit/bece3fdbb732bcf646589c051f2f882e2bbf0875#commitcomment-20910048

"I had to revert to 2.1.17, gnupg was unable to access my yubikey with 2.1.18.
The error was "gpg: selecting openpgp failed: Operation not supported by
device". Not sure if I'm the only one with the problem, if not I'd recommend
reverting the version."

I have fixed some things. In general PTR lookups are onow only used when you
run the 'keyserver --hosttable' command.

I note that even if i drop the "--trust-model tofu+pgp" and subsequently invoke
just "gpg --tofu-default-policy ask --fingerprint" i get the same crash.

however, if i just execute that in a fresh homedir without ever having set
"--trust-model tofu+pgp" i don't get a crash. so there is some sort of state
being set up that is then tickling the assertion later.

Yet another Yubikey think, I'll better a a keyword for this.

Never use system() anywhere!

You need to call cmd with the script. However, there are some security issues
with than too and thus I consider it better use a dedicated executabe for this.

If you can tell us what the script shall do, we may distribute a simple
executable for that purpose.

For a key listing I would suggest this

  gpg --dry-run --import-options import-show --import  FILE

This uses the regular key listing code.

Please tell us which version of GnUPG ayou are using and on what OS.

Tested this again with 2.1.18 and it works now as expected. Export secret key
just exports a key if it has no passphrase. So I think this issue can be marked
as resolved.

Done with commit b456e5be

gpg: Make --export-ssh-key work for the primary key.

* g10/export.c (export_ssh_key): Also check the primary key.
--

If no suitable subkey was found for export, we now check whether the
primary key is suitable for export and export this one.  Without this
change it was only possible to export the primary key by using the '!'
suffix in the key specification.

Also added a sample key for testing this.

Fixed with commit 30dac04 but not properly tested.

Frankly I am used to leave out the -d to use the default. I have seen the -d in
action only in CitizenFour ;-)

Need to think again about this.

(The last line in T2943 (wk on Feb 13 2017, 07:22 PM / Roundup) was garbage)

Fixed with commit dee026d7.

If no DNS method is found in nsswitch.conf we now append one. Using dirmngr w/o
DNS does not work anyway thus this seems to be the best solution.

Right, the proposed chnage will not fallback to the standard resolver.

I need to modify the patch because it was too simple: Need to explicitly look
for an dns entry and append it to the list iff it is missing.

I'll just note that the only programmatic unattended uses i've seen have been
*not* decryption. they're attempts to list a keyring. So switching to
decrypted mode there will provide the same amount of breakage as requiring an
explicit command, but without the benefit of requiring explicit intent.

Any variation in behavior between automated and "attended" use is a debugging
pain point that actually seems to create work in the rest of the ecosystem. The
more GnuPG can keep its rules and behavior simple to understand, the better.

right, the configuration is not an error, but a different way of handling the
DNS lookups.

just to clarify: this change means that dirmngr will continue to use libdns in
the event of finding no understood directives in nsswitch.conf. it is *not* the
equivalent of falling back to standard-resolver. right? If that's correct,
then i agree that an extra warning is probably too much noise.

Would be surprising for a Unix tool but given that we do that for certain files
anyway, I can imagine to implement this. (but no stdout fiddling - if that even
works.)

I'll change the title and set the priority to feature.

You would see that error message then with every first DNS call. My
understanding is that on systemd the unknown keywords are not an error but a
featyre of systemd-resolver(?).

I meant decryption. My idea is:

1. In attended mode: Just print a warning message.
2. In unattended mode (--batch or --with-colons): Make --decrypt the default

and do not print a warning message. That would be a hardfailure for everything
but encrypted data

The idea is that attended command line use keeps on working but using it in
scripts (--batch, etc) will hard failure.

make the default operation --decrypt

Right, agreed -- there is no way to get to the "improved --list-packets" without
using the dubious approach of not specifying a command at all.

I agree that a hard failure when --batch is given without an explicit command
would be reasonable (though that means we will be effectively breaking
python-gnupg and others like it, which do try to use it). I'm not sure i
understand the reasoning behind a hard failure for --with-colons without an
explicit command.

looks reasonable to me, though i haven't tried it myself (my nsswitch.conf
doesn't have the initial property reported).

Perhaps there should be an additional explicit log message for the
!ld.resolv_conf->lookup[0] case since dirmngr is falling back?

I understand, So this is another special case like the one when a keyring has
permissions which don't allow it to be read.

Right, but it would double the write time and we won't have an atomic update -
which we need.

Using a socket conenction would require new code. We use the standard ports
instead. Sometimes the socks5 code (and I assume also the Unix domain socket
code) takes some time to figure out whether Tor is actually running, Thus this
is not done at every request.

Doing a check for every request would also require a lot of new code because we
need to restart a connection attempt at a higher layer. Similar to HTTP 301
handling.

The whole point of a daemon is that is idling in the background to wait for work.

A more useful feature would be to flush the passphrase cache when the user is
not anymore logged in. But for Debian this has already been done by --supervised.

Unfortunately, it is also used in the test suite to deal with expiration times.

Oh well, using a curl based key server helper this might have worked in the
past. We better implement that for 2.2

There has never been support in GnuPG for https via an http proxy.
So can we change this to a feature request?

Also note that the key listing is different from a real key listing and in
effect more like an improved --list-packets. Maybe we should make a hard break
and only do encryption without an command - at least when --batch or
--with-colons is given.

I implemented that but then I found this in the man page:

  This command differs from the default operation, as it never writes
  to the filename which is included in the file and it rejects files
  that don't begin with an encrypted message.

Thus decryption is the default operation. The problem is that the
code also tries to do other things if it does not find encrypted data.
Note that the "never writes to the filename which is included in the
file" is wrong because gpg does not do that by default.

however i still think the actual key fingerprint used should be shown here.

There are two problems with this proposal:

1/ Usability. Showing a keyid or fingerprint is less user-friendly than to show
the identifier that the user actually used in the configuration file to refer to
her key. I'd guess that most users use a UID here.

2/ Consistency. The code around the message in question also deals with error
handling in case looking up the key fails. In this case, we cannot show
anything besides what the user used in her configuration.

shouldn't we avoid short keyids everywhere?

We should avoid short keyids everywhere we use keyids, but this is not the case
here.

that is true. however i still think the actual key fingerprint used should be
shown here. shouldn't we avoid short keyids everywhere?

Good idea.
The "This looks like foo" might be a bit complicated but the warning is easy to
implement. I will add that one immediately.

I guess the best solution is to handle this the same way as a missing
nsswitch file. Here is a non-tested patch; for a quick test the
change of the condition is sufficient.

diff --git a/dirmngr/dns-stuff.c b/dirmngr/dns-stuff.c
index f0de357..956fe72 100644

• a/dirmngr/dns-stuff.c

+++ b/dirmngr/dns-stuff.c
@@ -496,14 +496,15 @@ libdns_init (void)

fname = "/etc/nsswitch.conf";
err = libdns_error_to_gpg_error
  (dns_nssconf_loadpath (ld.resolv_conf, fname));

• if (err)

+ if (err || !ld.resolv_conf->lookup[0])

{

• log_error ("failed to load '%s': %s\n", fname, gpg_strerror (err));
• /* not fatal, nsswitch.conf is not used on all systems; assume
• * classic behavior instead. Our dns library states "bf" which tries
• * DNS then Files, which is not classic; FreeBSD
• * /usr/src/lib/libc/net/gethostnamadr.c defines default_src[] which
• * is Files then DNS, which is. */

+ if (err)
+ log_error ("failed to load '%s': %s\n", fname, gpg_strerror (err));
+ /* Not fatal, nsswitch.conf is not used on all systems;
+ * assume classic behavior instead. Note that some systemd
+ * based systems allow for custom keywords which are not
+ * known to us and thus lead to an empty result set; we then
+ * also fallback to classic behavior. */

if (opt_debug)
  log_debug ("dns: fallback resolution order, files then DNS\n");
ld.resolv_conf->lookup[0] = 'f';

I have seen that discussion and will takle care of this bug soon.

This is because you use a short key id in your gpg.conf. gpg is merely echoing
back whatever you specify there:

% touch tmp ; gpg2 --detach-sign tmp
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: using "baz" as default secret key for signing
% grep default-key gpg.conf
default-key baz