Adressed in 94645311f8a3e9ae33643512f87fbef41bf0556f.

The 4gb-packet test reads an OpenPGP message compressed with BZIP2. If that test fails, it most certainly means that you compiled GnuPG without support for BZIP2. You can check this with:

'82' is the line of the failing assertion.

Fixed in 01e84d429aeeb1450012ff0576a6a24de50693c6.

Ah right, that is bad...

Sure there is. Do ../configure --enable-languages= to build no bindings at all.

Fixed in 32b75fb7743f35936d7014fce33c90ba97dfa374.

The underlying issue has been dealt with.

This was effective and has been merged.

Fixed in 348da58fe0c3656e6177c98fef6b4c4331326c8e.

Well, if you ask *this* nicely, then I will most certainly get *right* to it.

You know what I find annoying? Me writing tests, and then on the first sight of
trouble, we back them out or disable them.

Indeed. We did not address the issues at all, we decided to skip all tests and
some fell through the cracks.

Yes, print *a was correct. Could you please do

  print *sc->load_stack[sc->file_i]->curr_line

there?

Indeed. I raised the limit to 5, do you think that this is ok?

What about gpgme_get_dirinfo ("agent-socket")?

I did not know about that, and that helps a bit, but has the downside that it
uses the GNUPGHOME from the process' environment.

I'm thinking about the following use case. I have created an ephemeral home
directory to contain the results or side-effects of some operation, and now I
want to talk to the agent that serves that particularly home directory. I
cannot use gpgme_get_dirinfo because that uses GNUPGHOME, and I don't want to
change the environment variable because that is a process-global thing and I
don't want to interfere with other threads.

I have looked into this. I installed Debian on an s390 emulator (hercules), but
have been unable to reproduce the problem there, maybe due to the emulation (it
is quite slow on my system, and the gpgscm interpreter seems especially slow,
maybe because of the challenge of doing branch prediction on interpreters).

Your stack trace suggests a memory corruption early during the initialization
("init.scm", the standard library, is being loaded), we see an error being
generated due to an unbound variable (i.e. the environment hash table is
corrupted / does not perform as expected). Then we see a segfault while the
history buffer is flattened into a list for the error message (i.e. hints at a
corruption).

Unfortunately, memory corruption bugs are very hard to detect in gpgscm due to
its use of a custom memory allocator. The allocator allocates large segments
using malloc and hands out cells from that pool as necessary. However, memory
is never freed, so tools like valgrind can not be used to detect use-after-free,
or even most out-of-bounds accesses.

I have been working on the low-level allocator last week trying to make it more
debuggable and memory errors more detectable, e.g. by moving parts of the
interpreter into readonly sections.

As Werner said, a stack trace with less optimizations would be helpful. Also,
is the problem always the same if it happens? If so, it would be interesting to
know what kind of variable is unbound (for that, inspect the 'a' parameter of
'_Error_1' [I'm attaching a pretty-printer for gdb, with that, do 'print a']).

Access to the porter box would be helpful as well.

As of 348da58fe0c3656e6177c98fef6b4c4331326c8e all Python tests are skipped with
GnuPG < 2.1.12.

Justus: I told you several times that we are not going to change working code
for no good reason.

Except that it is not working. If it was working, then
06f1f163e96f1039304fd3cf565cf9de1ca45849
would not be necessary.

Even if your hack (I call it a hack because it does not
work with getsockname)

1/ Yes it does. It returns precisely the path that was used in bind.

2/ We only use getsockname on sockets that were given us by a service manager
like systemd, and thus those sockets would be unaffected by "the hack".

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.

Please stop conflating these things. This bug is about "dirmngr and gpg-agent
should work automatically even when GNUPGHOME is larger than sun_path". It is
not about NFS or FAT or something.

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.

Addressed in e1cf8bab319ba1dea41ba5d711dbb66ffd8e6fd6 and
16b202d9999591b71fb8bb49f6db10ef96d4cbe8.

Yes please.

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

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.

[I'm doing s@://@: / /@g so that roundup does not complain about this message
having too many links.]

So I did that. There are two problems:

1/ We advertise URLs of the form 'https: / /git.gnupg.org/foo.git', but this URL
contains only the name of the repository as the path. In boa, I need to specify
a non-empty path in the ScriptAlias directive for the path to CGIs, and then the
script itself also needs a non-empty name. Neither pound nor boa seem to have
path-rewriting functionality, so I don't see how we can serve a git repository
using the 'git-http-backend' CGI this way (w/o patching boa that is).

I decided to be pragmatic about it (at least for the moment) and go for URLs of
the form 'https: / /git.gnupg.org/g/it/foo.git', so I can use 'ScriptAlias /g
...', and use 'it' for the script name. However:

2/ Something is fishy with the TLS setup:

% git clone https: / /git.gnupg.org/g/it/ntbtls.git
Cloning into 'ntbtls'...
fatal: unable to access 'https: / /git.gnupg.org/g/it/ntbtls.git/': GnuTLS recv
error (-110): The TLS connection was non-properly terminated.
% wget -O - --tries=1
https: / /git.gnupg.org/g/it/ntbtls.git/info/refs?service=git-upload-pack
--2017-03-16 17:34:02--
https: / /git.gnupg.org/g/it/ntbtls.git/info/refs?service=git-upload-pack
Resolving git.gnupg.org (git.gnupg.org)... 217.69.76.56, 2001:aa8:fff1:2100::56
Connecting to git.gnupg.org (git.gnupg.org)|217.69.76.56|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-git-upload-pack-advertisement]
Saving to: ‘STDOUT’

• [<=> ] 0 --.-KB/s 001e# service=git-upload-pack

000000d506bb9a836981e48c2e6939fb21480d97253a4588 HEADmulti_ack thin-pack
side-band side-band-64k ofs-delta shallow no-progress include-tag
multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.8.0.rc3
003f06bb9a836981e48c2e6939fb21480d97253a4588 refs/heads/master
00449fb1c710e821f27ac7039c2b3bdd584ccc6012e6 refs/tags/ntbtls-0.1.0
004750ad7a2206bac7682195e8285af96e0d790891b3 refs/tags/ntbtls-0.1.0^{}
00449b970fc16d5c257651c9377ec97fb255d2425583 refs/tags/ntbtls-0.1.1
00475de470fbeb7b6d92070206414d130dfb53d96e69 refs/tags/ntbtls-0.1.1^{}

• [ <=> ] 592 --.-KB/s in 0.003s

2017-03-16 17:34:02 (214 KB/s) - Read error at byte 592 (The TLS connection was
non-properly terminated.).Giving up.

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

Fixed in de3838372ae3cdecbd83eea2c53c8e2656d93052.

Fixed in a98459d3f4ec3d196fb0adb0e90dadf40abc8c81.

Can you be more specific?

I looked into this. Pound is configured to relay these requests to
127.0.0.2:80, but no backend listens there. git http-backend can serve these
requests, is a cgi program and thus needs a webserver to run.

https://git-scm.com/docs/git-http-backend

I believe we could setup another instance of boa for the purpose of running it.

Werner, if you agree to that plan I could give it a shot.

Andre?

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

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

Done.

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

(I cannot assign the issue to you.)

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.

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?

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.

Indeed, I can reproduce this.

PS: Hi flokli :)

Yes, I think that would be good.

Merged in 6c45eed62214b44fcc11e642b19df7b6ca0da0bd.

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.