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.

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.

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.

Example:

[CertificateCreationWizard]
CN_placeholder=Common Name
CN_prefill=false
EMAIL_placeholder=name@example.com
EMAIL_prefill=false
NAME_placeholder=Firstname Lastname
NAME_prefill=false

I guess this is solved. Feel free to re-open and schedule for 2.2.34

Might be a TOR Thing?

FWIW: We need a DCO; see doc/HACKING.

No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)

I have decided to use two different sets of settings for the placeholders and for controlling the prefilling of the values. Overloading the semantics of a specified placeholder text would have confused users and developers alike.