GPGME does not use gpgv. What Justus likely meant is that we would need to change the common code used by gpgv and gpg. That may give problems in GPGME.

Funny. We should make show-unusable-subkeys the default to detect such flaws ;-)

With the exception of Windows, we only provide source code. Thus you need to compile it for your platform yourself or a find a distribution which comes with GnuPG.

To avoid a single point of failure I would prefer to keep the wiki off from al-kindi and, if Intevation agrees, to keep it where it is.

Also note that --faked-system-time is a debugging aid and nothing you should use under production. A wrong system time is a security problem anyway because it invalidates assumptions gpg takes. A small clock skew is annoying but the way to avoid is is easy enough.

In fact, on Windows you would need to have a system service. We did this in the past for the dirmngr but remove that feature due to possible security problems and problems during installation.

BTW, dirmngr has an option --disable-ipv4.

If you don't have a TCP enabled OS, you can use configure --disable-dirmngr.

Done with commit rGa69464b0b6da.

auto-key-locate now defaults to "local,wkd" and --auto-key-retrieve is also the default.

Thanks for that. gpg-agent 2.1.23 or 2.2.0 will have a new default of --no-grab which can be reverted using the new --grab.

I have changed gpg-agent to make --no-grab the default. The new option --grab can be used to revert this.

Feel free to push it to the main repo at git.gnupg.org (similar to scrute). I granted you the required rights.

As said that is a distro thing and nothing we, as upstream authors, will decide for those who build gnupg on their own. Reading README and following migration instructions is a MUST for everyone installing a new version of a software.

Please ask any Unix sysadmin for help. Paid support is available from the companies listed here: https://gnupg.org/service.html and there are lot of others.

It is there for a purpose. If the distros want to enforce a certain policy, they can do that. But we can't do that.
Sure, we could print a warning note. But then we would need to print a lot of warning notes all over the place to the effect that nobody will care about that and ask for an option to silence them.

Yes, any auto-key-locate entry should disable the defaults.

Stephan released revised document which should fix this.

We should publish a status report about the campaign. I'd suggest to do this a few days before the 2.2 release.

I would not say that this remark is in a dark corner. Migration steps are actually important for, well, migration to a new version.

Grabbing the keyboard is an important X feature and not related to gtk etc.
It has two purposes:

• Make sure that the Pinentry has the focus
• Avoid that other users can grab the keyboard and snoop on the input.

These days the latter is not so important anymore, given that most of us have only a single user on the systems.

I don't know. We only provide binary packages for Windows.

The reason for that cruft is that James originally suggested to have that even in the tarball but later reverted his idea.

E194 started a bit too late but here we go:

So your suggestion is that

auto-key-retrieve
auto-key-locate local
auto-key-locate wkd
auto-key-locate dane

shall be the new default unless --disable-dirmngr is also used?

That's it. I can reproduce this on Debian.

Patch breaks the tests.

Just a few comments while glancing on the text.

We can't close this bug because the main thing is to define a policy on how the GnuPG icons can be used. For example do we allow their use by proprietary software to indicate that they use GnuPG below the hood?

I don't like this patch because it is too large for what it achieves. The common way how we override global options is to save the old option, set that option, process, and the restore the option. In the revoke code we already do this for opt.armor.

I recall that we had the same problem back in 2010 and solved it. Please describe the ABI differences.

I had a long discussion with Stephan on this and he convinced me that this is the Right Thing to do. Anyway, in the last meeting with the customer we agreed on this behaviour There is a table in the minutes.

The usual 'g' from triggering Gnus to get new News/mail. From time to time it happens that I hit g but having switched to the wrong buffer.

debug dns

log-file whateveryouwant

A new installer is now available:

Patched installer is better. This is also a good test on whether the build works with custom patches.

How, shall we build just a new patched installer or do a full new release?

That was an easy one.

According to POSIX stat(2) follows a symlink and thus /etc/resolv.conf is the right name to use. (To stat /etc/resolv.conf itself lstat(2) would need to be used. ). I just checked the macOS man page and it says nothing to the contrary.

Unless --quiet is used we now print

Can now be found in the 2.1.22 man pages.

It don't think it makes sense to put any work in this. rfc4880bis defines new cipher modes and a new ESK version which would be a good occasion to implement this for the new AEAD mode.