For remaining changes in 2.2, I pushed changes into gniibe/t7855 branch.
rGbd65b06b74c2: gpg,gpgsm: Don't lock recursively when KEEP_LOCK is enabled.
rG423fd047da87: kbx,gpg,gpgsm: Add FP-close method for keydb to close before unlock.
rG966258ac5f99: gpgsm: Fix delete and store certificate locking glitches.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, Oct 15
I pushed changes into gniibe/t7855 for compressing the keybox.
rG8cc2a0e0ffee: gpg: Minor clean up for keydb_lock API.
rGe4d3c3aa2220: kbx,gpg,gpgsm: Introduce keybox_compress_when_no_other_users.
rG3e441d5b299f: kbx,gpg,gpgsm: More changes for compressing the keybox.
Tue, Oct 14
Then, we need to integrate following commits of 2.2 into gniibe/t7855 branch:
rG43fe9073aa81: gpg,gpgsm: Tweak the locking of the pubring.kbx
rG8491aca73cff: gpg: Revert the always locking introduced with 43fe9073aa
rGad4a5117ab1c: gpgsm: Properly release the lock when compressing a pubring.
rG7962eca3a023: gpgsm: Change delete and store certificate locking glitches.
rG22f9c4a3b3c1: gpg: Release lock after close also in the compress code path.
I created gniibe/t7855 branch for this issue.
To start with, I forward-port/cherry-pick 2.2 commits to the branch:
rG39430d9f78dc: build,common,g13,sm,tools: Require GpgRT 1.56.
rGe71aca2a628d: common: New function gnupg_remove_ext.
rGe38c5f7d5873: w32:common: Take care of possible race on startup under Windows.
rG7bfd37e305c0: common,w32: Always use share mode readwrite for the keybox.
Mon, Oct 13
Fri, Oct 10
This does not occur any more in Gpg4win-5.0.0-beta369
I understand that this is for 2.6.
Thu, Oct 9
Except for the release/unlock thing after keybox_compress I already have the other fixes in my 2.2 commits. I noticed that the gpgsm keydb lock/release stuff differes from the one for gpg: For gpg we use the keybox_lock function but that is bot used at all by gpgsm. In theory this should be unified but I fear a regression risk and thus for 2.2 we better don't touch it.
The latter is also the case for deleted softkeys.
Might be related to T7836?
Shall we merge this with T2196 ? BTW, I have some unpushed commit and a test installer.
Here are places where I found problems.
The regression that the Welcome screen didn't go away after generating the very first key has been fixed. The fix has been backported for VSD 3.4 and VSD 3.3.
I was asked to test this again with a newer version. With Gpg4win-5.0.0-beta369 not much has changed, you still can choose "Certify" on the only secret key and the certify window only allows "Cancel". Difference is only that now the "Certify with" line is empty:
Wed, Oct 8
Tue, Oct 7
Mon, Oct 6
Thu, Oct 2
This happens only in the 64-bit builds, i.e. with Gpg4win 5.
I implemented that in the old 2.2 branch for easier testing.
Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.
I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.
Wed, Oct 1
The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.
Here is a possible fix:
Tue, Sep 30
Fixed and backported for VSD 3.4 and VSD 3.3.
Mon, Sep 29
Thu, Sep 25
We were testing different things. This instance of the move to folder issue is fixed, for variants we'll open new tickets with clear test cases.
Sep 24 2025
Also implemented for 2.2
The following workflow works for Markus and me:
FWIW: The fix rO75f46829054e is part of GpgOL since 2.6.3
Same behavior (on vsd-3.3.3-beta90.12 @ win10) for smime encrypted mails:
I can't find any causes of slowness in keyboxd initialization. I think that there is a situation where it simply takes time on Windows.
Sep 23 2025
Looks good to me on vsd-3.3.3-beta90.12 @ win10:
what ever was fixed with the attached commit we can not test.
I see no workaround.
The attachments in the original mail are not gone, yes.
But the mail can't be forwarded with them.