Thank you for the reproducible test case. Confirmed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 24 2022
Mar 21 2022
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.
Mar 18 2022
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.
Mar 16 2022
Mar 9 2022
Fixed in master and 2.2 branch.
Feb 18 2022
Feb 17 2022
Thank you for your suggestion.
Feb 10 2022
It was addressed in rC04f325d8917d: released 1.1.4 as "(obsolete)" feature, in Aug 2001.
Feb 9 2022
Instead, let us remove the feature.
Feb 2 2022
@gniibe Thanks a bunch for the quick fix!
Feb 1 2022
Pushed the change in rE433aba9e778e: build,tests: Fix detection of have_lock_optimization..
@marv Thank you for your report.
Jan 31 2022
Hey gniibe,
Jan 25 2022
For the record, there is a new report on the mailing list about this module on MacOS:
Thank you, applied both of two patches.
Jan 24 2022
Thanks. Looks good to me.
Jan 20 2022
Test cases are recovered in rC535a4d345872: fips: Recover test cases for selftest, add skipping in FIPS mode..
Jan 19 2022
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.
Pushed the change in rC76aad97dd312: fips: Reject shorter key for HMAC in FIPS mode..
Jan 18 2022
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;
Jan 17 2022
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.
Jan 12 2022
Jan 11 2022
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.
Jan 10 2022
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.
Jan 6 2022
Now, unwrapping supports both cases (KW and KWP).
Jan 4 2022
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.
Dec 21 2021
We talked today about the renaming the current "linux" entropy module to "oldlinux" would make sense.
Dec 17 2021
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.
Dec 16 2021
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..
Dec 14 2021
Dec 10 2021
Thank you, applied.
Dec 9 2021
It turned out that the new *.inp files are not part of the release tarball, which makes the tests from generated tarball fail. The attached patch should fix this issue.
Thank you, applied.
Dec 8 2021
Sorry for the noise. There were couple of other places which I missed initially and which are covered in the v2 patch which follows:
It turns out together with rCe96980022e5e some tests are failing in FIPS mode. The attached patch should handle the failures.
Let me explain concretely.
Excuse me NIBE san. What if any action do you expect me to take on this matter?
__outer