- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 18 2019
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.
Jun 17 2019
@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.
Jun 16 2019
@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.
Jun 15 2019
Jun 14 2019
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:
Jun 13 2019
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
Jun 12 2019
Thank you very much for your quick action!
Jun 11 2019
Hi Andre,
Hi,
as usual, thanks for your help.
@gouttegd good catch!
The reason for this is the change to Kleopatra that the columns are configurable ( 4847fcc27afc8101752de82b0dd1f5fee027695d ). In the process we added additional columns like origin and to hide the "summary" column that the line edit for the recipients use we gave it an index number that was higher then our internal column count.
Thank you very much for the report. I can see this problem myself. It is strange because the code for that has not changed since 3.1.7 so it must be some sideeffect.
Thanks for the hwf-ppc.c. I've pulled the latest from upstream, applied the patches, and gotten the updated library built. Will let you know of any feedback from our performance team.
Jun 10 2019
Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.