- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 7 2021
That reminds me that we we should replace libgcrypt's internal debug functions by those from gpgrt. We have a dependency for gpgrt anyway and thus we should avoid code duplication. Sure we will keep the existsing public functions but that is easy given that gpgrt comes with gpgrt_logv since 1.28 which we can make mandatory (currently libgcrypt requires 1.27 (from 2017, with 1.28 is from 2018)
I applied rC297d31294333: tests: Fix messages to STDERR when FIPS mode is enabled.. Please note that your intention to change check_digests is right, but your patch actually didn't; When a MD algo is not supported, gcry_md_test_algo returns != 0 (an error code), and it "continues" to next entry (before the change).
Thank you for your report.
Jul 6 2021
Check that the file exists and that you have permissions to read the file. You may use an editor to try this out.
In agent_write_private_key of agent/findkey.c, when file is available, it returns GPG_ERR_EEXIST error. Thus, private (stub) key will be kept.
With the planned new context aware pubkey functions we technically could do this change w/o an ABI break.
Jul 5 2021
This patch for libkleo fixes the build. Alternatively, updating extra-cmake-modules to 5.80 (where the target-variant of ecm_qt_declare_logging_category was added) fixes the build.
Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program:
https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
Jul 4 2021
Jul 2 2021
It is a matter of the used font. 2.2.29 will fix this problem.
In T5510#147840, @catenacyber wrote:Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2
curve=23 secp256r1 point=04555555ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff73a865e2e128733884fb82ce625ade822f7d8a59a4dcc09266966cf1bf082856 bignum=2020ff2020202020202020202020202020202020202020202020202020202020 nettle: 0 045549408909dd3e772d7d669f8fba2248d334b54be3d18833223d944a328948c76198ac3b29712256dcd9ce1a09471f04267684e1edd45910d61d0b7847db2d58 gcrypt: 0 047a6ec0df23082c8ce54c2b536d76b30464f4e1e690bb77665d298f05f0bee6806e7db3377141cc71ee30dcb8ffb7240bc3ecf29132ab5eb4ae03c067cea0d561
Jul 1 2021
Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2
Same error message in Windows 8.1 x64 with the commands:
gpg --local-user 0x12345678 --sign-key 0xABCDEF12 or: gpg --default-key 0x12345678 --sign-key 0xABCDEF12.
Very cool, I like it especially that you avoided a popup and used that action mechanism.
Jun 30 2021
When selecting a certification key without ultimate trust the message "Is this your own key?" is shown.
Thanks a lot.
Jun 29 2021
curve=23 secp256r1 point=040000ffffffff0000000000000000000000000000000000000000000000000000cfe26d107a5134d6feb38ce3577075bdc7aa70ff7523d3b203c8a973f2d3dc8e bignum=0000000000ff0000000400000000000000000000005d00003277002000010000 mbedtls: 0 04fd351b304ad50f36153d8193c4bbf7d4c3bee26e5af52a9c70133edfa62c273e05da8312615436e9c81b5b0624e68667233ace6307afc8056eae85049ca63226 gcrypt: 0 04d6915640b8ba3918f129c108f52f571ec28c1c89ad710b43928c3bd942eb29d8bf181e997b502abf12cf3606eb46379c59fd396bda7b45cdc75d429b2b37b15f
curve=24 secp384r1 point=0400000000000000000000000000000000000000000000000000000000000000000000000000fffffffffffffffffffffc1b0d6f8fb7f2de5b8875645b64042ae20f119f3e1cfefc0215857eeae5f4a8fca737057d69a42c44d958e7cfcc77ce6b bignum=ffffffffffffffffffffffffffffffffffffffffffffffffc7634d81f4372ddf581a0db248b0a77aecec196accc52972 mbedtls: 0 0400000000000000000000000000000000000000000000000000000000000000000000000000fffffffffffffffffffffce4f29070480d21a4778a9ba49bfbd51df0ee60c1e30103fdea7a81151a0b570258c8fa81965bd3bb26a7183133883194 gcrypt: 0 04fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffffff0100000000000000fffffffbe4f29070480d21a4778a9ba49bfbd51df0ee60c1e30103fdea7a81151a0b570258c8fa81965bd3bb26a7183133883194
The original idea with the DNS code was just to source copy it but it turned out that we need to maintain it in GnuPG. Thus adding support for SHA256 makes sense to keep the code current in case we ever need to use it.
Do I correctly understand that issue will be resolved on GnuPG side by tweaking key bits before private-key import/and/or/operations?
Jun 28 2021
P192, P224, P256 and P384 are affected.
Is secp192r1 only curve that is giving wrong results?
Attached patch should fix the issue: