Thanks for testing.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 11 2025
Aug 10 2025
Aug 8 2025
Aug 7 2025
Aug 6 2025
Aug 4 2025
That look s like a problems with logging to stderr in --server mode. On Windows fds 0,1,2 are special.
The advantage of using a fingerprint for referencing a key is that there won't be any collisions in the keyid. Further this unifies the schema with an LDS (Windows) installation where DNs must anyway be unique. But take care the client needs to support this new flag. This will be the case for gnupg >= 2.5.12 (cf. T7756)
1.11.2 has been release see T7642
Release done.
Aug 1 2025
Test on Windows by overwriting gpgtar from gpg4win-5.0.0-beta357 and also tested on Linux. Debian packages with patches are already available.
There is a new --keyserver-option update-before-send which is enabled by default.
Jul 31 2025
Jul 30 2025
But we emit a failure at the end of the gpg process; aren't we?
This might be related to the recent changes in now we spawn processes. Using gpgtar [...] --status-fd=3 3>a.log shows something different than directly using --status-fd=2. Do we handle the process termination correctly; i.e. wait for all status-fd output?
Note that 2.5.11 fixes a regression in 2.5.10 regarding the use of notations for 3rd party signatures. See T7743
Urgs
Jul 29 2025
The card returned these 32 bytes:
1883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286
agent_card_pkdecrypt however returned 33 bytes:
411883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286
Thus the indicator byte is 0x41. The specs (librepgp, rfc4880bis) say:
Jul 28 2025
Noteworthy changes in version 1.3.2 (2025-07-28)
Jul 25 2025
Jul 24 2025
This does not happen with gnupg24 because the cache has not been implemented there.