Thomas: Done. I was able to login to the wiki using my roundup credentials again.

(I cannot assign the issue to you.)

You're welcome. By the way, you may be interested in this PR since you are
obviously a stakeholder in the matter:
https://github.com/Homebrew/homebrew-core/pull/11083

Please feel free to comment/suggest/etc. if you have any thoughts!

Hi, I have been assigned to this bug, and we'll get to the bottom of this.

The plan is to patch the tests to dump the location of tools it thinks it should
use. I'd like you to run the tests with that patch then.

Thanks for working with us on these issues. It is really appreciated.

Fixed in 6993e42088c191f18468317ba2b5b8fbc8c3edff.

Werner: Will you provide a new authentication methods for people participating
in the GnuPG communit?

What should we do until then?
The wiki is potentially interesting each day. It is probably easiest for the
users if you restore the old behaviour until a new authentication method for the
GnuPG-Community is available. Otherwise users must change their credentials two
times (First to the separate wiki authentication now and then to the new one
once it is available.)

What is the estimated roadmap for replacing roundup?

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.

Any other suggestions?

Please assign this issue to _me_ when ...

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.

This seems to be a bug in our new resolver library. I have contacted the author
for assistance.

Hello :)

this is very interesting indeed. However, we focus our development effort on
GnuPG 2.1 nowadays, and a lot has changed since then. Would you be so kind to
redo your analysis on the current version and/or supply us with information how
to use secretgrind?

This bug report simply asks to solve the generic problem of GNUPGHOME being
larger than sun_path. Justus's proposed mechanism is only one way of solving
that problem.

Another proposed mechanism is what i originally proposed in T2964 (dkg on Feb 17 2017, 01:52 AM / Roundup), which
*does* address remote filesystems and re-mounted filesystems.

I don't undertstand the critique about the code not yet being mature. Code
doesn't become mature by not being written, it needs to be written first and
then tested in order to become mature.

Lastly, i think if we expect that /run/user/$(id -u)/ is a "simple dependency"
for building other software, we need to make that expectation explicit someplace
reasonable (e.g. doc/HACKING or something similar)

#2991 is a duplicate of this issue.

This is a duplicate of #2990.

Hey :-)

Glad to see I'm not the only one ;-)

Prototype in

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/justus/issue2826-0

this prototype turns the use of uninitialized values into errors that are easy
to detect. Fail early.

I've tried latest master and it no longer hangs for me.

Thanks. Changing the status to not-released as this is fixed.

Indeed, I can reproduce this.

PS: Hi flokli :)

I just tested it with gpg4win3.0.0-beta215

gpgsm -v --output Downloads\kitten.gpg --recipient jochen@intevation.de

Downloads\kitten.jpg

gpgsm: certificate #13/CN=Email CA 2013,O=Intevation GmbH,C=DE
gpgsm: Die CRL konnte nicht geprüft werden: Ungültiges CRL Objekt
gpgsm: Benutztes Gültigkeitsmodell: Schale
gpgsm: Hinweis: Verschlüsselung für `jochen@intevation.de' wird nicht

möglich sein: Ungültiges CRL Objekt

    gpgsm: Ungültiger Befehl (Es gibt keinen implizierten Befehl)

So the CRL file was not automatically pulled via console either.

This was with gnupg 2.1.19 I think it's a duplicate of T2984 if the CRL
can't be loaded sending an S/MIME mail will fail.

I tried it on two different autohrities.

https://ssl.intevation.de/:

    gpgsm -v --import F:\zertifikate\SMIME\emailca2013.crl
    gpgsm: no issuer found in certificate
    gpgsm: Grundlegende Zertifikatprüfungen fehlgeschlagen - nicht importiert
    gpgsm: no issuer found in certificate
    gpgsm: Grundlegende Zertifikatprüfungen fehlgeschlagen - nicht importiert
    gpgsm: ksba_cert_hash failed: Kein Wert
    ksba: ber-decoder: node `?': TLV length too large
    gpgsm: gesamte verarbeitete Anzahl: 2
    gpgsm:                        nicht importiert: 2

https://www.rz.uni-osnabrueck.de/dienste/unios_ca/index.html:

    gpgsm -v --import Downloads\cacrl.crl
    gpgsm: unknown hash algorithm '?'
    gpgsm: certificate has a BAD signature: Allgemeiner Fehler
    gpgsm: Grundlegende Zertifikatprüfungen fehlgeschlagen - nicht importiert
    gpgsm: gesamte verarbeitete Anzahl: 1
    gpgsm:                        nicht importiert: 1

Seem to be different errors, but it doesnt work from command-line, too.

But the error from the front-end is different, when I tried importing via
commandline first:

Beim Importieren der Sperrliste ist ein Fehler aufgetreten. Die Ausgabe von

GpgSM lautet:

gpgsm: unsupported inquiry 'SENDCERT_SKI

93E3D83226DAD5F14AA5914AE0EA4BE2A20CCFE1 /CN=DFN-Verein Certification Authority
2,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE'

    gpgsm: response of dirmngr: Unbekanntes IPC "Inquire"

The error is the same for both CAs (except tfor the inquiry details).

And failing with IPv6 nameserver.

Here's running normally (not in a container) using IPv4 nameserver.

Arch Linux. The PID was due to running in a container.

Hi,

I am using systemd-resolved. It is listening on localhost UDP.

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.

4ce4f2f683a17be3ddb93729f3f25014a97934ad allows make check to complete without
the other workaround. So it works as advertised! Thanks, Niibe and Justus.

Error output:

dirmngr[9.5]: handler for fd 5 started
dirmngr[9.5]: connection from process 10 (1000:1000)
dirmngr[9.5]: command 'KS_GET' failed: Server indicated a failure <Unspecified
source>
gpg: keyserver receive failed: Server indicated a failure
dirmngr[9.5]: handler for fd 5 terminated

Yes, I think that would be good.

Sure: https://gist.github.com/ilovezfs/c0754cd0f5795b4830cc55cec1b0d016

I updated the logo and link to PlusServer.

The remaining issue is the link to drm.info. I contacted the people running the
site in January, and I was told that the issue will be dealt within a few months.

Hi,

can you tell me what kind of DNS resolver is listening on localhost? Does it
support UDP? TCP?

gnupg fixed in dd60e868d2bf649a33dc96e207ffd3b8ae4d35af.

ntbtls fixed in e582e91e47a164816ac074b9078dbed8537601dc.

libgcrypt fixed in 654024081cfa103c87bb163b117ea3568171d408.

libksba fixed in 561d03a008150c201ece22b29c97b24a1f6bf590.

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.

libassuan fixed in b26b73d04bff10852382113ae361ea5726661510.

libgpg-error fixed in 5e51b642f747547c737a7abbc37e65b0f630d188.

Note that simply reverting 02eb9fc9d5863abcfed6af704e618f8cac7cc2e8 will make
our sanitizer build miscompile, likely because -fsanitize=x breaks some test.
This would be easy to fix with my approach, but Werner does not like it.

Reverted 4b57359ef3ce0b87e15889e12ef0fcd23f62dcb4.

Fixed in 4b57359ef3ce0b87e15889e12ef0fcd23f62dcb4.

Fixed in 591b6a9d879cbcabb089d89a26d3c3e0306054e1.

Simple Y2038 problem. Fixed in de3838372ae3cdecbd83eea2c53c8e2656d93052.

It fails exactly the same way on 64 bit Windows too. Our 32 bit build machine,
an OpenBSD box, is fine. I'll have a look.

my resolv.conf
nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver ::1
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844

I have test with 2.1.19 it works the same

Since this is for command-ssh.c, we can't change the protocol (the client is SSH
process, which doesn't use libassuan).
Here, the purpose of the code is getting PID of peer, so, we can do something
except FreeBSD.

I think that it is fixed in: f7f806afa5083617f4aba02fc3b285b06a7d73d4

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.

Werner does not think that this is a problem and does not want me to spend time
on this.