D399: 921_0001-fix-libgpg-error-lock-madness.patch

Werner, you closed this issue with (the now removed) T1448 (wk on Jun 24 2014, 01:42 PM / Roundup) stating:
"You may use --ignore-invalid-option to list options which are only implemented
by gpg2."

This option seems only to be supported in gpg.conf, not on the command line.
(but this is no problem for me)

And it generally works fine (thank you!), just not in this special case here,
becaue gpg1 accepts the option "--debug-level" as valid, but does not allow
any arguments (neither numbers nor e.g. "basic").

The result (with "debug-level basic" in line 42) is:

$ gpg
gpg: /home/thomas/.gnupg/gpg.conf:42: argument not expected

I'm currently using gpg (GnuPG) 1.4.18 from Debian jessie.

As I understand it, "debug-level" is intended to just be a dummy option in
gpg1 to avoid problems with this option appearing in gpg.conf, correct?
So we have two possible solutions:

• either remove option "debug-level" (and rely on "ignore-invalid-option debug-level")
• or accept an argument for "debug-level"

Indeed, I confirm that the newly updated version 2.1.16 fix this issue, thanks a
lot for doing this portability work!

The same problem reproduces with gnupg2 installed from Homebrew (w/o GPGTools patches).

I've updated the patch series here to the series we're using in debian for 2.1.16.

D389: 918_0005-dirmngr-Drop-useless-housekeeping.patch

D390: 917_0004-dirmngr-Avoid-automatically-checking-upstream-swdb.patch

D391: 916_0003-dirmngr-Lazily-launch-ldap-reaper-thread.patch

D392: 915_0002-dimrngr-Avoid-need-for-hkp-housekeeping.patch

D393: 914_0001-dirmngr-hkp-Avoid-potential-race-condition-when-some.patch

In practice, dirmngr from git master still wakes up every few seconds due to the
ldap-reaper thread, even if no connections to ldap have ever happened.

the patch dirmngr-Lazily-launch-ldap-reaper-thread.patch avoids this additional
wakeup at least for those dirmngr instances that have never used LDAP.

Fixed in 03a65a5. The time for doing a tofu --with-tofu-info --with-colons
listing is now similar to doing a pgp listing.

Please reopen if there are still unresolved issues.

$ time gpg2 --with-tofu-info --with-colons --no-auto-check-trustdb
--no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg
--trust-model pgp -k >/dev/null
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m1.972s
user 0m1.940s
sys 0m0.028s
$ time gpg2 --with-tofu-info --with-colons --no-auto-check-trustdb
--no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg
--trust-model tofu -k >/dev/null
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m2.252s
user 0m2.172s
sys 0m0.020s

I suspect that the problem is the same as T2817.

Andre and I chatted about this issue offline, and I now understand what the
problem is. The TOFU_STATS status line (as documented in gnupg/doc/DETAILS) has
a "validity" field that is a number between 0 and 4 where 1 to 4 indicate how
confident we are that the binding is valid, and 0 means that the binding has an
unresolved conflict. The problem that Andre has observed is that this field is
not set to 0 if there is a conflict.

As a matter of fact, the validity field is never set to 0. This is completely
redundant as the same TOFU_STATS status line has a policy parameter, which is
"ask" if there is a conflict. Moreover, overloading this field in this way
causes a loss of information. Just because there is a conflict doesn't mean
that gpg shouldn't report the validity, or that the client can't made use of it.

Thus, in my opinion, the right thing to do is to simply use the <policy> field
to detect whether there is a conflict. Werner has suggested that this is wrong,
but I couldn't follow his logic. Thus, I'm adding him to the nosy list and I
hope he can clarify what he wants here.

The ssh.scm failure is still happening intermittently with 2.1.16

https://bot.brew.sh/job/Homebrew%20Versions%20Pull%20Requests/1733/version=yosemite/console

$ ssh -V
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

Ah I spoke too soon. Just got the ssh.scm:
https://bot.brew.sh/job/Homebrew%20Versions%20Pull%20Requests/1733/version=yosemite/console

No problem. Thanks for looking into it.

My fault. Sorry.

Everything looks fine now that I removed all of the dependencies and started
from a blank slate. Sorry for the noise.

So far I'm not seeing the old "FAIL: gpgtar.scm" and "FAIL: ssh.scm"

Were those specifically fixed in some new commit(s), or am I just lucky so far?

This has been changed in 2.1.16 to happen only every minute. Along with the
wakeup being done at the full second (as has been agreed upon for other
daemons), this should be more of an annoyance than a real problem.

It has been confirmed that 2.1.16 solves the problem.

The reason for the crash is that 2.1.15 is calling gpgrt_set_syscall_clamp
before nPth is initialized. The nPth initialization was changed in 2.1.15 so to
solve problems on some other platforms.

We see no such failures for our builds (on El Capitan and now on Sierra). We
use these configure flags for all our builds on macOS:

  ./configure --prefix=/Users/jenkins/prefix/native
  --enable-maintainer-mode \
  --enable-wks-tools --enable-g13 --enable-symcryptrun \
  --enable-gpg2-is-gpg --with-libiconv-prefix=/Users/jenkins/pkg
  'CFLAGS= -D_DARWIN_C_SOURCE=900000L -fPIC' \
  'CXXFLAGS= -D_DARWIN_C_SOURCE=900000L  -fPIC -std=c++11'

--enable-maintainer-mode should not be needed, it is only used to
re-create Makefile when they have been added and to enable more
warning flags.

Thanks for the report. Unfortunately we do not have a regression test key for
--export-ssh-key and thus this bug slipped into the release.

Caused by commit d20107f6d.

However, if I turn the reading area/preview are on, anything works fine :/

Hi,

thanks for your message. I installed the gpg4win beta 194 (3.0.0, released at
15th November), however, Outlook now crashes with another error message:
Runtime Error!

Program: C:\Program Files\Microsoft Office\root\Offie16\OUTLOOK.EXE

This application has requested the Runtime to terminate it in an unusual way.
Please contact the acpplication's support team for more information.

The error message occurs, when I _select_ an encrypted/signed message in outlook
(preview window is off, so the message should probably not be loaded, yet). I
can't open the message itself (but I'll need to enter my private key pin).

Is this related to this bug or should I open a new one?

Best,
Florian

It is simply not implemented, yet. We need to do this of course instead of
fixing the website.

Yes, I have seen that URL but what I like to get an answer to my question here
or on gnupg-devel. I do not want to follow a possible long thread of some Linux
distribution.

We had to change some init things to better support some non-Linux OSes. This
2.1.16 will be a bit different and may solve your problem.

I've just announced a new 3.0 beta that contains the updated GpgOL

http://lists.wald.intevation.org/pipermail/gpg4win-devel/2016-November/001659.html

Please let me know if it still crashes for you with that version.

OK, I don't care enough to warrant more discussion/work on this.
"Unknown elliptic curve" is already better than "Invalid elliptic curve".

We're shipping these patches in debian unstable as of 2.1.15-9.

D394: 912_0145-dirmngr-Lazily-launch-ldap-reaper-thread.patch

D395: 911_0144-dirmngr-Drop-useless-housekeeping.patch

D396: 910_0143-dimrngr-Avoid-need-for-hkp-housekeeping.patch

D397: 909_0142-dirmngr-hkp-Avoid-potential-race-condition-when-some.patch

D398: 908_0141-dirmngr-More-win32-system-daemon-cleanup.patch

There was a long drawn out discussion as to the validity of "-hardfloat" in the
triplet name. You can peruse at https://bugs.gentoo.org/show_bug.cgi?id=584052 .

I am not a dev and have pretty much given up. The Gentoo devs are adamant that this
is an upstream problem.

The algorithm parser works by checking the known "classic" algorithm and then
assumes that anything else is an ellptic curve. You see that all over the place
where you can enter an algorithm name. Thus there is no way to change this.

1.25 has been released.

ah, misread the 2.1.16 part, so yes, it seems to be fixed.

Where do you take it from that keyid-format none should result in the full
fingerprint being shown?

The man page:
"none" does not show the key ID at all but shows the fingerprint in a separate
line.

OK, then this is just an issue for interactive usage, but still an issue.

When using a script you should not parse the human readable output.

gpg2 --status-fd 2 --verify /tmp/msg

[GNUPG:] VALIDSIG 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1 2016-11-14 1479138285
0 4 0 1 8 00 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

See https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS
for the meaning of these fields

In gpg2.1.16 the fingerprint is also used instead of the keyid if you do:

/opt/gnupg/bin/gpg --keyid-format none --verify foo.sig

Where do you take it from that keyid-format none should result in the full
fingerprint being shown?

To be clear: I want the

• less specific and
• already existing

error message "Unknown algorithm" (instead of "Unknown elliptic curve", which is
not correct in too many situations)

ping

Sorry for the delay in getting back to you on this issue. I think you mean they
have undefined trust (that's what I get here). Undefined trust means "not
enough information for calculation" (from trustdb.h).

Can you clarify what you mean by validity conflict?

Distinguishing between 32 and 64 bit Windows in the same development package
works on Windows but only because 64 bit Windows also supports 32 bit Windows.
On most other platforms this is not the case. For a different ABI it is quite
common to require the installation of a platform specific development package.

You won't change the design to support sloppy build systems which would only
trigger hard to find bugs.

The --quick-gen-key command with the additional option is for use by scripts and
they should be able to read the manual.

If you look at the code you should see why it is a lot of work for a bit more
specific error message - we already have way to many messages. I could easily
find dozens of other places where we - in theory - could primt more specific
error messages. That would turn into a neverending story.

Fixed in 40e5ff0a0084c0d9521b401db4f38885bfdae233.

The string "Unknown algorithm" already exists. Because it is less specific, it
does not indicate that there is a problem regarding support for elliptic curves
here.