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.

Thanks a lot. I will test as soon as you release the test build.

Hi,

Thanks for testing gpg4win This issue was already reported in T2335 and has
been resolved (but not yet released).

I'll upload a new beta next week.

Regards,
Andre

Still true for sending but for sending we don't have a choice. But decryption is
now done in a different thread.

I've tried this again with the current development version after a very large
refactoring how we handle mails. The bug appears to be gone. I've tested 10
times to send a file with closed / open outlook and with and without encryption
active.

If I install gpg4win-2.3.3 on the same system / setup the crash is reliably
reproducible.

It's still likely that we made a reference counting error internally in code
that was changed / fixed now. And Outlook released the Mail object too early and
crashed.

Kaspersky probably had some similar error in their code.

I'll upload a new Gpg4win beta with the new gpgol next. I'll ping in this issue
once thats done so you could ideally confirm that its fixed now.

That is a bit complicated and would require new strings. I do not think that is
justified.

I don't think there is an issue anymore.

Still in issue after we figured out that select could have been the reason for
this? The explict check for a valid FD number was added in June so before that
a segv could have been the outcome.

With the soon to be released gnupg 2.1.16 and gpgme 1.8 this will work.

If a keyring is non-readable (e.g. chmod 000 pubring.bkx), gpgme_op_keylist_next
will return GPG_ERR_OPENKEYRING instead of GPG_ERR_EOF.

The difference (according to the gpg agent log) is that gpg v1 is obviously caching
the decrypted private key used to decrypt the files using the option "-d --
multifile" whereas gpg v2 in my case repeatedly requests the decryption of the
private key for each single file. Any way to change that?

A little bit better, but that would still confuse me, as I did not intentionally
specify an elliptic curve.
What could help here is:

1. talking about algo/algorithm (that is shown in the man page as parameter for

--quick-gen-key)

2. saying which algorithm gpg saw.

If the error message had been "Unkown algo 'user@example.com'" I would
immediately know that I provided an email address where an algorithm was expected.

okay, changed to

Unknown elliptic curve

Andre said, category dirmngr is better