Feedback from the lab is that they'd recommend returning a specific error code that indicates that the prime search failed and then relying on the caller to decide whether to loop or bubble up the error. I'm not sure who we would consider to be the "caller" of the relevant generation function in this case, though.

Ahh, this is about cross-compiling. I keep forgetting this.

We use the tooling from debian buster. We do not compile any host tooling as part of the build, except for QtBase tools.

I'm wondering if this happens when users have made some other application window active. In this case, I'm pretty sure there is no way on Windows to bring the result dialog to the front. An alternative might be to use a notification to inform the user that the operation is completed, either always or only if we notice that the result dialog isn't active.

I'll close this. Feel free to reopen if you think this would still be useful.

In T5716#152555, @aheinecke wrote:

Ingo: Exactly we have the problem that we don't compile build tools before building for the target. So we take the build tooling like kconfig_compiler from the system we compile on. This means that we compile with the tooling from debian buster. Except for Qt which handles stuff like that directly and builds for example moc and the other tools correcly for the build system first.

Full ack.

For the record, I am for the deletion as long as it is guarded by a safety check.

Here is my proposal patch:

diff --git a/random/random-drbg.c b/random/random-drbg.c
index 5a46fd92..f1cfe286 100644
--- a/random/random-drbg.c
+++ b/random/random-drbg.c
@@ -341,6 +341,9 @@ enum drbg_prefixes
  * Global variables
  ***************************************************************/

Done. Note that different from the comments in your example a non-negative ValidityPeriodInDaysMax value implies that an expiration date is required. This way it's possible to require a validity period of at least 10 days, but still allow unlimited validity.

Done. This also fixes the state of the encryption check box in case the OpenPGP key type is forced.

That sounds reasonable. The FIPS 186-5 draft (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5-draft.pdf) covers this in section A.1.3, although I'm not quite sure why a lower bound for p was chosen compared to q. The comment that seems to have triggered this change is published on page 68 of https://csrc.nist.gov/CSRC/media/Publications/fips/186/4/final/documents/comments-received-fips186-4-december-2015.pdf by Allen Roginsky. It only contains a suggestion of 20, presumably for both numbers.

In Kleopatra's KeyToCardCommand there is this comment

/* TODO DELETE_KEY is too strong, because it also deletes the stub
 * of the secret key. I could not find out how GnuPG does this. Question
 * to GnuPG Developers is pending an answer

before a commented out code snippet that asks the user whether the key should be deleted locally and, if the user confirms, asks the agent to do DELETE_KEY --force <keygrip of subkey>.

I checked FIPS 186-4 (and FIPS 186-5-draft). It is Appendix A 1.3.

I've just had an issue probably related to this.
Outlook was showing an error message like the following: "Empty messages cannot be encrypted" (I am translating, so the exact message may differ)

Works for Kleopatra.

Done. I have also tried to make this dialog as accessible as possible as prototype for other form-like dialogs. The error reporting could still be improved by specifying what exactly is wrong instead of simply saying what could be wrong, but QValidator is too limited for this.

Seems we can close this bug.

We have not seen this problem anymore in recent versions. Thus closing.

We have a solulion for this bug. For further improvements we will use T5882.

• Fixed in 2.3
• assert replaced by a fatal error message

Printing a note as we do in --edit-key is a good idea.

Passing fds etc adds complex extra code to gpg-agent. This was not the original design goal, although we violated this anyway by have some OpenPGP specific code there. This needs more thinking. Due to our internal use of OCB we can't make it FIPS compliant without large changes.

I have not yet tested OpenSSH 9 and thus the patch to master is here just as a test. Please better use gnupg 2.3 (stable) instead of 2.2 (LTS) because it is unlikely that we will backport all this new ssh stuff.