ntbtls support is now available in master and we will release a TLS enabled
2.1.19 installer for Windows.

Right now it is somewhat limited and does not work with some sites, notably
those which allow only ECC ciphersuites. An example for such a site is
posteo.de. Note that posteo.net sends a a bogus certifcate with rediretion to
posteo.de.

Most other sites work.

You need to wait for 1.8 - in a few weeks.
I looked at the required changes but decided not to backport that for 1.7.6.

Ubuntu uses a bad combination of an older gpg version and a more current
libgcrypt version. We can't do anything about it. Someone may want to escalate
this to Ubuntu; they should definitely get an update out.

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

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.

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

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.

jenkins is redirected from kerckhoffs to soro using pound features. Please
check out /etc/pound/pound.cfg on kerckhoffs. The jenkins server on soro is
running on a non-standard port - may be this is the reason for the wrong redirect.

I can't easily test this because I am living in the same network.

Regarding HSTS (HTTP Strict Transport Security): The Jenkins server needs to
generate that header

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.

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

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.

Done. It is now redirected via refresh, javascript, or a link to click. Thus
most users won't see the gnu pages at all (because most(tm) use Javascript)

Andre, can you look at it?

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.

I do not understand your request. Do you mean we shall use HSTS and forced
redirection to https for jenkins?

--faked-system-time is debug hack, so I degrade this to a minor-bug.

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.

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';

Please ask on the gnupg-users at gnupg.org mailing list for help. Note that you
do not need to subscribe but just a wait a bit until our moderators will approve
your mail. But anyway here is a quick hint in case you did not already tried:

$ gpg --card-edit
gpg/card> admin
gpg/card> factory-reset

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

Is that the gnome3 pinentry? if so please try the gtk-2 pinentry to see whether
it is the same problem.

Someone please check whether this is still the case and come up with a fix?

The Debian report is waiting since October for a reply from the orig. submitter.

justus: we recently talked about this. Would you like to work on this. I am in
particular interested to use it for Windows statically linked.

Copying pubring.kbx to the backup file is not an option because keyrings tend to
get very large. Several dozen megabytes are quite common.

Okay, that first part has been pushed. Now need to figure out how to test for
Tor in a clean way.

I will do some rework to make testing for tor easier ....

I think this is a good idea. If Tor is already running we can expect that the
user wants to use Tor as much as possible and thus tehre should be no need for
any configuration.

I do not think that we need a new option (except for making --no-use-tor). To
avoid checking for tor with every new connection to Dirmngr, I would do a test
at startup and after each reload.

Please take such discussions to the mailing lists. As soon as a resolution has
been found please update the status of this bug.