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.

So I believe that if we have a test that demonstrates this problem, then it is
safe to set the status to resolved.

Fixed in 6823ed46584e753de3aba48a00ab738ab009a860.

We need more information how to reproduce the bug.

I can reproduce this. Our test indeed feeds a passphrase to the agent.

Addressed in 56aa85f88f6b35fb03a2dc1a95882d49a74290e3.

Addressed in 56aa85f88f6b35fb03a2dc1a95882d49a74290e3.

Here's the make check verbose=2 log for 2.1.18 on macOS 10.10.5 Yosemite:
https://gist.github.com/ilovezfs/d9de58955697858a1eb3c6d3a5e48bea

And ssh -V:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

I feel that this is the very same issue as T2847

I assumed they were different issues since this is ssh-import.scm and that was
ssh.scm.

I asked what version of ssh you were using over there, and sadly you

did not react.

Sorry

Yes, your version of OpenSSH does not seem support elliptic curve cryptography.
I feel that this is the very same issue as T2847, could you please revisit
that bug? I asked what version of ssh you were using over there, and sadly you
did not react.

I guess we need to figure out what kind of algorithms are supported, and skip
the ones that are not.

Additional findings. If I depend on homebrew/dupes/openssh (which is not
actually permissible in homebrew/core, but just for the sake of testing this
here), then the test passes. The homebrew/dupes/openssh formula is 7.4p1, so
this bug appears to be specific to 6.2p2 (possible all of 6.2 or all of 6.x?)

Note this is

yosemitevm:brew brew$ ssh -V
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

Sorry: to clarify my previous remark: i don't think gpg should change from its
current behavior during *encryption*. I do think it should be more constrained
in its output during *decryption*.

I don't think it's a problem that the files created during encryption simply
obey the umask.

I do think that when gpg creates sensitive data, though, it should limit the
mode of its output to the mode of its input (filtered by the umask, of course)

if the mode of the input is INMODE, and the umask is UMASK, during decryption,
when gpg creates an output file, it should set the mode to (INMODE & ~UMASK).

(if gpg is decrypting and sending output to stdout, perhaps it wants to try
fchmod (1, INMODE & ~UMASK) as well?)

well, it looks like i stand corrected: the problem happens both in encryption
and decryption. i *meant* to post about decryption, but i only pasted the setup
part... :p

[1012]anarcat@curie:~130$ rm foo
rm : supprimer fichier 'foo' ? y
[1013]anarcat@curie:~$ gpg foo.gpg
gpg: encrypted with 4096-bit RSA key, ID A51D5B109C5A5581, created 2009-05-29

"Antoine Beaupré <anarcat@orangeseeds.org>"

[1014]anarcat@curie:~$ ls -al foo*
-rw-r--r-- 1 anarcat anarcat 4 fév 6 13:16 foo
-rw-r--r-- 1 anarcat anarcat 594 fév 6 13:04 foo.gpg
[1015]anarcat@curie:~$ chmod 600 foo.gpg
[1016]anarcat@curie:~$ ls -al foo*^C
[1016]anarcat@curie:~130$ rm foo
rm : supprimer fichier 'foo' ? y
[1017]anarcat@curie:~$ gpg foo.gpg
gpg: encrypted with 4096-bit RSA key, ID A51D5B109C5A5581, created 2009-05-29

"Antoine Beaupré <anarcat@orangeseeds.org>"

[1018]anarcat@curie:~$ =k^C
[1018]anarcat@curie:~130$ ls -al foo*
-rw-r--r-- 1 anarcat anarcat 4 fév 6 13:16 foo
-rw------- 1 anarcat anarcat 594 fév 6 13:04 foo.gpg