Page MenuHome GnuPG
Create Task
Maniphest T1555

gpg(2) trying to lock secret keyring even if not req'd?
Closed, ResolvedPublic
Actions

Description

On my Mac I have my public keyring on a regular HFS filesystem, and my secret
keyring on a TrueCrypt volume which I only unlock when req'd. Trying to delete a
public key from my public keyring using EnigMail in Thunderbird failed. When I
investigated it I found that gpg2 couldn't lock my secret(!) keyring:

gpg: lock not made: link() failed: Operation not supported
gpg: can't lock `/Users/theUser/Documents/Encrypted/gpg/secring.gpg'

I don't see any reason why gpg2 should lock the secret(!) keyring when deleting
a public key from the public keyring, so I assume this is an issue in gpg2 (and
I can observe it in 1.4.x as well!)

Details

Version
2.0.21

Event Timeline

ralfbergs added projects: gnupg, Bug Report.Oct 11 2013, 8:48 PM
ralfbergs set Version to 2.0.18.
ralfbergs added a subscriber: ralfbergs.
• werner added a subscriber: • werner.Oct 15 2013, 4:18 PM

2.0.18 is quite old - please test with a decent version. Some time ago we
overhauled the locking code to better detect "broken" filesystems.

• werner added a project: Info Needed.Oct 15 2013, 4:18 PM
ralfbergs changed Version from 2.0.18 to 2.0.21.Oct 15 2013, 8:51 PM

Used the latest MacPorts version available as of today.

Now the picture changed somewhat:

  • 8x -----------

$ gpg2 --delete-keys 450F89EC
gpg (GnuPG) 2.0.21; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: keyblock resource `/Users/theUser/Documents/Encrypted/gpg/secring.gpg': No
such file or directory

pub 1024D/450F89EC 2003-02-03 PAUSE Batch Signing Key 2011 <pause@pause.perl.org>

Delete this key from the keyring? (y/N) y

  • 8x -----------

As you see gpg2 STILL for whatever reason tries to do "something" with the
secret keyring (even though I would not expect this since the command supposedly
only operates on PUBLIC keys), but this time it succeeds.

So this is only a minor annoyance, but still I consider it "quirkish."

• werner closed this task as Resolved.Oct 23 2013, 1:11 PM
• werner claimed this task.
• werner removed a project: Info Needed.
• werner added a project: Won't Fix.

2.1 will not anymore use a secring and thus this problem will soon vanish.
Fixing this may introduce other bugs, thus we better don't do anything here.

ralfbergs reopened this task as Open.Oct 23 2013, 1:17 PM

Does that mean there will only be a single keyring in the future? So that I can
not lock-away my secret key(s) while I don't need them?

• werner added a comment.Oct 24 2013, 11:58 PM

The secret keys are stored as separate files below ~/,gnupg/private-keys-v1.d/ -
gpgsm uses this method for more than a decade.

ralfbergs added a comment.Oct 25 2013, 8:17 AM

Sorry for being ignorant, but I don't even know what gpgsm is... ;-)

I'm just using the "classical" gpg since it came into life (being a PGP user for
more than 20 years now)...

But since gpgsm seems to use a separate directory for the private keys it's fine
for me as well -- I will then mount that directory as an encrypted one...

• werner closed this task as Resolved.Oct 25 2013, 11:47 AM

gpgsm is the S/MIME cousin of gpg.
No need for that. The files are of course encrypted.