Addressed in e1cf8bab319ba1dea41ba5d711dbb66ffd8e6fd6 and
16b202d9999591b71fb8bb49f6db10ef96d4cbe8.

Yes please.

Shall I look into this?

So this is about the new Python binding.
I would suggest not to build tye python support on systems with the old 2.0.24.
Note that 2.0 will reach EOL in 9 months.

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.

[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.

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?

Yeah I broke that by fixing GnuPG to output Console Encoding. Kleo uses Qt
::fromLocal8Bit which expects the GUI CP.

Messy stuff, need to figure out how to get the ACP through Qt or the QT Name of
the console codepage for conversion. This not only here but everywhere where
Kleo shows GnuPG's console output. There are also some bugs about this at
bugs.kde.org.

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.

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.

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?

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?

Done.

Thank you.
I have removed the hint about the login problems.

Please give Bernhard and me a head-up (outside this issue) as soon as you know
which authentication method/providers you will support.

I can confirm that I can login again.

@justus: Thanks for the quick fix!

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.