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.

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

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.

I don't know about HSTS, but I'd love to see a forced redirect.

It seems Jenkins sometimes generates a redirect that strips the httpS off, e.g.
go to https://jenkins.gnupg.org/manage, click on [Manage Plugins] (the link
itself looks fine), but one is for some reason redirected to
http://jenkins.gnupg.org/pluginManager/.

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.

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.

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)

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

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

--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.

Thank you very much. Straightforward fix. Applied the patch.

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

Delegating to our resident C++ expert.

So i'm left a little confused here about what the resolution is. neal added
documentation, but ueno suggested it was wrong and contributed a patch for it.
However, that patch hasn't been applied.

Some additional questions about pinentry-emacs and INSIDE_EMACS that came up in
discussion over on https://bugs.debian.org/854797:

    What's the best way to debug a problem when emacs pinentry
    isn't working?  do we look at gpg?  gpg-agent?  pinentry? emacs itself?
    all of those places?  What happens when the user has two separate
    instances of emacs running?  What if there's an instance of emacs
    running and someone uses tramp to connect to a remote ssh server, and
    gpg-agent is providing the ssh-agent interface?  What if someone uses
    ssh from *outside* of emacs and it talks to a gpg-agent that was
    auto-launched from within an emacs session?  What about when there's an
    instance of emacs running in a graphical session on a machine where the
    same user is also logged into the machine via ssh, and they're using a
    different graphical session?  how does pinentry-emacs interact with
    emacs --daemon and multiple emacsclient instances?

Another few questions:

Why does emacs use /tmp/emacs$UID for the ephemeral socket instead of

/run/user/$UID ?

If OPTION allow-pinentry-emacs is set, but the emacs process isn't

repsonsive (or nothing is listening at all) should pinentry do a second layer of
fallback, e.g. to curses?

I'm having trouble decrypting some mails. I use an encryption sub-key with a
unusual length of 3104 bits. I described my problem in the gnupg-users mailing
list and there the following problem was identified:
<quote>
I think that it is deterministic; The cause is that the RSA keysize is
not the one in the set of: 1024, 1536, 2048, 3072, 4096. When data to
be decrypted is padded, scdaemon can't decrypt, I suppose.

I am not sure the exact reason why scdaemon only supports limited set of
keysize for encryption. But we have this handling of padding in the
current code:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=scd/app-openpgp.c;h=71c9e1b83003af07b0984688ba1ec5e9013b877c;hb=refs/heads/master#l4334

       /* We might encounter a couple of leading zeroes in the
          cryptogram.  Due to internal use of MPIs these leading zeroes
          are stripped.  However the OpenPGP card expects exactly 128
          bytes for the cryptogram (for a 1k key).  Thus we need to fix
          it up.  We do this for up to 16 leading zero bytes; a
          cryptogram with more than this is with a very high
          probability anyway broken.  If a signed conversion was used
          we may also encounter one leading zero followed by the correct
          length.  We fix that as well.  */
       if (indatalen >= (128-16) && indatalen < 128)      /* 1024 bit key.  */
         fixuplen = 128 - indatalen;
       else if (indatalen >= (192-16) && indatalen < 192) /* 1536 bit key.  */
         fixuplen = 192 - indatalen;
       else if (indatalen >= (256-16) && indatalen < 256) /* 2048 bit key.  */
         fixuplen = 256 - indatalen;
       else if (indatalen >= (384-16) && indatalen < 384) /* 3072 bit key.  */
         fixuplen = 384 - indatalen;
       else if (indatalen >= (512-16) && indatalen < 512) /* 4096 bit key.  */
         fixuplen = 512 - indatalen;
       else if (!*(const char *)indata && (indatalen == 129
                                           || indatalen == 193
                                           || indatalen == 257
                                           || indatalen == 385
                                           || indatalen == 513))
         fixuplen = -1;
       else
         fixuplen = 0;

Perhaps, it was due to support all existing OpenPGP card
implementations, I mean, somehow historical, and it was easier to list
up specific keysizes.

This should be fixed.
</quote>

I also attached to log-files of the scdaemon. One for a successful and one for a
failed decryption attempt.

Please let me know if you need any additional information.

The unnecessary PTR lookup is causing problems for other people too, over on
https://bugs.debian.org/854359

Hello. Im not that much of an expert. So Im not sure what kind of
information you need. But its Debian 8.7, amd64, Cinnamon, 16 GB ram
Or can you say what kind of information?
Today I freshly installed Debian 8.7.1 (latest stable), Gnome, amd64 using
VirtualBox with Windows 10 as the host, and then installed GPA on this
Debian. But it still has the same problem. Im boggled as to why I have this
problem.