Here is an experimental change to support the feature.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Fri, Jul 11
I'm testing the following patch with experimental change of libgpg-error.
Thu, Jul 10
In libgpg-error, we have: rE65114f24e13f: w32: More changes to the extended length path handling.
Wed, Jul 9
Sat, Jul 5
Fri, Jul 4
Thu, Jul 3
Wed, Jul 2
Tue, Jul 1
Fri, Jun 27
Thu, Jun 26
Wed, Jun 25
Tue, Jun 24
Fixed in 2.5.8.
secp256k1 failure:
https://lists.gnupg.org/pipermail/gnupg-users/2025-June/067731.html
Mon, Jun 23
Fri, Jun 20
OK. I'll add a code for setting the fallback value in _gpgme_io_subsystem_init and use it from get_max_fds.
For issues of get_max_fds, I created a sub task, although it seems not the direct cause of this particular problem.
Thu, Jun 19
I test following test program (gcc -o t-gmf t-gmf.c) on Debian machine of S390x.
Tue, Jun 17
In the log, we can observe duplicated lines generated by
https://dev.gnupg.org/source/gpgme/browse/master/src/posix-io.c$545
Example is like:
2025-05-19 20:16:35 gpgme[21970.55d7] _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1 2025-05-19 20:16:35 gpgme[21970.55d7] _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1
Done in 1.11.1.
Done in 1.11.1.
Done in 1.11.1.
Jun 13 2025
Reading https://openssl-library.org/files/blog/Request_to_Extend_IETF_WGLC_for_PQ_Key_Specifications.pdf ,
seed (with "S") is included in the private-key.
The commit rC23543b6c1497: Add mldsa_compute_keygrip and let private-key include "p". works well for me.
To support Dilithium, we need to extend data handling of libgcrypt.
I propose following changes:
- internal flag of PUBKEY_FLAG_BYTE_STRING to ask opaque MPI for data to be signed/verified.
- The format of data as: (data(raw)[(flags no-prefix)](value ...)[(label ...)][(random-override ...)]): message, context, and random. Optional no-prefix flag to ask specific way of signing, controlling the internal, for Known Answer Tests (siggen).
Jun 6 2025
My test coverage was not good (even if I daily use Curve25519 on Gnuk Token).
Your analysis is correct.
Jun 5 2025
The problem was: In scdaemon, PKSIGN with OPENPGP.3 didn't work well for Ed25519 (done by do_auth function in app-openpgp.c), when --hash=sha512 (not SHA1).