summaryrefslogtreecommitdiff
path: root/website
diff options
context:
space:
mode:
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>2008-09-14 21:41:18 -0400
committerDaniel Kahn Gillmor <dkg@fifthhorseman.net>2008-09-14 21:41:18 -0400
commit86d072e02c75f1c0e84d4f5c51c2e034fa84de21 (patch)
tree46af0ceabe0a6fa3c84b0f46c638afcf9b35a17a /website
parente98366cd478343b9c39ced4984874cd611ccb4ad (diff)
documenting trouble with two keyring arrangement.
Diffstat (limited to 'website')
-rw-r--r--website/bugs/problems-with-root-owned-gpg-keyrings.mdwn24
1 files changed, 24 insertions, 0 deletions
diff --git a/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn b/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn
new file mode 100644
index 0000000..65268c5
--- /dev/null
+++ b/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn
@@ -0,0 +1,24 @@
+[[meta title="Problems with root-owned gpg keyrings"]]
+
+`/var/lib/monkeysphere/gnupg-host/` is root-owned, and the public
+keyring in that directory is controlled by the superuser.
+
+We currently expect the `monkeysphere` user to read from (but not
+write to) that keyring. But using a keyring in a directory that you
+don't control appears to trigger [a subtle bug in
+gpg](http://bugs.debian.org/361539) that has been unresolved for quite
+a long time.
+
+With some of the new error checking i'm doing in
+`monkeysphere-server`, typical operations that involve both keyrings
+as the non-privileged user can fail with an error message like:
+
+ gpg: failed to rebuild keyring cache: file open error
+
+Running the relevant operation a second time as the same user usually
+lets things go through without a failure, but this seems like it would
+be hiding a bug, rather than getting it fixed correctly.
+
+Are there other ways we can deal with this problem?
+
+--dkg