Home → Stable →

GPG Keychain Access deletes ~/.gnupg/pubring.gpg

• Edit

HJ

24 Oct, 2013 01:28 AM

GPG Keychain Access 1.1.2 (68f417b) (567n) <--- from the latest nightly, downloaded 2013-10-23
10.6.8

Please describe your problem. Add as much detail as possible.

Using GPG Keychain Access to edit the Ownertrust on a key in the public keyring causes the entire public keyring to be deleted(!).

Please describe what you did expect instead

I would expect the change in ownertrust to take place (probably by refreshing trustdb.gpg). I would NOT expect pubring.gpg to be deleted.

If you remember, please describe the steps leading up to the problem

1. Launch GPG Keychain Access.

2. Scroll down the list and select some random key. (I happened to pick one whose trust is undefined; I haven't checked if the following issue happens on all keys.)

3. Click on the Info button (top right) to show the Key Inspector.

4. Under the "Other:" block, change Ownertrust (using the pulldown menu) to something other than its current value.

5. Wait several seconds. A non-modal (I think that's what it's called) progress bar appears for a split-second, then disappears, upon which *** the entire list of public keys disappears ***.

6. Verify that ~/.gnupg/pubring.gpg is missing. Fortunately, I had a copy in pubring.gpg~, so a simple "cp pubring.gpg~ pubring.gpg" solved the problem. But that won't help anyone who doesn't have a backup copy of the keyring handy.

I cannot imagine that this bug is widespread, otherwise people would be screaming all over the place. So perhaps it is due to something odd in my setup. Please let me know what I can do to help debug this.

Thanks, H

p.s. The only vaguely similar ticket I found by searching the GPGTools discussions is http://support.gpgtools.org/discussions/everything/10400-upgrade-to-gpgmail-2-deleted-all-the-keys-from-gpg-keychain-access-and-wont-let-me-create-new-keys. But I do not have the same ownership problem (U:G = root:staff) on pubring.gpg which is described in that report (mine is U:G = (my_username):staff, as it should be). I also do not see any matching tickets on lighthouseapp.

1. Support Staff 1 Posted by Luke Le on 24 Oct, 2013 01:39 AM

   

   Hi HJ,

   we've honestly have never seen this before, and I couldn't think of any reason why this would be happening.
   GPG Keychain Access only runs commands through gpg to manipulate the key rings and never does so directly.

   Is there any chance, your .gnupg is located on an external usb drive or something similar?

   This sounds terrifying. So sorry, but happy you had a backup.

   • Edit

2. 2 Posted by M. C. H. on 24 Oct, 2013 07:48 AM

   

   Hi HJ,

   Are you able to you reproduce this issue?

   Be sure to backup the keyring before!

   If not, is the filesystem clean? Did you verify it with Disk Utility? What is the smart-status of the drive?

   c.

   • Edit

3. 3 Posted by HJ on 24 Oct, 2013 03:45 PM

   

   Hi Luke,

   On my laptop, ~/.gnupg/ is in my home directory. My gpg.conf used to have a line pointing to the path of a removable drive (when I used to keep my private keyring exclusively on a USB stick), but that line is commented out.

   As I said, I've got backups so I'm fine for now, but this is a potentially serious bug. On my machine it appears to be 100% consistently reproducible. Is there any way to grab debug output of what GKA commands is issuing?

   -H

   • Edit

4. Support Staff 4 Posted by Luke Le on 24 Oct, 2013 03:47 PM

   

   Reproducible, as frightening as it is, sounds better than not.
   If you run:

   defaults write org.gpgtools.common DebugLog 1

   you should see a lot of debug messages.

   • Edit

5. 5 Posted by HJ on 24 Oct, 2013 03:51 PM

   

   Got it -- thanks. Right now I'm Running Disk Utility and checking SMART status on the hard drive, as per M.C.H.'s suggestion, and will try to produce a debug log once that's done. Will post back once I have that.

   Thanks!

   -H

   • Edit

6. Support Staff 6 Posted by Luke Le on 24 Oct, 2013 03:55 PM

   

   One other thing - could you try to manually edit the owner trust from command line.
   If that works without deleting your pubring, we at least isolate one culprit.

   gpg2 --edit-key

   After that type "trust" and press enter and complete the menu.

   • Edit

7. 7 Posted by HJ on 24 Oct, 2013 04:32 PM

   

   Hi M. C. H.,

   Yes, at the moment this issue appears to be 100% reproducible on my laptop (MacBook pro).

   My keyrings (both pubring and secring) are already backed up, so I've managed to recover the former without problems.

   Running Disk Utility on the drive shows:
   -- S.M.A.R.T. Status: Verified
   -- Repair Permissions: flags a bunch of the usual things, but nothing obviously related to GPG as far as I can see (though I certainly might be overlooking something).

   FWIW, the repair doesn't actually seem to do anything, in that when I run it a second time, it flags the same things it claims to have fixed the first time. But I believe this is well documented in Apple's forums as a non-issue for the files in question. Is there some particular directory or file that Repair Permissions complains about that I should be looking for?

   Thanks,

   -H

   • Edit

8. 8 Posted by HJ on 24 Oct, 2013 06:44 PM

   

   1) I can manually edit the trust setting for the key in question from Terminal without any problems:
   : gpg2 --edit-key <...>
   : [change trust from one setting to another]
   : quit
   : gpg2 --edit-key <...> (again, verifying that my edit was executed correctly)
   : quit

   and I can verify that ~/.gnupg/pubring.gpg remains in place with no changes.

   2) After running "defaults write org.gpgtools.common DebugLog 1", I see the following in the Console logs:

   [DATABASE SEARCHES > Console Messages]:
   : 10/24/13 9:54:49 AM GPG Keychain Access[2296] *** __NSAutoreleaseNoPool(): Object 0x1002162a0 of class NSPathStore2 autoreleased with no pool in place - just leaking
   : 10/24/13 9:54:49 AM GPG Keychain Access[2296] *** __NSAutoreleaseNoPool(): Object 0x10021a0b0 of class NSPathStore2 autoreleased with no pool in place - just leaking
   : 10/24/13 9:54:49 AM GPG Keychain Access[2296] *** __NSAutoreleaseNoPool(): Object 0x10021a2b0 of class NSCFString autoreleased with no pool in place - just leaking
   : 10/24/13 9:54:49 AM GPG Keychain Access[2296] *** __NSAutoreleaseNoPool(): Object 0x1002158d0 of class NSURL autoreleased with no pool in place - just leaking
   : 10/24/13 9:54:50 AM GPG Keychain Access[2296] GPG Keychain Access version: 567n

   ... and matching entries in [FILES > system.log].

   [FILES > gpg-home-fixer.log]:
   : 2013-10-23 18:01:57: Overwrite UID: heywood
   : 2013-10-23 18:01:57: Overwrite GNUPGHOME: /Users/heywood/.gnupg
   : 2013-10-23 18:01:57: [fixGpgHome] Fixing '/Users/heywood/.gnupg'...
   : gpg: WARNING: unsafe ownership on configuration file `/Users/heywood/.gnupg/gpg.conf'
   : 2013-10-23 18:01:57: [fixGpgHome] Fixing '/Users/heywood/.gnupg/gpg-agent.conf'...
   : 2013-10-23 18:01:57: [fixGpgHome] Start gpg-agent.
   : GPG_AGENT_INFO=/Users/heywood/.gnupg/S.gpg-agent:9981:1; export GPG_AGENT_INFO;
   : 2013-10-24 07:07:58: [fixGpgHome] Fixing '/Users/heywood/.gnupg'...
   : 2013-10-24 07:08:12: [fixGpgHome] Fixing '/Users/heywood/.gnupg/gpg-agent.conf'...
   : 2013-10-24 07:08:23: [fixGpgHome] Start gpg-agent.
   : GPG_AGENT_INFO=/Users/heywood/.gnupg/S.gpg-agent:787:1; export GPG_AGENT_INFO;

   Not sure if any of the above is significant. Did I look in the right place for the DebugLog?

   I'm now running DTRACE to see exactly what happens. Since the output is lengthy, I'll post those findings separately.

   -H

   • Edit

9. 9 Posted by HJ on 24 Oct, 2013 08:26 PM

   

   After some further experimenting, I'm seeing two similar (but not identical) behaviors: either ~/.gnupg/pubring.gpg gets zapped to zero length, or it disappears altogether. (I'm starting to suspect that the relative timestamps of pubring.gpg, pubring.gpg~, and trustdb.gpg may have something to do with this, but that is just a guess.)

   Iin any case, attached below are the results of several runs of sudo dtruss -d -f "/Applications/GPG\ Keychain\ Access.app/Contents/MacOS/GPG\ Keychain\ Access" 2>&1 | grep -i pubring > 20131024_GKA_debug_[...], where the end of each filename describes what I did immediately prior to generating it. The contents of these files differ slightly, so I'm hoping that at least one of them captures what's really going on.

   For the two "aligned" files, I ran touch trustdb.gpg pubring.gpg~ pubring.gpg before launching GPA. After restoring pubring.gpg from backup, I generated the three "not-aligned" files using the same command, only without refreshing the timestamps with touch.

   • 20131024_GKA_debug_timestamps-aligned-with-touch1.txt 7.76 KB
   • Edit

10. 10 Posted by HJ on 24 Oct, 2013 08:27 PM

    

    "Aligned" file #2...

    • 20131024_GKA_debug_timestamps-aligned-with-touch2.txt 12.1 KB
    • Edit

11. 11 Posted by HJ on 24 Oct, 2013 08:28 PM

    

    "Not-aligned" file #1. In this case pubring.gpg~ and trustdb.gpg are one minute older than pubring.gpg.

    • 20131024_GKA_debug_timestamps-not-aligned1.txt 4.68 KB
    • Edit

12. 12 Posted by HJ on 24 Oct, 2013 08:29 PM

    

    "Not-aligned" file #2...

    • 20131024_GKA_debug_timestamps-not-aligned2.txt 5.85 KB
    • Edit

13. 13 Posted by HJ on 24 Oct, 2013 08:30 PM

    

    "Not-aligned" file #3. Sorry for the comment spam, but I couldn't figure out how to attach all five files to a single post.

    • 20131024_GKA_debug_timestamps-not-aligned3.txt 4.56 KB
    • Edit

14. Support Staff 14 Posted by Luke Le on 31 Oct, 2013 04:23 PM

    

    Hi HJ,

    we think this might be related to different threads or processes accessing the key rings in parallel.
    I've also found a message on a debian user list which seems to run into a similar issue:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725138

    Just to make sure, could you please check if you have the "lock-never" or any similar option in your gpg.conf, or best, post your gpg.conf and gpg-agent.conf?

    Thanks.

    • Edit

15. Support Staff 15 Posted by Steve on 12 Nov, 2013 11:32 AM

    

    No further user feedback. Closing.

    Should your problem persist, feel free to re-open this discussion any time.

    All the best, steve

    • Edit

16. Steve closed this discussion on 12 Nov, 2013 11:32 AM.

17. HJ re-opened this discussion on 17 Jan, 2014 06:30 AM

18. 16 Posted by HJ on 17 Jan, 2014 06:30 AM

    

    Hi all,

    (Re-opening the discussion as I'm still seeing the original issue. Sorry for the long delay -- I was in the process of moving and basically stopped doing anything other than email for a long while.)

    Responding, finally, to Luke's question of 31 Oct 2013:

    1) The non-commented lines in my gpg.conf are:
    

    default-key <hex fingerprint of my key ID>
    no-escape-from-lines
    charset utf8
    lock-never
    keyserver hkp://keys.gnupg.net
    keyserver-options no-include-revoked
    secret-keyring /Users/heywood/.gnupg/secring.gpg
    keyring /Users/heywood/.gnupg/pubring.gpg
    comment GPGTools - http://gpgtools.org
    utf8-strings
    personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160
    cert-digest-algo SHA256
    default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
    

    2) My gpg-agent.conf is as follows:
    

    pinentry-program /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac
    default-cache-ttl 600
    max-cache-ttl 7200
    

    Taking the suggestion implied by Luke's question, I commented out lock-never and noted that the issue goes away: I can edit ownertrust using Keychain Access and it doesn't delete the keyring. But I vaguely recall that I uncommented that line for a specific reason some time ago; this wasn't arbitrary. In any case, I don't think a misconfiguration in gpg.conf should cause the entire keyring to be deleted!

    Please let me know what else I can do to assist in debugging from this end.

    Regards,

    -H

    • Edit

19. Support Staff 17 Posted by Luke Le on 17 Jan, 2014 09:32 AM

    

    Hi HJ,

    the lock-never option is only to be used in cases where it's guaranteed that only one thread (or one process) accesses the keyrings at a time.
    When you're using GPG Keychain Access, this requirement is no longer met and so it's very well possible that the keyring is destroyed.
    The lock-never is an expert option and should only be used if the file system where the keyrings are located is not capable of locking. For example an NFS or AFP share.
    This is a really annoying limitation, but unfortunately rewriting the locking mechanism is out of scope of this project at the moment.
    It would be best if you bring this issue up with the gnupg developers at bugs.gnupg.org

    • Edit

20. 18 Posted by HJ on 17 Jan, 2014 05:39 PM

    

    --------------------------------------------
    Hi Luke,

    Now that you mention it, I recall exactly when and why I uncommented that option.

    For a while I was keeping my entire keyring on a removable USB stick -- my thinking was that if my laptop ever got stolen, my keyring would be more secure by not being on the machine at all, rather than having its individual keys protected by a passphrase.

    I've long since moved my keyring back to the laptop (having to mount the stick to sign emails had become too much of a chore), so there's no longer any reason to have lock-never uncommented.

    Thanks for the clarification. I will file a report with the gnupg devs as you suggest.

    Cheers,

    HJ

    • Edit

21. Mento closed this discussion on 23 Jan, 2014 03:32 PM.