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

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.