dirmngr is now part of gnupg proper.
Original report was for dirmngr-1.1.0.

Thanks, Fix will go into 1.7.

Is this still a problem with 1.6.2 ?

Is this still a problem with 1.17 - guess yes. Can you please try and send me
the config.log from 1.17 or current master?

The context menu of the key manager now has a "refresh key" item.

Now, shall I add this to gnupg 2.1? To which tools? All or just gpg?

Does the patch work for you?

1.6.2 with the fix was released in August

Released with 1.6.2. on August 21.

2.1.1 has been released.

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.

Okay, fixed with commit 5cb6df8.

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

OpenPGP does not specify this. It is actually not easy to add another format
becuase that opens the path for all kind of attacks. Like with ELF comment
section you can do the same for any other data format. No, there is no ELF
parser in gpg and there won't be one for any other language.

Please take this to the gnupg-users ML or to the OpenPGP WG. Thanks.

Additionally to T1665 (wk on Jul 03 2014, 11:13 AM / Roundup) (outlining that a trust path to the global SSL companies
is available and thus resolving this):

https://files.gpg4win.org is verified by a certificate that is available over
https://ssl.intevation.de/ this site is "verified" by one of the preinstalled
companies. (You are hopefully aware that you just have to send them some bucks
and some unsigned mails with an @intevation.de address claiming that you are
intevation.de to get such a certificate)

We also bought a certificate for codesigning so that in Windows itself you get
an assurance that one of the >100 Root CA's in their certificate program earned
some money from us ;-)

Please check the openpgp signatures or the checksums in our release
announcements and decide for yourself if you trust us. We can just buy your
trust otherwise.

This should have been resolved a long time ago. There was a KDE bug about this
but I can't find it anymore.

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 :)

The language designers will almost certainly return the ball by saying that it
is not their job to define signatures :-)

Elves and dwarves aside, could we have a bottom signature format that would keep
files readable for Shellscript, Perl, Python, plain text and maybe a few more by
using the last line in the file as in my example? This is the main request here.

Should be fixed now.

The next version will no longer include the generated moc files.
It's not really a patch to backport (as you requested this in your mailing list).

In quilt you can just do something like:
quilt new remove-broken-moc-files.patch
quilt add qt4/*.moc
rm qt4/*.moc
quilt refresh

That is something you need to build into your language's interpreter or into the
OS proper (for the ELF, COFF, or the shebank hack). We can't do anything in gpg
with that. It is of course possible todo that. For example many years ago, I
wrote such a system for ELF with gpg used by a tool for signing and a dedicated
verification module for the OS.

If you like to discuss this, you may want to post to the gnupg-users ML.

understood - please note I used a very recent automake in testing this
without issue, but I only have an osx platform - others may experience
breakage.

I also ran into this problem with our (intevation's) debian packaging.

Just removing the .moc files worked as they were correctly generated
automatically (as they should be).

I'll commit a fix not to include them in the dist package anymore.

This is due to a newer automake. This is not yet supported due to backward
incompatibilities since autmake 1.13. The plan is to switch to a newer automake
with the release of Debian's Jessie. See README.GIT on how to use an
alternative automake version. There is at least one other bug regarding this
problem, thus I will close yours.

As noted on the ML we do our own selection from the pool and consider only A and
AAAA records. This needs to be changed of course. Unfortunately this won't go
into 2.1.1.

Yes, this is the case for a very long time. I also won't call this a
bug.

There is no way to protect an update by a lock without having write
permissions to the same directory. Well, one could setup a second
file system hierarchy below /var/run and use that for the locking
file. However, this assume that all process accessing the files are
on the local machine. One of the reasons why we can't use a locking
API are remotely mounted file systems. See the comments in
common/dotlock.c .

And yes, we need lock the file even if the local process as no write
permissions to the directory - other processes may have and the
reading process may thus read garbage.

By using --lock-never you assert that there is no other processing
writing to the gpg data files. Thus using this is the Right Thing.

Pushed.

Or use the new --quick-sign-key command ...

I assume this is related to T1630 which has been fixed

Fix has been released.

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

This has already been fixed as well as a couple of other bugs in 2.1.0.

I will release 2.1.1 soon despite that there are a few other bugs left open.
Feel free to reopen this bug if it persists with that new release (or the
current GIT master).

Thanks!

Applied:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=484465338ea6f5f12eb1341ca0ef84aa79224ed4

D274: 536_0001-pinentry-qt4-make-the-accessibility-part-optional.patch