Neal, this is still not fixed in 2.1.19.

We have seen this today also in another Kleoptra warning box. The text was not
localized but the error description (from gpg-error) had a broken Umlaut.

Yes, please do. Look at trithemius so see how to run several boa instances.
You really need to give the binary another name.

Justus, please remove the option --disable-tools. gpgconf is a core component
and always required, as weel as some of the other tools.

Note that roundup will be decommissioned in the near future, thus the wiki needs
to switch to another authentication method anyway.

Can you develop a fix based on the result of your prototype? I mean a short fix
without all the code changes from the prototype.

I agreed in T2964 (wk on Mar 01 2017, 07:31 AM / Roundup) to auto create socket directories. I would like to do that
only for a tmpfs but we can also try to do this always. Adding a inotify watch
to remove the directory is more complex and I am not sure whether this is really
needed. The other thing is simple and we could do that for 2.1.20.

The whole IPC thing is pretty complex and adding a non-standard hack as proposed
by Justus will for sure cause breakage on some platforms.

Yes, we should document /var/run recommendations in the README. I will do that
for the next release.

Please remove the drm.info logo and url. This is an FSFE project and (iirc)
they stopped the DRM project and thus tehre is no budget for doing even trivial
things.
They scared the voluntary sysadmins mostly away.

What OS are you using? It looks like A Linux distro but the process id 10 is a
little bit unlikely.

Please add

verbose
debug ipc,dns
log-file /foo/bar/dirmngr.log

to dirmngr.conf, kill dirmngr (gpgconf --kill dirmngr), and retry. Show us the
log then.

Justs, can you please check this bug. It is related to the migration to libdns
and thus we should consider this a bug.

Justus, I mentioned several solutions on Jabber which do not affect the rule not
to modify CFLAGS.

What's your /etc/resolv.conf ? Would you mind to also test with 2.1.19?

Does this work on the command line?

Which gpg4win version?
Does this work on the command line?

My main reasons why I don't want to consider this now are:

• That code is not written and thus will not be matured.
• It does not solve the major problem why we moved to /var/run, namely remote file systems and avoidance of possible re-mounted file systems
• The claim that /var/run/user does not exists is not valid, because that is a simple dependency for building the software or using it with non-common setups (remot, long $HOME). Thus an admin will anyway be on duty and adding a few lines to /etc/rc.local is not a bug deal.

FWIW, we may try this in 2.3 see T2987.

The page now links to the Wiki which makes sure that things are up to date.

Neal: Do you have an answer for him?

Fixed with commit b1f48da for 2.1.20

Changed category to pinentry - this is a pinentry-gnome (ie. gcr) problem.

Tried with ntbtls and gnutls - both work fine now. Given the work we did with
recent release I will close this bug now.

Did you changed --default-cache-ttl or --max-cache-ttl to zero or another small
value? The multifile feature requires that the passphrase cache has been enabled.

Duplicate of T2962

I think it is easier to enforce this than to handle bug reports due to
export/import and whatever problems.

We should better fix that by adding a new API to libassuan so that we have that
code only once.

Thanks for the report.

Shall I then thake this bug?

That implicit local is for backward compatibility and to avoid network lookups
as much as possible (privacy leak). "clear" is required because auto-key-locate
is cumulative.

I doubt that this is Windows only. On Linux we use our own driver but on
Windows we have to resort to PC/SC. My educated guess is that we are in some
blocking system call which is not npth_unprotected.

I have to refine my statement. We store the 'ultimateley trusted flag in the
trustdb and thus we require a trustdb when creating a new key. That is so that
we know the key has been created by us and is not an imported key.
Thus for most commands the trustdb should not be created but for key generation
it is better to safe that ultimately trusted flag in the trustdb.

Thanks. Can you please run the test again with

make check BIN_PREFIX=/usr/local/Cellar/gnupg21/2.1.19

This seems indeed a different problem than 2979.

SSH_AUTH_SOCK seems not to be set. I would suggest to try

mkdir /run/user/YOURUID
chown YOURUID /run/user/YOURUID

and try again.

Duplicate of T2980

Please describe your platform.
I guess the log is the same as in T2980, thus I will merge them.

Let's keep this one open to track missing options.

Isn't this the same as T2975 ?

The --hostable option is a debugging aid and only used manually.

The nsswitch items "mymachine", "resolve", and "myhostname" are not known to
libdns but should have been skipped. "files" is the first entry and should have
delivered the result.

Seems that libdns does not pick it up /etc/hosts

Fix pushed. Thanks.

Simply not implemented. Will be in 2.1.19

Thanks for reporting. Fixed in master for 2.1.19.

And a second message

Finally fixed in 2.0.11
(restored T1001 (wk on Mar 03 2009, 04:58 PM / Roundup))

(sorry, I accidentally removed the attached while while editing the mime type)

Can we test whether /run is mounted on a tmpfs ?
should we assume that /run is always on a tmpfs but /var/run is a classical Unix
w/o a tmpfs? Or is it better to have a configure option.

I can imagine to agree to auto-create the directory on a tmpfs.