I've just confirmed that the fixes in the commit "rE50e0f32b1935" above to configure.ca & tests/makefile.am do NOT fix the problem under MacOSX Catalina 10.15.7 using Xcode 12.4, gcc Apple clang-1200.0.32.28.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 25 2021
I'm getting the same error even when compiling with x86_64/glibc (from Apple clang-1200.0.32.28) :(
Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.
We should only allow this for v5. This way we get incentive to move forward. ed448 requires a newer version anyway and thus it is good to take this as an opportunity to also demand AEAD etc.
The branch gniibe/v5/448 has the implementation.
To be conservative, given the situation most implementations already support zero-removal and zero-recovery, it's better to output zero-removed signature, that is, signature with well-formed MPI.
My proposal is applying SOS (MPI with leading zero octets) patches, for 2.2, because there may be existing keys with SOS already.
It's not yet solved.
Reading the documentation of musl, it seems that there are no equivalent feature which detects if an application is single-threaded or not.
Nov 24 2021
In the libgpg-error implementation, it may skip synchronization when it can detect an application is single threaded. The t-lock-single-thread test checks if it really skips as intended.
Thank you.
Nov 23 2021
Thanks @ikloecker - I'll rebase to the original repo and send it to the email list.
And you may want to read the section "Sending patches" of https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING.
(forgot to upload the patch to the last comment)
I am fine with either way. The memcmp variant is probably cleaner to make sure all works as expected in all cases.
Hi Werner, Here is the DCO. Thanks.
Thanks for the well written bug report and the fix.
So that you don't need to chase the downstream bug report, the problem from a user's perspective looks like this:
Thank you. Extending the semantics of GCRYCTL_CLOSE_RANDOM_DEVICE sounds good to me. I think the deinit functions were created initially especially not to change the semantics of existing code using GCRYCTL_CLOSE_RANDOM_DEVICE, but I agree that it will probably not be an issue.