Page MenuHome GnuPG
Create Task
Maniphest T1249

renaming '...\pubring.tmp' to '...\pubring.gpg failed: Permission denied during key creation
Closed, ResolvedPublic
Actions

Description

I just switched from GnuPG 1.4.2 to GnuPG 1.4.10. as the encryption engine of my
program. Now I have an error during key creation. Below a description. As this
is a core GnuPG function, I classified it as urgent. As this error only happens
sometimes (but often when GnuPG is freshly installed), it will be hard to track
down.

I think it is the return of an old fixed bug with the Windows file system that
may now have returned in only very special circumstances.

Remark: This error never happened to me with GPG 1.4.2., when I created DSA/ELG
keys. (But mostly tested on WinXP, not Windows 7.

Immediate questions:
Is there a short-term work around?
Should I just return to version 1.4.2 for key creation?

Good luck and thank you for all your work.
Wolfgang

Happens when:
gpg 1.4.10 (MinW32)
Key Creation with batch file:

Operating system: Windows 7, 32 bit, Intel Core 2 Duo L7700 1.80 GHz

Happens intermittently.
Has has also happened when key directory was not empty before key creation, but
all files in it were empty.
Has not happened with other GPG functions used with v. 1.4.10, but I have not
tested it much either.

This is the error: Key creation with batch file cannot complete.
GPG's error messages were:

gpg: renaming 'E:/Users/Wolfgang/InstantCrypt_2.2/Keys\pubring.tmp' to
'E:/Users/Wolfgang/InstantCrypt_2.2/Keys\pubring.gpg failed: Permission denied
gpg: error writing public keyring
'E:/Users/Wolfgang/InstantCrypt_2.2/Keys\pubring.gpg: file rename error
gpg: key generation failed: file rename error
gpg: done

Content of keycreation batch file:

Key-Type: RSA
Key-Length: 2048
Subkey-Type: RSA
Subkey-Length: 2048
Name-Real: Tester
Expire-Date: 0
%commit
%echo Done

State of key directory after key creation:

pubring.bak 0 KB
pubring.gpg.lock 0KB
pubring.tmp 2 KB
pubring.gpg.lock 0KB
random_seed 1KB
secring.gpg 0 KB
secring.gpg.lock 0KB
trustdb.gpg 1 KB
trustdb.gpg.lock 0KB

  • End of Error description------------

Details

Version
1.4.10 (MingW32)

Event Timeline

Wolfgang_Schlage added projects: gnupg, Bug Report.Jul 13 2010, 12:42 AM
Wolfgang_Schlage set Version to 1.4.10 (MingW32).
Wolfgang_Schlage added a subscriber: Wolfgang_Schlage.
Wolfgang_Schlage added a comment.Jul 14 2010, 4:40 AM

I found the work-around:

Instead of using the "Unattended key generation", that is creating the key with
a parameter file which had produced this bug with the command line

gpg.exe --gen-key --batch [etc.]

I did the key generation the conventional way in which I feed gpg.exe the key
parameters one by one with this command line:

gpg.exe --gen-key (no --batch here, and no key parameter file!)

This worked fine *reliably* on the same machine that produced the described bug.
(I tested probably 10 to 20 times.)

This makes this bug much less urgent. I leave it as urgent for the time being,
because I think it should be documented (in the DETAILS file?) that the batch
version of the key creation can produce an error, at least in the Windows
version of GPG. Whoever takes care of this bug can then reduce the priority to
something less important.

Thanks you guys!

• werner lowered the priority of this task from High to Normal.Jan 10 2011, 6:40 PM
• werner added a subscriber: • werner.Nov 8 2012, 4:24 PM

Do you still have this problem with 1.4.12?

Wolfgang_Schlage added a comment.Aug 4 2013, 9:23 AM

Problem seems solved; reason very likely found.

After years of taking a break from GPG, I took the work up again. First I
upgraded to GPG version 1.4.14 (the currently latest version). Then, in
reviewing my previous work, I found that in the interprocess dialog between my
program and gpg.exe I had been sloppy and had caused race conditions. In the
process of improving these dialogs, the described problem disappeared, i.e. did
not come up again despite some intense testing. I hope it stays that way!

Thus, although I cannot put my finger on "the one" code change that did it, I
tend to think now that the problem has been mine from the beginning, namely that
I had programmed race conditions. The intermittent nature of the original
problem supports this assumption.

I apologize for any inconvenience that has caused.

• werner closed this task as Resolved.Aug 5 2013, 3:26 PM
• werner claimed this task.
xianghongai added a subscriber: xianghongai.Dec 13 2017, 11:01 AM

windows:

  1. exit gnupg software;
  2. ctrl+shift+esc: end the process that starts with the 'GnuPG's ...' character~；
  3. windows + r : %appdata%, delete ‘gnupg’ directory；