dirmngr Windows DNS resolution of pools (Re: Problem refreshing keys)

[Phil Pennock]

On 2018-06-14 at 06:24 -0400, Jerry wrote:
> gpg-connect-agent --dirmngr "GETINFO version" /bye
> gpg-connect-agent: no running Dirmngr - starting 'C:\Program Files 
> (x86)\Gpg4win\..\GnuPG\bin\dirmngr.exe'
> gpg-connect-agent: waiting for the dirmngr to come up ... (5s)
> gpg-connect-agent: waiting for the dirmngr to come up ... (4s)
> gpg-connect-agent: connection to the dirmngr established
> D 2.2.7
> OK

Oh dear.  Sounds like there may be an issue with DNS resolution on
Windows and dealing with pool hostnames.

  gpg-connect-agent --dirmngr KILLDIRMNGR /bye
  gpg-connect-agent --dirmngr
  > KEYSERVER --hosttable
  > KEYSERVER hkps://hkps.pool.sks-keyservers.net
  > KS_GET 0x4D1E900E14C1CC04
 [warning: lots of output]
  > KEYSERVER --hosttable
  > /bye

There should be around five to nine IPs returned from the last
"KEYSERVER --hosttable"; if you only see one, could you also use
whatever tools are used for DNS resolution at the Windows command-prompt
and see what that tooling says?

I can't help any further, I don't use Windows and so just can't help
more (pragmatic backing out, not philosophical).

In the meantime, look through  and
see if there's any you recognize as belonging to anyone you personally
trust; look for a green box in the hkps column, it's "highly likely"
(but not certain) that you can use https/hkps with just the hostname
shown in that table.

Configure a keyserver which works for you until such time as GnuPG's DNS
resolution on Windows manages to handle pools correctly.  Werner?

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Silencing MDC Warning with gnupg 2.2.8.

[Ralph Corderoy]

Hi Werner,

> > remove the MDC warning from stderr, allowing the rest of stderr's
> > content to pass?  Downstream of this command is unhappy otherwise.
>
> Why do you need stderr at all?  These are diagnositics for human
> consumption.

But stderr shouldn't be ignored.  Perhaps something unexpected appears
on it without affecting the exit status thus downstream of the program
using gpg doesn't just ignore stderr; it expects it to be empty and
checks it is.  Now it's not and downstream shouldn't know about a
gpg-specific stderr warning so I'll modify the script calling gpg to
delete one instance of that warning from stderr.  Thanks for confirming
there's no other way.

> > gpg(1) still documents --force-mdc and --disable-mdc, saying they're
> > now no-ops, but --no-mdc-warning is undocumented despite still being
> > accepted and also a no-op.  This hampers investigating why
>
> There is no reason to document a dummy option which never affected the
> behaviour of gpg.

It clearly did affect the behaviour else I wouldn't have needed to use
it, but I've raised the point so I'll let the matter rest, along with
the NEWS error.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users