I noticed it happens after entering the passphrase, and only using the
inline editor to answer.

we now have a DCO from @Valodim

If we only need it for backward compatibility, then the configuration in gpg.conf should *not* be overriding the preferred, forward-looking form of the configuration (in dirmngr.conf). If it is low priority to fix this, then there will be a generation of GnuPG users and toolchains which deliberately configure the value in gpg.conf instead of dirmngr.conf because they'll know that's the more robust way to do it.

@johng: I understand your problems and recall that Linux systems had a hard to time to replace all bashism with standard Posix. The problems with /bin/sh on Solaris seems to be even more persistent.

This seems to be closely related to T4257 for which I have a fix under test. The problem is that we pass the fd used by the caller to create the data object to gpgsm and close that very fd. The descriptor passing involves an implicit dup so closing is in theory okay but we should not close an fd which has been set (w/o dup) by the caller.

Fixed with gpg4win 3.1.9.

I wrote the script and the intention is supporting old systems using POSIX shell. Our goal here is: Not introducing (additional) dependency to Bash.

Thanks for your feedback Werner.

@werner, My usual approach for private branches is to prefix with dkg/, but (a) playfair rejects branch names with a /, and (b) i'm not the author of these patches, and i didn't want to claim credit that doesn't belong to me.

Please use a private branch as usual. There has been no agreement or a discussion over this change nor do we have a DCO from him.

I've pushed @Valodim's proposed patches to the fix-4393 branch in our git repo. they look good to me, and i think they should be merged to master.

We also have not DCO on record for @Valodim

Please use a private branch for such patches (dkg/fix-*) as you did in the past.

Feel free to fix it but a "make -j3 distcheck" MUST work.

I think this commit should be reverted -- if the test fails we should figure out why and fix it, because the logic of the test is correct.

It also passes for me with python 2.7.16 (debian package 2.7.16-2).

i think you mean t-decrypt-verify.py, right? That seems to indicate a problem on the targeted system that we ought to fix, rather than just commenting out the test. t-decrypt-verify.py passes for me when i test it with python 3.7.3 (debian python 3.7.3-1). what version of python are you testing with?

Unfortunately this is not the case. I had to remove the test code from t-decrypt-verify.c (7d0a979c07d2) to let "make check" work.

Sorry for the truncated commit. the sentence should have been:

This is all valid Bourne shell syntax. In detail:

Release done.

Can you please explain the commit messages. It seems the message was truncated.
And a failed test is a no-go in the regression test suite. A make check fails and thus the make release (or make distcheck) won't work either.

I have a larger change for the wait code in the works. This will go into 1.14.0 but not in 1.13.1

Thank you very much for your quick action!

Hi Andre,

Hi,
as usual, thanks for your help.

@gouttegd good catch!