Sorry, I thought I would receive an email when this was updated.

We don't do this on-the-fly to avoid cluttering the /run/user with directories.

So, I was expecting gnupg to use /run/user/$UID/gnupg/. However, if GNUPGHOME is
set, it uses /run/user/$UID/gnupg/d.$GNUPGHOME_HASH/. Therefore, by "littering",
I assume you mean littering /run/user/$UID/gnupg/ (otherwise this argument makes
no sense).

I'm leaving this here for future readers as I can't find *any* documentation of
this behavior (the use of d.$GNUPGHOME_HASH).

---

Regardless, my actual goal is to move the homedir to ~/.local/share/gnupg (not
have multiple homedirs) as described in (T1456)
so I really do want sockets to go in /run/user/$UID/gnupg/. However, I'm
guessing that's not going to be possible.

Justus: I told you several times that we are not going to change working code
for no good reason. Even if your hack (I call it a hack because it does not
work with getsockname) would make it, it does not solve the major problem: The
inability of creating sockets on certain file systems. THAT is the major reason
why we moved to /var/run.

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.

I'm not sure why you call it a hack. I've been looking at POSIX, [0] introduces
pathname resolution, and the terms 'relative path' and 'absolute path'.

0: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13

Neither the page for connect [1], nor the one for bind [2] state that the path
used to connect/bind unix sockets must be an absolute path.

1: http: / / pubs.opengroup.org/onlinepubs/9699919799/functions/connect.html#
2: http: / / pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html#

Furthermore, my test across a wide range of UNIX implementations did not show
any issues with using relative paths.

Ok, closing this bug. Feel free to reopen it if you reconsider.

Fixed in 88f1505f0613894d5544290a170119eb538921e5.

Are they sending ASCII armored files (those with "-----BEGIN PGP MESSAGE-----")
of binary data?

They might have used the -t (--textmode) option and removed that.

But more likely is that this is one of the usual CR,LF problems. For example
when using FTP, and sending binary data, it is important to switch to binary
mode first. WIthout looking at the data it is hard to help.

DUPLICATE

Okay. So the actual cause is that we print data for a key (usage, expire, and
possible more) which we should not do. That data comes from self-signatures and
those can't be verified because we have a time warp. That should be the same as
with invalid self-signatures - what do we do in that case?

merge_keys_and_selfsig is called, but because of the clock skew no self
signature is considered and hence the expiredate is not initialized.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20170317 12:57]:

Fixed with commit 69c521d.
You can reconfigure your server. Thanks.

What are the reasons that expredate is not valid?
merge_keys_and_selfsig() not called for sure, Anything else?

It would appear I was wrong. The localhost address should not have been in the
/etc/resolv.conf. I have removed it and the standard-resolver option and it is
working. I have tried this several times.

I marking this as resolved since I think the issue is fixed. If this is not the
case, please reopen.

I'm marking this as resolved since I think is fixed. Please reopen if this is
not the case.

This should be fixed in b1106b4 . The problem had to do with an incorrect
assumption that a key with policy 'ask' necessarily had at least one conflict.
This assumption may not hold if --tofu-default-policy is set to ask.
Thankfully, the assertion caught this.

Fixed with commit 69c521d.
You can reconfigure your server. Thanks.

There is no easy fix. We see the key usage as SCEA because pk->pupkey_usage ==
0 means 'default capabilities', and pk->expiredate == 0 means 'does not expire'.

Fixing this means being able to mark these fields as not valid, either by
initializing to a special value, or by having a separate bit to store the validity.

The former approach means taking away one more value and making it magical. It
requires a special 'not valid' value for every field, and the code has to be
changed to recognize that special value.

Using a separate bit is more general, so I went for that. Setting and testing
that bit is best done with introducing accessors. Asserting the valid bit in
the getters notifies us where to explicitly test for the validity.

Knowing where the problems are does not help if we have no way to know whether
the value in question is valid or not. Therefore, I don't see how to "lift" a
fix from the prototype.

For example, the prototype produces this crash:

% gpg --faked-system-time $(date --date "2016-07-01" +%s) -k foo@example.org
gpg: WARNING: running with faked system time: 2016-06-30 22:00:00
gpg: please do a --check-trustdb
gpg: key F35FB3E372211AFC was created 1 day in the future (time warp or clock
problem)
gpg: key F35FB3E372211AFC was created 1 day in the future (time warp or clock
problem)
gpg: Ohhhh jeeee: Assertion "(pk)->flags.valid_expiredate" in print_key_line
failed (../../g10/keylist.c:1861)

This is in print_key_line, I don't see how to fix this without being able to
tell whether the expiration time is valid or not.

Fixed in 38c955599f7c6c20faeec57d8e1df7d2c0eeba18.

Thanks for testing.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20170316 21:12]:

What is this Apache thing ;-). Frankly, I don't have one running and it would
be easier if you can remove it from testkolab.

What is this Apache thing ;-). Frankly, I don't have one running and it would
be easier if you can remove it from testkolab. The current Windows versions
should not have the problem anyway because warning alerts are skipped in ntbtls.
For gnutls I have a fix ready.

Yes, this fixed the segfault.

Would you be so kind to test the attached patch?

(I'm operating on a hunch. Also, I'm not happy with that feature I introduced,
so I'm going to remove it one way or another. But if this was the cause of the
troubles, I'd add a remark in the commit message.)

D414: 974_gpgscm-remove-immediates.diff

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20170316 14:37]:

Thomas: Is there any way how I can reproduce this now that you changed the
configuration of testkolab?

print x
$1 = (pointer) 0xa200b8868
(gdb) print *x
Cannot access memory at address 0xa200b8868

Just running gpgscm crashes with segfault. Is this backtrace sufficient or do
you need me to investigate further?

(gdb) run
Starting program: /root/rpmbuild/BUILD/gnupg-2.1.19/tests/gpgscm/gpgscm
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.25.90-1.fc27.ppc64
Error: init.scm:785: eval: unbound variable: define-macro

Program received signal SIGSEGV, Segmentation fault.
oblist_find_by_name (name=name@entry=0x20071a50 "args",
slot=slot@entry=0x3fffffffe680, sc=<optimized out>, sc=<optimized out>) at
scheme.c:1128
1128 s = symname(car(x));
Missing separate debuginfos, use: dnf debuginfo-install
libgcrypt-1.7.6-2.fc26.ppc64 libgpg-error-1.25-2.fc26.ppc64
ncurses-libs-6.0-8.20170212.fc26.ppc64 readline-7.0-5.fc26.ppc64
(gdb) bt
#0 oblist_find_by_name (name=name@entry=0x20071a50 "args",
slot=slot@entry=0x3fffffffe680, sc=<optimized out>, sc=<optimized out>) at
scheme.c:1128
#1 0x000000002001cd4c in mk_symbol (sc=sc@entry=0x20070660, name=0x20071a50
"args") at scheme.c:1384
#2 0x000000002001de6c in mk_atom (sc=sc@entry=0x20070660, q=<optimized out>) at
scheme.c:1496
#3 0x0000000020021114 in opexe_5 (sc=0x20070660, op=<optimized out>) at
scheme.c:5012
#4 0x000000002001d770 in Eval_Cycle (sc=sc@entry=0x20070660,
op=op@entry=OP_T0LVL) at scheme.c:5392
#5 0x000000002002712c in scheme_load_named_file (sc=0x20070660, fin=0x200d4de0,
filename=0x20038d30 "ffi.scm") at scheme.c:5782
#6 0x000000002000d590 in load (sc=0x20070660, file_name=0x20038d30 "ffi.scm",
lookup_in_cwd=<optimized out>, lookup_in_path=1) at main.c:180
#7 0x000000002000cf88 in main (argc=<optimized out>, argv=<optimized out>) at
main.c:268

I was able to reproduce it again. Maybe this bug depends on which keyserver in
the pool answers. The error is the same for Tor and non-Tor connections.

Thomas: Is there any way how I can reproduce this now that you changed the
configuration of testkolab?

Fixed in de3838372ae3cdecbd83eea2c53c8e2656d93052.

Fixed in a98459d3f4ec3d196fb0adb0e90dadf40abc8c81.

Can you be more specific?

Thanks for reporting this. I can reproduce it and will hopefully have a good
fix soon.

I don't know why, it is not repdroducible anymore.

Neal, this is still not fixed in 2.1.19.

Yup! Fix works. Thanks, Justus.

Fixed in a98459d3f4ec3d196fb0adb0e90dadf40abc8c81.

Thanks for helping us diagnose this issue. Finally I understood the problem and
was able to reproduce it. Please keep filing bugs :)

voilà: https://gist.github.com/ilovezfs/7979ace5e07e08fbb63155fd78c70d38

I just pushed c7833eca38fdb8d9ba7b59438ea87d651b8bf7ba that will help us
diagnose the problem. Would you be so kind to apply it and rebuild your package?

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.

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

Any other suggestions?

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.

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.