There is another case: RSA-4096 key. scdaemon rejects data by Invalid value. Unfortunately, there is no fix for this, as it's really too large. Even if scdaemon allows larger data, the card implementation rejects, when it conforms to PKCS #1 standard (data should not be larger than 40% of the modulus).

You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.

I have added the check for a possibly wrong symmetric password to QGpgMEDecryptVerifyJob because it relies on logging messages emitted by gpg which are not part of gpg's status API.

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.

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.

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

Not applying the change to GnuPG 2.2, users can use GnuPG 2.3 for that.

Confirmed to work, thanks!

Thank you. Applied.

Implemented.

Thank you for the error output.

it still shows the no certificate or invalid encoded error message:

I gave it a try. It works now, but it still shows the no certificate or invalid encoded error message:

Thank you. Confirmed.

Thank you for the reproducible test case. Confirmed.

Now, the problem is not about the case of pid == getpid () any more.

That would be bad for unattended use cases. Recording the time the lock file was created might be a solution. Then cleanup only after 15 minutes or so.

Note that there is a race condition still (after a fix of one race condition which may be somewhat likely and reproducible, and another fix of race condition when there is a stale lockfile).

Fixed another race in commit: rG2f1afc129662: common: Fix another race condition, and address the other one.

Before the fix above, https://bugs.debian.org/972525 can be explained by the following scenario:

Fixed in master. Should be backported when found stable.

Fixed in master and 2.2 branch.

Thank you for your suggestion.

It was addressed in rC04f325d8917d: released 1.1.4 as "(obsolete)" feature, in Aug 2001.

Instead, let us remove the feature.

@gniibe Thanks a bunch for the quick fix!

Pushed the change in rE433aba9e778e: build,tests: Fix detection of have_lock_optimization..

@marv Thank you for your report.

Hey gniibe,

For the record, there is a new report on the mailing list about this module on MacOS:

Thank you, applied both of two patches.

Thanks. Looks good to me.

Test cases are recovered in rC535a4d345872: fips: Recover test cases for selftest, add skipping in FIPS mode..

Sorry, it's my misunderstanding.
_gcry_fips_run_selftest can be run by GCRYCTL_SELFTEST.
I was confused by the function name. Perhaps, it is good to change the name of function to _gcry_run_selftest.

@werner Those removed tests are selftests which are only invoked by FIPS mode for its requirement of selftests.

AFAICS, the last commit removes some tests. We should never remove a test just because FIPS does not allow it. The old tests need to be run in non-fips mode.

Hi, @gniibe and @Jakuje. That fulfills the requirement and all the regression tests pass in FIPS mode. Thanks!

Pushed the change in rC76aad97dd312: fips: Reject shorter key for HMAC in FIPS mode..

And we need to fix selftest for shorter keys.

@pmgdeb : IIUC, what we need is:

diff --git a/cipher/md.c b/cipher/md.c
index 34336b5c..4f4fc9bf 100644
--- a/cipher/md.c
+++ b/cipher/md.c
@@ -903,6 +903,9 @@ prepare_macpads (gcry_md_hd_t a, const unsigned char *key, size_t keylen)
 {
   GcryDigestEntry *r;

In T5512#153650, @Jakuje wrote:

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.

libgcrypt-fips-indicator-kdf.patch3 KBDownload

I'm not completely sure but it might be convenient to mark HMAC keys with lengths less that 112 as non-approved in FIPS mode for both generation and verification. It could be easily implemented by adding a check using cipher/mac-hmac.c:hmac_get_keylen() or at the algo level. What do you think?

Thank you, applied.
Also, add another change.

Backported to 2.2, too.

I went through the documentation related to FIPS and updated some wording to match reality. It will probably require still some more work.

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.

Yes, we should introduce an INDICATOR_KDF thing.

I pushed the change: rC383866f014f2: cipher: Keep original behavior of Key Unwrap when not extended.

The previous comment should have come to the T5600. Sorry for the noise.

Sorry for resurrecting the done task, but I got a message from @pmgdeb who noticed there is mismatch between parenthesis in the --with-fips-module-version help string. The attached patch fixes the issue and add proper help text.

Now, unwrapping supports both cases (KW and KWP).

For unwrapping, it is good if we can support "automatic" unwrapping, apply W^-1 and check the first 8 octets to see if it's KW or KWP.

We talked today about the renaming the current "linux" entropy module to "oldlinux" would make sense.

Thank you for comments on random/rndlinux.c.

Pushed another patch to clarify the semantics of --enable-random-daemon;
It's only for building gcryptrnd and the test program getrandom.

Good catch. I pushed the change to remove use of random daemon remained.

Thank you for your quick testing.

The patch worked, thank you very much.

Thank you. Tested locally that it does what it is supposed to do and all tests passed for me as expected.

Reading through the changes, the content and usage of the getentropy looks good.

the random daemon is still part of the configure.ac and the undefined _gcry_daemon_initialize_basics() and _gcry_daemon_randomize() is still used under the USE_RANDOM_DAEMON guard in several places. I think at least the following cases should be removed too (or the configure check to be modified to throw error or warning):

Here is the change remained:

diff --git a/src/fips.c b/src/fips.c
index bcadc5f2..5499aee8 100644
--- a/src/fips.c
+++ b/src/fips.c
@@ -82,6 +82,12 @@ static void fips_new_state (enum module_states new_state);

Before rebasing, I pushed a change to simplify access to no_secure_memory variable by rC209d98dcf66b: Simplify the logic for no_secure_memory..