From 78fe687a40613136c72bf3fcf16939d4415d4a1c Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Fri, 15 Aug 2008 16:51:35 -0400 Subject: fixing gen-subkey when no agent is present. --- website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'website') diff --git a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn b/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn index 51cf57e..e97b49c 100644 --- a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn +++ b/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn @@ -135,3 +135,10 @@ it. Alternately, we could use `--passwd-fd` and `ssh-agent`, along the lines i proposed [for handling passphrase-locked secret keys](/bugs/handle-passphrase-locked-secret-keys). + +--- + +[[bugs/done]] as of 2008-08-15 16:48:26-0400 (to be released in 0.8-1) + +I opted to go with the `ssh-askpass` route, and fall back to echoing +stuff to a fifo directly if `ssh-askpass` is not available. -- cgit v1.2.3 From c9acc1237d8e21d74fe7070af1b061c888664e8b Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Fri, 15 Aug 2008 17:19:58 -0400 Subject: noting that list-identity-certifiers should be running as a non-privileged user. --- website/bugs/list-id-certifiers-should-run-non-priv.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 website/bugs/list-id-certifiers-should-run-non-priv.mdwn (limited to 'website') diff --git a/website/bugs/list-id-certifiers-should-run-non-priv.mdwn b/website/bugs/list-id-certifiers-should-run-non-priv.mdwn new file mode 100644 index 0000000..3cbd1af --- /dev/null +++ b/website/bugs/list-id-certifiers-should-run-non-priv.mdwn @@ -0,0 +1,15 @@ +[[meta title="list-identity-certfiers should run as the non-privileged user"]] + +Right now, `monkeysphere-server list-identity-certifiers` runs as the +superuser, and just lists the keys in the host's keyring. This might +not be the actual list of valid id certifiers, for a number of reasons: + +* the keys themselves might have been revoked by the owner + +* the id-certifiers might have been added with a different trust + level, or a regexp/domain limitation. + +It would make more sense to derive the list of trusted certifiers +directly from the keyrings as seen by the non-privileged +`monkeysphere` user, since this user's keyrings are what are going to +judge the validity of various user IDs. -- cgit v1.2.3