Fix keyring handle caching for windows
Open, WishlistPublic
Actions

Assigned To

None

Authored By

	dkg
	Apr 19 2017, 6:20 PM

Description

This bug was created by 5556eca5acd46983bff0b38a1ffbc2f07fbaba9f which intended to improve keyring access performance on Windows. A workaround d3d640b9cc98dd0d06b49a2e4d46eb67af96fe29 disabled the caching again.

Maybe a new report would have been in order to fix this but as this task is mentioned in the comment disabling the caching and the commit message I decided it would be better to edit this report.

The original report was:

I have encountered a problem with 2.1.20 writing to my public keyring.
I was using the pre-compiled binaries on Windows 10.

When editing/refreshing keys, or running gpg --check-trustdb, at the
end of the operation the command window gradually fills up with
repeated lines of:-

gpg: waiting for file 'C:/[path]/gnupg/pubring.kbx' to become
accessible ...

These lines keep coming until I close the command window, or CTRL C
then RETURN, or terminate "GnuPG's OpenPGP tool (32 bit)" in Task
Manager.

Oddly, creating new keys does not seem to trigger this (Or else the
problem is intermittent.)

The problem went away when I switched back to GnuPG 2.1.19.

Details

Version: 2.1.20

Revisions and Commits

rG GnuPG
	rGe80925171ddb gpg: Disable keydb handle caching only for W32
	rGd3d640b9cc98 gpg: Disable keydb handle caching

Related Objects
Search...

		Status	Assigned	Task
		Resolved	aheinecke	T3103 Release Gpg4win 3.0 stable
		Open	None	T3097 Fix keyring handle caching for windows

Event Timeline

dkg created this task.Apr 19 2017, 6:20 PM

dkg created this object in space S1 Public.

Had same problem with waiting for .../gnupg/pubring.gpg - changed back to version 2.1.19, too [Windows 7, 32bit]

MFPA added a subscriber: MFPA.May 21 2017, 11:56 AM

According to @MFPA still a problem on 2.1.21.

Unknown Object (User) renamed this task from GnuPG 2.1.20 on windows 10 fails with "gpg: waiting for file 'C:/[path]/gnupg/pubring.kbx' to become accessible ..." to NATIONAL SECURITY. FEDERAL OFFENSE 12-20 FEDERAL PRISON.May 23 2017, 4:09 AM

Unknown Object (User) closed this task as Invalid.

Unknown Object (User) updated the task description. (Show Details)

Unknown Object (User) removed a project: Windows.

Unknown Object (User) removed subscribers: • werner, MFPA, hiker, dkg.

aheinecke renamed this task from NATIONAL SECURITY. FEDERAL OFFENSE 12-20 FEDERAL PRISON to GnuPG 2.1.20 on windows 10 fails with "gpg: waiting for file 'C:/[path]/gnupg/pubring.kbx' to become accessible ...".May 23 2017, 8:07 AM

aheinecke reopened this task as Open.

aheinecke updated the task description. (Show Details)

*restored the issue after spam edititing*

I Put this down to the general keyring corruption we had with 2.0.20 but if you see this with a keybox this can't be the case. I saw the problem, too but when I switched to a smaller / different keyring the problem was gone so I did not report it. I'll try to debug this / get at least some debug output.

aheinecke added a parent task: T3103: Release Gpg4win 3.0 stable.May 23 2017, 8:12 AM

I have generated a new pubring.kbx file by using GnuPG 2.1.19, following the instructions at https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox, starting
from my existing pubring.kbx that worked up to and including 2.1.19.

Early days yet, but so far my new pubring.kbx is working with both 2.1.20 and 2.1.21.

I bisected this to: 5556eca5acd46983bff0b38a1ffbc2f07fbaba9f
GnuPG apparently keeps the keyring open in some situations and then fails trying to modify / rename the pubring.

It did not happen with some of my smaller testing keyrings but I reliably was able to repdroduce this through "gpg --update-trustdb" on a production size keyring. I'm looking at the commit now to see if I can find the problem.

I don't see a way to make the intention work on Windows without mayor changes. As far as I can see it keeps the pubring open for the full gpg.exe run after a getkey is done and only closes it in gpg_deinit_default_ctrl so any modification to the pubring after it was accessed in the same process once will fail with a sharing violation. And I don't know how we can decide when callers will modify the pubring after a getkey.

Werner: Are you ok with reverting this change?

I was about to suggest that. However, please keep the code but disabled only the filling of the cache. And keep this open so that I can look for a real solution.

aheinecke added a commit: rGd3d640b9cc98: gpg: Disable keydb handle caching.May 30 2017, 10:26 AM

aheinecke renamed this task from GnuPG 2.1.20 on windows 10 fails with "gpg: waiting for file 'C:/[path]/gnupg/pubring.kbx' to become accessible ..." to Fix keyring handle caching for windows.May 30 2017, 10:40 AM

aheinecke reassigned this task from • werner to • gnupg-hackers.

aheinecke lowered the priority of this task from Unbreak Now! to Wishlist.

aheinecke updated the task description. (Show Details)

aheinecke added a project: gnupg.

• werner added a commit: rGe80925171ddb: gpg: Disable keydb handle caching only for W32.Jun 13 2017, 9:13 AM

marcus removed • gnupg-hackers as the assignee of this task.Jul 17 2017, 6:27 PM

marcus added a subscriber: • gnupg-hackers.

Fix keyring handle caching for windowsOpen, WishlistPublicActions