Applied as 091c35e. Thanks.

D280: 540_gpg211-dirmngr.patch

That is easy to fix - commit 3197f69 pushed.

Thanks.

The latest version is 0.9.7. Please report error only against the latest version.
It has likely been fixed.

The sem_post in enter_pth can't set ERRNO because we assert the return value
later. However, the sem_wait in leave_npth has the usual EINTR protection and
thus changes ERRNO. Needs to be fixed.

No this was on "the master of the day"

And with the dead server detection the case for "localhost lookup" already got
better.

But you could look at npth src/npth.c
I am pretty sure that npth_enter and npth_leave modify errno and that this
causes at least npth_connect not to set errno as expected.

This was straight 2.1.0, right? Please try again with 2.1.1 there are just to
many bugs fixs that it is not worth to look at 2.1.0. If it is still the case I
can look at (although that you assigned yourself ;-)

I had another go at this bug this evening. I had a keyserver with reproducable
failures (while I still could use it in gpg1). And suddenly during debugging it
all changed and worked flawlessly. I was down to npth_connect and after I had
added debug output in there it began to work (and kept working after removing
the debug output again, hrmpf)

With regards to the test case from T1773 (aheinecke on Nov 26 2014, 10:35 PM / Roundup). This now (after e8c0ed7 ) returns a
dead host.

Btw. I think the error message could be improved for dead hosts.

gpg2 --keyserver hkp://127.0.0.1 --search foobar
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Should be something like "No reachable keyserver found"

Assigned this bug to me to at least provide a clearer example.

Thanks for fixing the 127.0.0.1 lookup error :)

Pushed.

Give that the macro change is a no-brainer I will do that immediatly. Which
means this bug report can be closed.

Understood - would you like me to fix with automake 1.10, or park this
for a merge post-Jessie ?

automake 1.14 is not yet supported becuase it defaults to the new parallel tests
and automake 1.11 has no way to disable this tests (serial-tests option in 1.14).

After the release of Debian Jessie I plan to migrate to 1.14 and drop support
form earlier automakes.

Thanks werner -- I've filed an upstream issue to bring awareness of the change
to the software I use that was affected (duply/duplicity), I'm sure this is
going to pop up for others as 2.1 becomes more widely adopted. Maybe add
something to the release notes or docs for '--passphrase-fd 0' so folks know a
config change is needed in their apps and gpg-agent? Regardless, I appreciate
your help.

(marking as resolved)

If you add it to gpg.conf the Pinentry won't be used and there are fir sure
cases where things won't work. In an unattended use I can't see a problem right
now.

We can't change the behaviour of --passpharse-fd; it is widely used and:

  if ( !opt.batch && opt.pinentry_mode != PINENTRY_MODE_LOOPBACK)
    { /* Not used but we have to do a dummy read, so that it won't end
         up at the begin of the message if the quite usual trick to
         prepend the passphtrase to the message is used. */

think would break or - worse - may insert the passphrase into the message.

The passphrase is still used for symmetric only encryption in batch mode.

Roger that, thanks - I've tested it on a VM with my keys and things seem "like
they used to be" for scripting an automated passphrase entry. I specified them
in my ~/.gnupg/pgp.conf and ~/.gnupg/gpg-agent.conf since editing many
individual softwares is not possible at this time, it needs to be backwards
compatible.

What side affects (breaking things?) does having these options permanently
enabled in configs are there? Having the allow in gpg-agent.conf is harmless,
but what about the client side gpg.conf?

If client gpg '--passphrase-fd 0' is useless without '--pinentry-mode loopback',
why not make this an automatic added option (internally) if '--passphrase-fd 0'
is specified? Of what use with gnupg-2.1.x is '--passphrase-fd 0' without
'--pinentry-mode loopback'?

I double-checked the official docs, there's no mention of needing these new
loopback settings in the section for --passphrase-fd 0:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options

"If you use 0 for n, the passphrase will be read from STDIN." (but as we know
here, it's not unless the new loopback options are added)

Ah damn,..
Duplicate of
T1774

sorry.

Duplicate of T1774

Like gpgsm has done from its very beginnong, gpg now also does not pknow
anything about the secret keys. This is all delagted to gpg-agent. This means
that telling gpg a passphrase is useless.

But wait. There is a workaround: gpg has the new option

   --pinentry-mode mode
          Set the pinentry mode to mode.  Allowed values for mode are:

          default
                 Use the default of the agent, which is ask.

          ask    Force the use of the Pinentry.

          cancel Emulate use of Pinentry's cancel button.

          error  Return a Pinentry error (``No Pinentry'').

          loopback

                 Redirect Pinentry queries to the caller.  Note that
                 in contrast to Pinentry the user is not prompted
                 again if he enters a bad pass- word.

Thus by using

  gpg --pinentry-mode=loopback

you can do basically the same as with 1.4. It is well tested and
slighly different than in 1.4. Uou also need to configure gpg-agent
with

  --allow-loopback-pinentry

       Allow clients to use the loopback pinentry features; see the
       option pinentry-mode for details.

The problem was with that specific keyserver. If I use another keyserver it
works. The keyserver was the first one returned to me by using the
keys.gnupg.net pool and as gpg 1 works with it.

I've debugged the issue.

The test case is now reduced to:
gpg2 --keyserver hkp://127.0.0.1 --search foobar

Dirmngr logs:

2014-11-26 20:35:55 dirmngr[5892.1] getnameinfo returned for '127.0.0.1':
'localhost'
2014-11-26 20:35:55 dirmngr[5892.1] can't connect to '127.0.0.1': Success
2014-11-26 20:35:55 dirmngr[5892.1] error connecting to
'http://127.0.0.1:11371': System error w/o errno
2014-11-26 20:35:55 dirmngr[5892.1] command 'KS_SEARCH' failed: System error w/o
errno

In my case this is because common/http.c (connect_server) ~ line 2200

  ai->ai_family == AF_INET && (flags & HTTP_FLAG_IGNORE_IPv4)

Returns true for 127.0.0.1 (same for 75.75.183.132 which also explains why it
works with gnupg) the address is skipped but it is the only one -> loop finishes
with no errno set.

It is set in dirmngr/ks-engine-hkp.c which looks to me like: "If it is not
indicated that a host either uses IPv4 nor IPv6 ignore it." Which i find kind of
harsh. At least a debug output like:

      if (!hi->v4 && !hi->v6)
        log_debug("Ignoring host\n");

Should be added there and of course connect_server should return an appropiate
error in case it never actually tried to connect to a server.

While debugging this I think I found another issue. You are using errno after
my_connect calls. If this expands to npth_connect the actual calls are

enter_npth()
sem_post() modifies errno
connect() modifies errno
leave_npth()
sem_wait() //modifies errno

Afaik enter / leave in npth should save errno. I could not confirm that this is
really an issue with a test but I think it is.

A few Arch users are reporting the same regression/breakage, thread here:

https://bbs.archlinux.org/viewtopic.php?pid=1479136

Thanks applied.

Had a go at this myself. I've attached a patch that checks the gpg-agent version
before migration.

Output when an old version is found:

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: starting migration from earlier GnuPG versions
gpg: error: GnuPG agent version "2.0.22" is too old.
gpg: Please start an updated GnuPG agent.
gpg: migration aborted

Output when gnome-keyring running around:

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: starting migration from earlier GnuPG versions
gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool to not
interfere with the GnuPG system!
gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be started.
gpg: migration aborted
gpg: no default secret key: No secret key
gpg: signing failed: No secret key

The error message should also occur in case gpg-agent can not be started at all.
It happens when "GETINFO version" errors. So its generic.

D252: 507_0001-Check-gpg-agent-version-before-2.1-migration.patch

Meanwhile done.

There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.

Thank you for the prompt response.

I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?

This has been discussed at gnupg-users at lengths. You need to read the OpenPGP
standard to understand some of the defaults. For the others you may start yet
another disucssion thread at gnupg-users.

re 4) The iteration count used depends on the machine.

Fic for master with commit c434de4. However decryptyed files are not subject to
this because that would for sure breakk too man applications.

Fixed in master.

I meant 2.0.24 of course.

I consider to do this for 2.1

This has been discussed ad nauseam. Thus this will not be included.

D182: 410_0001-gpg-Compile-time-flag-for-RSA-key-sizes-4096.patch

Uploaded a new patch file - I missed a semicolon.