Merge commit 'jrollins/master'

14 files changed, 317 insertions, 9 deletions

diff --git a/website/bugs/add-man-pages-to-website.mdwn b/website/bugs/add-man-pages-to-website.mdwn
new file mode 100644
index 0000000..4a8d2e2
--- /dev/null
+++ b/website/bugs/add-man-pages-to-website.mdwn
@@ -0,0 +1,12 @@
+[[meta title="Add man pages to web site"]]
+
+We should publish the various monkeysphere man pages in browsable form
+somewhere under http://monkeysphere.info/.  Ideally, this would be
+updated automatically from the sources for the official man pages
+themselves.
+
+This strikes me as an ikiwiki subproject (implementing a man2html wiki
+compilation language perhaps?).
+
+Interestingly, [ikiwiki's own man page](http://ikiwiki.info/usage/)
+appears to be written in markdown and then converted to nroff.
diff --git a/website/bugs/handle-passphrase-locked-secret-keys.mdwn b/website/bugs/handle-passphrase-locked-secret-keys.mdwn
index b66e4c7..ae5bf72 100644
--- a/website/bugs/handle-passphrase-locked-secret-keys.mdwn
+++ b/website/bugs/handle-passphrase-locked-secret-keys.mdwn
@@ -36,8 +36,10 @@ work for reasonable values of `$KEYID`:
 	mkfifo "$TMPDIR/passphrase"
 	kname="MonkeySphere Key $KEYID"
 	mkfifo "$TMPDIR/$kname"
-	ssh-agent "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" &
-	gpg  --passphrase-fd 3 3<"$TMPDIR/passphrase" --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes --export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname"
+	ssh-askpass "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" &
+	gpg  --passphrase-fd 3 3<"$TMPDIR/passphrase" \
+	  --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes \
+	  --export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname" &
 	(cd "$TMPDIR" && ssh-add -c "$kname")
 	rm -rf "$TMPDIR"	
 
diff --git a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
index 5b19b13..0163727 100644
--- a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
+++ b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
@@ -25,3 +25,19 @@ part about verifying you to a server. Then it could say: if you're really
 interested, you can run this hacky script but we make no guarantees.
 
 -- Sir Jam Jam
+
+---
+
+I just realized that i think i can test for the presence of [GNU-dummy
+support in
+GnuTLS](http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html),
+which means that we can cleanly test whether the proposed [handling of
+passphrase-locked secret
+keys](bugs/handle-passphrase-locked-secret-keys/) is functional.  With
+that in mind, I'd like to propose that we could resolve this bug
+simply by adding a new subcommand: `monkeysphere authkey-to-agent`,
+which would fail in the absence of a functionally-patched GnuTLS.
+
+Would this proposal be sufficient to resolve this bug?
+
+--dkg
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..2a3d533
--- /dev/null
+++ b/website/bugs/list-id-certifiers-should-run-non-priv.mdwn
@@ -0,0 +1,19 @@
+[[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.
+
+---
+
+[[bugs/done]] 2008-08-16 in a29b35e69d0fab5f2de42ed5edd9512a6552e75a
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.
diff --git a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn b/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn
index 3fbf19f..85f79f1 100644
--- a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn
+++ b/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn
@@ -16,3 +16,7 @@ following order instead:
  * default value of subkeys.pgp.net
 
 -- Sir Jam Jam
+
+---
+
+[[bugs/done]] 2008-08-15 in ab5cfab5be64cfb5e01c2b660587da43b3097cad
diff --git a/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn b/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn
index 965f198..028c8f9 100644
--- a/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn
+++ b/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn
@@ -20,3 +20,15 @@ at least, would be for silent output to be the default and have a -v/--verbose
 option to get the output. Or - maybe these should be environmental variables?
 In any event - someway to suppress informational output would be a useful
 improvement.
+
+------
+
+I'd be fine with silent mode as a default, with a more verbose mode
+accessible to the user who desires it.
+
+I'd prefer an environment variable (e.g. `MONKEYSPHERE_VERBOSE` or
+`MONKEYSPHERE_DEBUG`) over a command-line (e.g. `--verbose`) option,
+personally.  It's more in keeping with the model we've used in general
+so far.
+
+--dkg
diff --git a/website/bugs/multiple-hostnames.mdwn b/website/bugs/multiple-hostnames.mdwn
index 7597af5..f4920fd 100644
--- a/website/bugs/multiple-hostnames.mdwn
+++ b/website/bugs/multiple-hostnames.mdwn
@@ -35,3 +35,5 @@ probably prompt the administrator to re-publish the host key as well,
 to ensure that the new User IDs are published.
 
   --dkg
+
+[[bugs/done]] on 2008-08-15 15:00:02-0400 in 84b775ff0b36ec4b86e6708844ad2d678eced403
diff --git a/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn b/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn
new file mode 100644
index 0000000..f785a9d
--- /dev/null
+++ b/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn
@@ -0,0 +1,94 @@
+[[meta title="revoke-hostname function revokes wrong hostname user ID"]]
+
+It appears that the monkeysphere-server revoke-hostname function will
+occasionaly revoke the wrong hostname.  I say occasionally, but it
+seems to be doing it pretty consistently for me at the moment:
+        
+	servo:~ 0$ sudo monkeysphere-server n- servo.finestructure.net
+	The following host key user ID will be revoked:
+	  ssh://servo.finestructure.net
+	Are you sure you would like to revoke this user ID? (y/N) y
+	gpg (GnuPG) 1.4.9; Copyright (C) 2008 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.
+	
+	Secret key is available.
+	
+	pub  1024R/9EEAC276  created: 2008-07-10  expires: never       usage: CA  
+	                     trust: ultimate      validity: ultimate
+	[ultimate] (1)  ssh://localhost.localdomain
+	[ultimate] (2). ssh://servo.finestructure.net
+	[ revoked] (3)  ssh://jamie.rollins
+	[ revoked] (4)  asdfsdflkjsdf
+	[ revoked] (5)  ssh://asdfsdlf.safsdf
+	[ revoked] (6)  ssh://bar.baz
+	[ revoked] (7)  ssh://foo.bar
+	[ revoked] (8)  ssh://
+	
+	
+	pub  1024R/9EEAC276  created: 2008-07-10  expires: never       usage: CA  
+	                     trust: ultimate      validity: ultimate
+	[ultimate] (1)* ssh://localhost.localdomain
+	[ultimate] (2). ssh://servo.finestructure.net
+	[ revoked] (3)  ssh://jamie.rollins
+	[ revoked] (4)  asdfsdflkjsdf
+	[ revoked] (5)  ssh://asdfsdlf.safsdf
+	[ revoked] (6)  ssh://bar.baz
+	[ revoked] (7)  ssh://foo.bar
+	[ revoked] (8)  ssh://
+	
+	Please select the reason for the revocation:
+	  0 = No reason specified
+	  4 = User ID is no longer valid
+	  Q = Cancel
+	(Probably you want to select 4 here)
+	Enter an optional description; end it with an empty line:
+	Reason for revocation: User ID is no longer valid
+	Hostname removed by monkeysphere-server 2008-08-16T17:34:02
+	
+	pub  1024R/9EEAC276  created: 2008-07-10  expires: never       usage: CA  
+	                     trust: ultimate      validity: ultimate
+	[ revoked] (1)  ssh://localhost.localdomain
+	[ultimate] (2). ssh://servo.finestructure.net
+	[ revoked] (3)  ssh://jamie.rollins
+	[ revoked] (4)  asdfsdflkjsdf
+	[ revoked] (5)  ssh://asdfsdlf.safsdf
+	[ revoked] (6)  ssh://bar.baz
+	[ revoked] (7)  ssh://foo.bar
+	[ revoked] (8)  ssh://
+	
+	gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
+	gpg: depth: 0  valid:   1  signed:   2  trust: 0-, 0q, 0n, 0m, 0f, 1u
+	gpg: depth: 1  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 2f, 0u
+	gpg: next trustdb check due at 2012-01-07
+	sec   1024R/9EEAC276 2008-07-10
+	      Key fingerprint = C094 43E0 6882 8BE2 E9AD  516C 45CF 974D 9EEA C276
+	uid                  ssh://servo.finestructure.net
+	uid       [ revoked] ssh://localhost.localdomain
+	uid       [ revoked] ssh://jamie.rollins
+	uid       [ revoked] asdfsdflkjsdf
+	uid       [ revoked] ssh://asdfsdlf.safsdf
+	uid       [ revoked] ssh://bar.baz
+	uid       [ revoked] ssh://foo.bar
+	uid       [ revoked] ssh://
+	
+	NOTE: User ID revoked, but revokation not published.
+	Run 'monkeysphere-server publish-key' to publish the revocation.
+	servo:~ 0$ 
+	
+Clearly this is unacceptable.  gpg does not let you can't specify a
+uid to revoke from the command line.  The uid revokation can only be
+done through edit-key.  We do edit-key scripting in other contexts,
+but to revoke a user id you have to specify the uid by "number".  We
+currently try to guess the number from the ordering of the output of
+list-key.  However, this output does not appear to coincide with the
+ordering in edit-key.  I don't have a good solution or fix at the
+moment.  Suggestions are most welcome.  It may just require some trial
+and error with edit-key to come up with something workable.
+
+This underlines the problem that gpg is currently not very well suited
+for manipulating gpg keyrings non-interactively.  It's possible that I
+just haven't figured out how to do it yet, but it's not very clear if
+it is possible.  It would be nice to have some alternate tools to use.
+
+-- Big Jimmy.
diff --git a/website/download.mdwn b/website/download.mdwn
index 5bd2f2a..dbae309 100644
--- a/website/download.mdwn
+++ b/website/download.mdwn
@@ -28,7 +28,7 @@ The git repo from this web site:
 
 [Jameson Graef Rollins](http://cmrg.fifthhorseman.net/wiki/jrollins):
 
-	git clone http://lair.fifthhorseman.net/~jrollins/git/monkeysphere.git monkeysphere
+	git clone git://lair.fifthhorseman.net/~jrollins/monkeysphere monkeysphere
 
 [Daniel Kahn Gillmor](http://cmrg.fifthhorseman.net/wiki/dkg):
 
diff --git a/website/index.mdwn b/website/index.mdwn
index 853c75b..6583e18 100644
--- a/website/index.mdwn
+++ b/website/index.mdwn
@@ -9,7 +9,7 @@ yourself and the servers you administer or connect to.  OpenPGP keys
 are tracked via GnuPG, and managed in the `known_hosts` and
 `authorized_keys` files used by OpenSSH for connection authentication.
 
-[[bugs]] | [[download]] | [[news]] | [[documentation|doc]]
+[why?](/why) | [[bugs]] | [[download]] | [[news]] | [[documentation|doc]]
 
 ## Conceptual overview ##
 
@@ -26,13 +26,14 @@ keys for authenticating to a server (known as
 "`PubkeyAuthentication`"), rather than relying on a password exchange.
 But again, the public part of the key needs to be transmitted to the
 server through a secure out-of-band channel (usually via a separate
-password-based SSH connection) in order for this type of
-authentication to work
+password-based SSH connection or a (hopefully signed) e-mail to the
+system administrator) in order for this type of authentication to
+work.
 
 [OpenSSH](http://openssh.com/) currently provides a functional way to
-managing the RSA and DSA keys required for these interactions through
-the `known_hosts` and `authorized_keys` files.  However, it lacks
-any type of [Public Key Infrastructure
+manage the RSA and DSA keys required for these interactions through
+the `known_hosts` and `authorized_keys` files.  However, it lacks any
+type of [Public Key Infrastructure
 (PKI)](http://en.wikipedia.org/wiki/Public_Key_Infrastructure) that
 can verify that the keys being used really are the one required or
 expected.
diff --git a/website/news/release-0.8-1.mdwn b/website/news/release-0.8-1.mdwn
new file mode 100644
index 0000000..ed4ed7d
--- /dev/null
+++ b/website/news/release-0.8-1.mdwn
@@ -0,0 +1,5 @@
+[[meta title="MonkeySphere 0.8-1 released!"]]
+
+MonkeySphere 0.8-1 has been released.  This release contains bugfixes,
+some UI re-arrangement, and new features for `monkeysphere-server`,
+among other things.  [[download]] it now!
diff --git a/website/news/release-0.9-1.mdwn b/website/news/release-0.9-1.mdwn
new file mode 100644
index 0000000..8a51f42
--- /dev/null
+++ b/website/news/release-0.9-1.mdwn
@@ -0,0 +1,8 @@
+[[meta title="MonkeySphere 0.9-1 released!"]]
+
+# MonkeySphere 0.9-1 released! #
+
+MonkeySphere 0.9-1 has been released.  This release contains a serious
+bugfix related to host key expiration, and provides the ability for
+server administrators to extend the lifetime of their keys.
+[[download]] it now!
diff --git a/website/why.mdwn b/website/why.mdwn
new file mode 100644
index 0000000..3f6aa7c
--- /dev/null
+++ b/website/why.mdwn
@@ -0,0 +1,126 @@
+[[meta title="Why should you be interested in the MonkeySphere?"]]
+
+# Why should you be interested in the MonkeySphere? #
+
+## As an `ssh` user ##
+
+Do you use `ssh` to connect to remote machines?  Are you tired of
+seeing messages like this?
+
+	The authenticity of host 'foo.example.org (192.0.2.3)' can't be established.
+	RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90.
+	Are you sure you want to continue connecting (yes/no)?
+
+Do you actually tediously check the fingerprint against a
+cryptographically-signed message from the admin, or do you just cross
+your fingers and type "yes"?  Do you wish there was a better way to do
+it?  Shouldn't our tools be able to figure this out automatically?
+
+Do you use `ssh`'s public key authentication for convenience and/or
+added security?  Have you ever worried about what might happen if you
+lose control of your key?  (Or did you have a key that was compromised
+by [the OpenSSL debacle](http://bugs.debian.org/363516)?)  How many
+accounts/machines would you need to clean up to ensure that your old,
+bad key is no longer in use?  
+
+Have you ever wished you could phase out an old key and start using a
+new one without having to comb through every single account you have
+ever connected to?
+
+## As an `sshd` administrator ##
+
+If you are a system administrator, have you ever tried to re-key an
+SSH server?  How did you ease the change along to your users?  How did
+you keep them from getting the big scary warning messages?  
+
+Have you ever wanted to allow a colleague key-based access to a
+machine, *without* needing to have a copy of their public key on hand?
+
+Have you ever wanted to be able to revoke the ability of a user's key
+to authenticate across the entire infrastructure you manage, without
+touching each host by hand?
+
+## What's the connection? ##
+
+These questions all stem from rough edges we run up against in regular
+use of SSH that could be improved by a decent [Public Key
+Infrastructure (or
+PKI)](http://dictionary.die.net/public%20key%20infrastructure).  A PKI
+at its core is a mechanism to provide answers to a few basic
+questions:
+
+* Do we know who a key actually belongs to?  How do we know?
+* Is the key still valid for use?
+
+Given a clearly stated set of initial assumptions, functional
+cryptographic tools, and a PKI, these questions can be clearly
+answered in an automated fashion.  We should not need to ask humans to
+do complicated, error-prone things (e.g. checking host key
+fingerprints) except in relatively rare situations (e.g. when two
+people meet in person for the first time).
+
+The good news is that this is all possible, and available with free
+tools!
+
+## Examples ##
+
+Bob is an `ssh` user, and has just been given an account on
+`foo.example.org` by Alice, the `example.org` system administrator,
+who he knows.
+
+Bob already trusts Alice to properly identify all `example.org`
+servers.  Alice already knows who Bob is, and the new machine `foo`
+knows that it can rely on Alice's certifications because Alice is its
+administrator.
+
+Alice can set up the new `bob` account on `foo.example.org` without
+needing to give Bob a new passphrase to remember, and without needing
+to even know Bob's current SSH key.  She simply tells `foo` that `Bob
+<bob@example.net>` should have access to the `bob` account.
+
+Bob's first connection to his new `bob` account on `foo.example.org`
+is seamless, because all the steps are already in place!  Using the
+MonkeySphere, Bob never has to "accept" an unintelligible host key or
+type a password.
+
+When Bob decides to change the key he uses for SSH authentication, he
+can do so at once: he generates a new key, revokes his old key, and
+publishes these changes to the public keyservers.  The next time he's
+ready to log into `foo.example.org`, it accepts his new key -- and it
+*won't* accept his old key any longer.
+
+The same thing works for Alice when she decides to re-key
+`foo.example.org` (let's say Alice learned that Eve has compromised
+the old key).  Alice generates a new key, revokes the old one,
+publishes the changes, and the next time Bob connects, he connects as
+smoothly as ever.  And if Eve tries to use the old host key to
+masquerade as `foo`, Bob's SSH client will refuse to let him connect!
+
+Alice can even quit as `example.org` system administrator, and revoke
+her certifications of all `example.org` hosts.  As long as Bob knows
+and trusts the new `example.org` system administrator to identify
+hosts in that domain, there's no problem.
+
+## Why OpenPGP? ##
+
+We believe that OpenPGP is the right PKI to use for this project.  It
+allows a very flexible trust model, ranging all over the map, at the
+choice of the user:
+
+* individual per-host certifications by each client (much like the
+  stock OpenSSH behavior),
+
+* strict centralized Certificate Authorities (much like proposed X.509
+  models), and
+
+* a more human-centric model that recognizes individual differences in
+  ranges of trust and acceptance.
+
+Even if Bob *doesn't* trust Alice to identify *all* `example.org`
+hosts, his first connection to `foo.example.org` should give him more
+than an unintelligible string to accept or reject.  It should also
+give him the information that Alice (and perhaps her colleague
+Charles) have certified the key.  This is far more useful information
+than the current infrastructure allows, and is more meaningful to
+actual humans using these tools than some message like "Certified by
+GloboTrust".