Thanks. Fixed for 2.2.22

Thanks for reporting. Fixed for 2.2.22. repeat==0 works like before and repeat>1 also (that is several passphrase pinentries will pop up).

I's say we should not do anything but solve that along with the move of all fd/fp/sock/HANDLE stuff to gpgrt to solve this at one place. We need that anyway to properly support Windows64. We won't be abale to do this for 2.3, though.

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

For GNU/Linux, it's done.

If you use

Hello,
just reading the issue in detail.

Just reading this issue in detail.

It is indeed a limitation. We added these options to support the Kleopatra GUI. To avoid problems with filenames with embedded newlines etc. Kleoptra uses a binary nuls to delimit filenames. And that is what we only support.

Thanks

No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.

Here's the patch:

I believe the problem here is OS X 10.12's (and above) System Integrity Protection (SIP). SIP protects system integrity by doing things like sanitizing environmental variables for system programs. Sanitizing environmental variables on system programs avoids code injections.

-std=c99 is probably the reason that the tests fail.

Fixed.

Please try with out supplied CFLAGS or change them from

@JW: @gniibe explained you the problem and provided a fix (i.e. use correct specifiction of the directory names). Changes to Makefile.in are a no-go because that is a built file and a real fix would need to go into libtool. However, for a couple of reasons we do not want to update libtool (e.g. too many breakages in the past, we have out own fixes in for Windows). Thus we consider this bug closed.

I understand your point, but your fix is not relevant

Thanks for your patch. I understand your point, but your fix is not relevant (for supporting all platforms). You can use that way in your build script, but we can't take that approach; The correct fix is fixing libtool.

I'm feeling difficulty to talk to you.

libtool works like this:

• For program without -no-install, it uses wrapper script specifying the runtime path to the library by LD_LIBRARY_PATH (or equivalent), so that the program can work without installation
• For program with no-install, it uses a feature (e.g., -rpath in ELF environment) to specify the runtime path to the library *in* the executable. The executable cannot be installed because the path of build directly is embedded in the executable.

@JW, I'm feeling difficulty to talk to you.

... no-support of slash at the end of path and duplicated slash, we won't fix.

T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation)

For the original problem of no-support of slash at the end of path and duplicated slash, we won't fix.

@JW, I'm afraid you are not able to read what I write here. This is not chat system at all. For chat system, please use XMPP on
gnupg-devel@chat.gnupg.org as written at https://gnupg.org/documentation/mailing-lists.html (if possible).

I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo

I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo, and I asked to fix your typo and test again.

... you are now describing another problem

@JW, you are now describing another problem, instead of the problem you reported.
I'm closing this one.

Taking: Still does not work although now --quick-set-expire is used by gpgme.

Awesome. Thank you for the explanation and for solving the issue.

We won't do such a interface now.

Thanks a lot.

Mitigations are in place for quite some time now; see T4755.

Fix will be in 2.2.22. Thanks for the report.

It was actually moved to noninstall in 2006. The reason or this is a conflict between the version of gpgsplit in GnuPG 1.4 and 2.0. Back then it seemed easier to keep on using the gpgpslit from 1.4 because that version was installed anyway. At that time gpg was called gpg2 we changed this much later and probably forgot to switch also to the gpgsplit from GnuPG 2.