Fixed by jukvilli’s patch.
__outer
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 20 2021
That works, thanks. So does that become part of the next release?
__outer
Both are affected. I updated to reflect that I tested the newer version
FWIW, after the release I had some time and after some trouble with my Pi4B I ran into the same problem.
Jan 19 2021
Confirmed working after applying your patch!
Thanks for you report.
We plan this for 1.10 but it may also go into one of the next 1.9.x releases
Docs done.
Jan 18 2021
I am not sure. MD5 is still important for some applications, say CRAM-MD5. IIRC, back in 2008 we dis-allowed RMD160 and added separate RMD160 code directly to gpg to fulfill FIPS requirements.
Okay for 1.9.
Jan 15 2021
Note that even after rCce1cbe16992a: Disable non-allowed algorithms in FIPS mode, gcry_md_open won't return an error with disabled algo.
Jan 12 2021
Note: The commit in master (1.9) is rCe0898d0628789414
and in 1.8 it is rC03e6d6597198ee
The commit which fixes this is rC761a1a0d30
Jan 11 2021
Jan 8 2021
I agree to the sexp change - but it should not be backported to 1.8
For printing SEXP, it would be good to have this change:
rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.
I describe about rC6f8b1d4cb798: ecc: Consistently handle parameters as unsigned value..
Reading compressed point (in keys) is supported (except for NIST P-224). When curve point is represented in compressed format, it is correctly interpreted now. So, for example, I think that with 1.9.0, gpgsm can handle certificate which uses compressed format in its curve point representation.
Jan 7 2021
Yes, bug is also in 1.8 branch.
Do we need to backport to 1.8?
Do we really need this for 1.9?
What is the state of this bug? Reading is implemented - do we really need writing (maybe to support certain smartcards)?
It is possible to disable the mlock thingy and if that is not wanted the application should be modified to be suid(root) during Libgcrypt initialization - this is actually how we handle this in GnuPG. Or maybe I don't understand the bug described here. It seems to be more of a support question.
For security and auditing reasons a Libgcrypt SO may not be "unloaded".
gcry_ecc_get_algo_keylen has been added with commit a658c9ccc2c741f40b0b5cdbcd184cfb9a841d17 but documentation is missing.
Thanks. I added the OIDs and the missing curves. To go into 1.9
Jan 5 2021
Flagged as high becuase this is RC for Libgcrypt 1.9
Dec 30 2020
Reimplemented 8 block parallel in "vertical" orientation.
With little extra effort, stitched implementation turned out ok after all.
Dec 22 2020
Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=7532e27cacb74c92fd561524a0897163b0fcd7f4
Applied to s390x optimizations feature branch:
SHA256: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=0b555c3cc7c2b80ec2628685946a6139a1996911
SHA512: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=45f0ec0c4e3b08627cbf7e65f5f110c321710d01