summaryrefslogtreecommitdiff
path: root/website
diff options
context:
space:
mode:
authorMatthew James Goins <mjgoins@openflows.com>2010-03-20 15:07:30 -0400
committerMatthew James Goins <mjgoins@openflows.com>2010-03-20 15:07:30 -0400
commit2f9fe93b98ed32b662212899db6ba2174c1138d3 (patch)
tree099a0b3224b666bfc1289462f1a6d01a24763102 /website
parent072e05ac7a9872edc3a3e18e103bbba2706254bf (diff)
Removed docs and website. They will now reside (for my repo) at git://lair.fifthhorseman.net/~mjgoins/monkeysphere.info/
Diffstat (limited to 'website')
-rw-r--r--website/advanced-user.mdwn137
-rw-r--r--website/archive-key.mdwn139
-rw-r--r--website/bugs.mdwn19
-rw-r--r--website/bugs/add-identity-certifier-behaves-oddly-without-pty.mdwn15
-rw-r--r--website/bugs/add-man-pages-to-website.mdwn12
-rw-r--r--website/bugs/allow-publishing-to-public-keyservers.mdwn20
-rw-r--r--website/bugs/authorized_keys-options.mdwn16
-rw-r--r--website/bugs/authorized_keys_not_cleared.mdwn24
-rw-r--r--website/bugs/cssh-connection-timeout.mdwn93
-rw-r--r--website/bugs/done.mdwn5
-rw-r--r--website/bugs/genericize-filesystem-locations-for-testsuite.mdwn32
-rw-r--r--website/bugs/gpg-authentication-cmd_requires_single_input.mdwn15
-rw-r--r--website/bugs/handle-passphrase-locked-secret-keys.mdwn117
-rw-r--r--website/bugs/headless-servers-take-too-long-to-generate-host-key.mdwn31
-rw-r--r--website/bugs/hostkeyalias-confuses-monkeysphere.mdwn28
-rw-r--r--website/bugs/install-seckey2sshagent-in-usr-bin.mdwn59
-rw-r--r--website/bugs/list-id-certifiers-should-run-non-priv.mdwn19
-rw-r--r--website/bugs/make-tarball-is-not-idempotent.mdwn12
-rw-r--r--website/bugs/missing-known_hosts-causes-error.mdwn14
-rw-r--r--website/bugs/monkeysphere-gen-key-should-guess-KeyID.mdwn25
-rw-r--r--website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn144
-rw-r--r--website/bugs/monkeysphere-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn37
-rw-r--r--website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn22
-rw-r--r--website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn251
-rw-r--r--website/bugs/multiple-hostnames.mdwn39
-rw-r--r--website/bugs/posix_compliance.mdwn12
-rw-r--r--website/bugs/postinst-clobbers-gpg.conf-settings.mdwn35
-rw-r--r--website/bugs/problems-with-root-owned-gpg-keyrings.mdwn121
-rw-r--r--website/bugs/reorganize-monkeysphere-server-shortcuts.mdwn22
-rw-r--r--website/bugs/revoke-hostname-revoking-wrong-userid.mdwn94
-rw-r--r--website/bugs/setup-subcommand-for-monkeysphere-server.mdwn56
-rw-r--r--website/bugs/setup-test-server-for-public.mdwn84
-rw-r--r--website/bugs/ssh-connection-refused-with-proxycommand.mdwn23
-rw-r--r--website/bugs/ssh_config_files_not_parsed.mdwn47
-rw-r--r--website/bugs/use_getopts_instead_of_getopt.mdwn19
-rw-r--r--website/bugs/useful_information.mdwn50
-rw-r--r--website/community.mdwn69
-rw-r--r--website/doc.mdwn34
-rw-r--r--website/download.mdwn145
-rw-r--r--website/expansion.mdwn49
-rw-r--r--website/favicon.icobin937 -> 0 bytes
-rw-r--r--website/features.mdwn4
-rw-r--r--website/getting-started-admin.mdwn182
-rw-r--r--website/getting-started-user.mdwn181
-rw-r--r--website/index.mdwn82
-rw-r--r--website/local.css134
-rw-r--r--website/logo.pngbin11425 -> 0 bytes
-rw-r--r--website/logo.simple.pngbin5536 -> 0 bytes
-rw-r--r--website/logo.title.pngbin4123 -> 0 bytes
-rw-r--r--website/mirrors.mdwn47
-rw-r--r--website/news.mdwn7
-rw-r--r--website/news/0.24-accepted-in-Debian-testing.mdwn10
-rw-r--r--website/news/0.24-available-in-Backports-org.mdwn8
-rw-r--r--website/news/FreeBSD-0.24-port-accepted.mdwn11
-rw-r--r--website/news/FreeBSD-port-available.mdwn34
-rw-r--r--website/news/Monkeysphere-in-Debian.mdwn15
-rw-r--r--website/news/apt-repo-moved.mdwn15
-rw-r--r--website/news/git-repo-moved.mdwn9
-rw-r--r--website/news/gnutls-2.6-enables-monkeysphere.mdwn30
-rw-r--r--website/news/mailing-list.mdwn22
-rw-r--r--website/news/modified-gnutls-2.4.x-available.mdwn66
-rw-r--r--website/news/msva-perl-0.2.mdwn20
-rw-r--r--website/news/plans-for-the-bezoar.mdwn45
-rw-r--r--website/news/release-0.10-1.mdwn6
-rw-r--r--website/news/release-0.11-1.mdwn13
-rw-r--r--website/news/release-0.12-1.mdwn9
-rw-r--r--website/news/release-0.13-1.mdwn9
-rw-r--r--website/news/release-0.14-1.mdwn11
-rw-r--r--website/news/release-0.15-1.mdwn17
-rw-r--r--website/news/release-0.16-1.mdwn31
-rw-r--r--website/news/release-0.17-1.mdwn17
-rw-r--r--website/news/release-0.18-1.mdwn25
-rw-r--r--website/news/release-0.19-1.mdwn15
-rw-r--r--website/news/release-0.20-1.mdwn18
-rw-r--r--website/news/release-0.21-1.mdwn10
-rw-r--r--website/news/release-0.22-1.mdwn25
-rw-r--r--website/news/release-0.23-1.mdwn31
-rw-r--r--website/news/release-0.23.1-1.mdwn12
-rw-r--r--website/news/release-0.24-1.mdwn26
-rw-r--r--website/news/release-0.25-1.mdwn30
-rw-r--r--website/news/release-0.26-1.mdwn21
-rw-r--r--website/news/release-0.27-1.mdwn19
-rw-r--r--website/news/release-0.28.mdwn15
-rw-r--r--website/news/release-0.29.mdwn25
-rw-r--r--website/news/release-0.5-1.mdwn6
-rw-r--r--website/news/release-0.7-1.mdwn6
-rw-r--r--website/news/release-0.8-1.mdwn5
-rw-r--r--website/news/release-0.9-1.mdwn8
-rw-r--r--website/news/website-launched.mdwn57
-rw-r--r--website/screenshots.mdwn18
-rw-r--r--website/screenshots/blanco.pngbin83071 -> 0 bytes
-rw-r--r--website/screenshots/zimmerman.pngbin9150 -> 0 bytes
-rw-r--r--website/sidebar.mdwn20
-rw-r--r--website/signing-host-keys.mdwn127
-rw-r--r--website/similar.mdwn135
-rw-r--r--website/technical-details.mdwn28
-rw-r--r--website/trust-models.mdwn203
-rw-r--r--website/validation-agent.mdwn32
-rw-r--r--website/validation-agent/protocol.mdwn24
-rw-r--r--website/vision.mdwn33
-rw-r--r--website/why.mdwn182
101 files changed, 0 insertions, 4376 deletions
diff --git a/website/advanced-user.mdwn b/website/advanced-user.mdwn
deleted file mode 100644
index 723b161..0000000
--- a/website/advanced-user.mdwn
+++ /dev/null
@@ -1,137 +0,0 @@
-[[!meta title="Advanced usage of the Monkeysphere"]]
-
-Advanced usage of the monkeysphere
-==================================
-
-
-Keeping your `known_hosts` file in sync with your keyring
----------------------------------------------------------
-
-If you want to keep your keyring updated without attempting
-connections to a remote host, you want to make sure that OpenSSH can
-still see the most recent trusted information about who the various
-hosts are. You might also want to check on hosts that were not
-originally in the Monkeysphere, to see if their host key is now
-published.
-
-You can do this kind of independent update with the
-`update-known_hosts` command:
-
- $ monkeysphere update-known_hosts
-
-This command will check to see if there is an OpenPGP key for each
-(non-hashed) host listed in the `known_hosts` file, and then add the
-key for that host to the `known_hosts` file if one is found. This
-command could be added to a crontab, if desired.
-
-
-
-Establishing trust
-------------------
-
-The Monkeysphere is predicated on the idea that users and
-administrators know each other (or know people who know each other,
-etc). It uses the Web of Trust to explicitly represent those links.
-If you haven't used the Web of Trust explicitly, you will need to
-establish an acceptable trust path to the admin(s) of the
-monkeysphere-enabled servers that you will be connecting to. You need
-to do this because the admin is certifying the host, and you need a
-mechanism to validate that certification. The only way to do that is
-by indicating who you trust to certify hosts. This is a two step
-process: first you must sign the key, and then you have to indicate a
-trust level. If you do not indicate that you trust the administrator
-to certify host keys, then the monkeysphere will show you her
-certification on every connection, but will not treat it as an
-automatic verification.
-
-The process of signing another key is outside the scope of this
-document, however the [gnupg
-README](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/README?root=GnuPG&view=markup)
-details the signing process and you can find good [documentation
-](http://www.debian.org/events/keysigning) online detailing this
-process.
-
-If you have signed your admins' key, you need to denote some kind of
-trust to that key. To do this you should edit the key and use the
-'trust' command. For the Monkeysphere to trust the assertions that are
-made about a host, you need full calculated validity to the host
-certifiers. This can be done either by giving full trust to one
-host-certifying key, or by giving marginal trust to three different
-host-certifiers. In the following we demonstrate how to add full trust
-validity to a host-certifying key:
-
-
- $ gpg --edit-key 'Jane Admin'
- 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.
-
-
- pub 4096R/ABCD123A created: 2007-06-02 expires: 2012-05-31 usage: SC
- trust: unknown validity: full
- sub 2048R/01DECAF7 created: 2007-06-02 expires: 2012-05-31 usage: E
- [ full ] (1). Jane Admin <jane_admin@example.net>
-
- Command> trust
- pub 4096R/ABCD123A created: 2007-06-02 expires: 2012-05-31 usage: SC
- trust: unknown validity: full
- sub 2048R/01DECAF7 created: 2007-06-02 expires: 2012-05-31 usage: E
- [ full ] (1). Jane Admin <jane_admin@example.net>
-
- Please decide how far you trust this user to correctly verify other users' keys
- (by looking at passports, checking fingerprints from different sources, etc.)
-
- 1 = I don't know or won't say
- 2 = I do NOT trust
- 3 = I trust marginally
- 4 = I trust fully
- 5 = I trust ultimately
- m = back to the main menu
-
- Your decision? 4
-
- pub 4096R/ABCD123A created: 2007-06-02 expires: 2012-05-31 usage: SC
- trust: full validity: full
- sub 2048R/01DECAF7 created: 2007-06-02 expires: 2012-05-31 usage: E
- [ full ] (1). Jane Admin <jane_admin@example.net>
- Please note that the shown key validity is not necessarily correct
- unless you restart the program.
-
- Command> save
- Key not changed so no update needed.
- $
-
-Note: Due to a limitation with gnupg, it is not currently possible to
-limit the domain scope properly, which means that if you fully trust
-an admin, you'll trust all their certifications.
-
-Because the Monkeysphere currently relies on GPG's definition of the
-OpenPGP web of trust, it is important to understand [how GPG
-calculates User ID validity for a key](/trust-models).
-
-
-Miscellaneous
--------------
-
-Users can also maintain their own `~/.ssh/authorized_keys` files with
-the Monkeysphere directly. This is primarily useful for accounts on
-hosts that are not already systematically using the Monkeysphere for
-user authentication. If you're not sure whether this is the case for
-your host, ask your system administrator.
-
-If you want to do this as a regular user, use the
-`update-authorized_keys` command:
-
- $ monkeysphere update-authorized_keys
-
-This command will take all the user IDs listed in the
-`~/.monkeysphere/authorized_user_ids` file and check to see if
-there are acceptable keys for those user IDs available. If so, they
-will be added to the `~/.ssh/authorized_keys` file.
-
-You must have indicated reasonable ownertrust in some key for this
-account, or no keys will be found with trusted certification paths.
-
-If you find this useful, you might want to place this command in your
-crontab so that revocations and rekeyings can take place
-automatically.
diff --git a/website/archive-key.mdwn b/website/archive-key.mdwn
deleted file mode 100644
index 6552fde..0000000
--- a/website/archive-key.mdwn
+++ /dev/null
@@ -1,139 +0,0 @@
-[[!meta title="Monkeysphere archive signing key"]]
-[[toc ]]
-
-## Verifying the key ##
-
-The [Monkeysphere apt repository](/download) is signed by this key, so
-you [can verify](http://wiki.debian.org/SecureApt) that the packages
-come from the right place and have not been tampered with.
-
-This key is certified by several of the Monkeysphere developers, and
-should be able to be found from the public keyservers with:
-
- $ gpg --recv-key EB8AF314
- gpg: requesting key EB8AF314 from hkp server pool.sks-keyservers.net
- gpg: key EB8AF314: public key "Monkeysphere Archive Signing Key (http://archive.monkeysphere.info/debian)" imported
- gpg: no ultimately trusted keys found
- gpg: Total number processed: 1
- gpg: imported: 1 (RSA: 1)
- $
-
-You should be able to verify the fingerprint like this:
-
- $ gpg --list-key --fingerprint http://archive.monkeysphere.info/debian
- pub 4096R/EB8AF314 2008-09-02 [expires: 2009-09-02]
- Key fingerprint = 2E8D D26C 53F1 197D DF40 3E61 18E6 67F1 EB8A F314
- uid [ full ] Monkeysphere Archive Signing Key (http://archive.monkeysphere.info/debian)
- $
-
-And you can also verify the fingerprints with:
-
- $ gpg --list-sigs http://archive.monkeysphere.info/debian
-
-If you believe that the repository has been tampered with, please [let
-us know](/community)!
-
-If you have properly verified this key, you can add it to your apt
-keyring for proper cryptographic verification of the archive and its
-packages by doing the following:
-
- $ gpg -a --export EB8AF314 | sudo apt-key add -
- OK
- $ aptitude update
- ...
-
-## The key itself ##
-
-<pre>
------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v1.4.9 (GNU/Linux)
-
-mQINBEi9Ws0BEADUROJtI2VsWGI6jklofbCDw6webGi0nJTnKYSSxDE5XSWu6GtK
-PG4RiX/YGtL+kD8+z/pVAbjqdLNypqiK5VkTZp3cE+4Yv2jxySQJz/UMNZ2wO3U+
-9NAK2rJG3p0HhiTzAurJ2KqNstcMcPmqEDtP+J2tUHoIXttGiwFpss4R2hSBMlg+
-nNFc53FlTadF2z3LNNCozPf7wRST2Zqkeem84+Vo2X3zy7pGpSf9S/XEPW/ve0fs
-daADK9I6fZiqtrsb3/M3E3rESsD2YA+/25QA+XVJgtenTlaYEMkI0ARpd44oBHp7
-Oj0RbRZ0Wz6OYDiJl6D2YJ1nFRHhbx+tnCJvuqUUkv3HYD85mGWIow7ElX5fc4iT
-RdYUE3ebImES0gsaasNl3JUjuImNbrqqjQsAaN7JV77TqR8GGRLcalZkvIgY5b4a
-hRYY16rvUaqZ4aYpiZftvE0X07W+siYqGfCynOn0+iX80pKid8gATjrwGdQ6TBr7
-+yrBkmFTJFCCi5TS8gaJPdMJzYs7C3ou9XOWJLuwmnwn9edaCSTJ1Vgq+8eKjDj8
-NxER5vjtXdAJqCJm7d4eNgHYXTNqRPznJRsutVfkFwEIzGXvvhnnDC1PdnhBjBVI
-1+TbdSz9qKq3VaCxr6HNk9CBF2S0El3YMRmy0Zlf6/AOo9XiW3fp3LL6AwARAQAB
-tEpNb25rZXlzcGhlcmUgQXJjaGl2ZSBTaWduaW5nIEtleSAoaHR0cDovL2FyY2hp
-dmUubW9ua2V5c3BoZXJlLmluZm8vZGViaWFuKYkCPAQTAQIAJgUCSL1azQIbAwUJ
-AeEzgAYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEBjmZ/HrivMUFIYP/30NIcTO
-EucC2S3YI+8UiedBfqM6iIJ9jS73avvfNdjv5MsfTeERXOGKgmE/JM2FwtIPgzOU
-R7qEu0W4WG2kYN+pABzpoRijm9F2zwNzSrZdzinClhxKBZzhg9tylvXdVxrdfAVS
-3XoQrAK5W/5zZBBmkW18bmlgu7hLY9jfYfwJH1/jhV40UtuWPW5kfBoZlrv9S4l2
-WUA7drrWlyk+h4Q/ZxF6aQljyI9a1oXNfcgpGCorIBNlMlwjNaL4DWmH4j/kchLG
-Vka35t3R5OjlRo8jsd12nc6gp0K3BdDTEd1AJQbqTS+sb+ocdeNpSUQoCn8XIg9V
-ELV9XE0n2vmvG3i4CJuOyHOHuW5IqJ1k8W4e9fikpBOmOy7Jdec5johI9wtkRiYg
-9i5vqM/wKSW14QCkLeQP/YtIK0o0J+FOj7FUTI+wM5AXGeva53McnzbiUnJPRFIR
-du8vvdmvu1wuWb3AWLIysU0bsbSSGZ9g7cX2p/qdH1Hvi2Ji8sM020WHBFuvRXEJ
-i8/RXiIxj0LR/DO8ihd/x1MTwfSTEZ6ecnywDv7Wtx19i5NRX5Ik72M75kzD29TW
-7mTsgZbYWrHT3gHmL3pWxPKa8nsEC/HUlcCnIrOPiwNcNu7+4L1ikbJXDRwVLjWP
-enmAs1srZ2+Pm2Gm1pM6uzl0qGR9J5GmdPf2iQIcBBABAgAGBQJIvVyrAAoJEMzS
-7ZTSFznpYQ0P/iTg3IlgNiRAlYXcrmiKKbMLSgUekQl6O7eUowXS9vKEyzgcxr3e
-DWARHsf01DrHJvkwdbaQPmq5mZcWxYaEdWY7VtCNHf11vnRV6ws7S3aiV3Hmf0II
-GaGBJywhDw/hkz2gTM3V71whYm1tgPbw/ilVqJtt8jVL9qbGsXer8Yx0iLFSCfaj
-SpgBo/1WlyxSm+i958ddSaQ+uTrAPgChYT7jseAIzF3UB95i00OkHaK30tb6SdWC
-4hgptMAhU0lW9tKDviMtoKUQa7LiCa4RyQ9TJQcsjJBoFVskcLl9f6GNEP72bN0V
-ly087Guvw8G8TdQcubteFYQDIxIc2atZkjEn3oCjtZgk8mdDlCjLQYgHV1/o+eWd
-/mb9mCtKvwo14LeKIIIYP19Z7142X2c2txSY3u6eNNo3ImqcPJNOM2xFqLcdSeVr
-S31RCBx16I7tJya0fwJJRC7qZWf7hrPdi7eqcecqyr26X5upV+Irjv5qYu/6HAGb
-59W6n+8KTfMxEMaBQI6qZXxhaBr3HzEaSrz7jtkl+xxym2TGkbarXcm7e7MP66Hu
-GD5UCC3svhAAxKXf4K/8v7WhwBpekF9mXtgpq72Du2JG9q+OAWhxzZXbZku+RY7T
-a83wKc1TaPvzK2WZlhNGjcCYSUXcfQOSn5noVTUukW3DNEKP5BmwkvVdiEYEEBEC
-AAYFAki9wXQACgkQ9n4qXRzy1ioXYwCgmzCV+o+Ai0gNx0pt9shofcjfJoAAoInV
-mhn36lBeDh/E6cigrUlkdDGWiQIcBBABAgAGBQJIvdcSAAoJEO00zqvie6q8sB4Q
-AKDLTKqtiONf4FkMCZFcMxQyiALcy76zTW9L2oK90zKRhKSt5RPnVmDVyiinBcRJ
-h0lEkpxoqSrs+0XvASWC3RzWLEbW6XXsuHO1RXFsC3FNbe0HkHenirenFkitPMDX
-Q5gHmCJ6yiq2ssuzXAG9vZ4HjkUINBgkeMASiTRC7o0we7jFSRzOTCs4WWdsavrx
-7bhCadeC35ISldTSo6nOP3laPctPcLD83cJszzQyHr/LjF6KYr6n85NAwIt/oxHh
-EUxmezx+lMwWHdr9TQzXzU8cxLSBZ+c+PuZ/NuHz9fOv87eaFDNEqKli9zhzh4eA
-EMeiWKQXHYlmEUUWnZoea46jdjBrvHphogqlCjzMDHtg/pWOsYrGeXjjZ352SGN4
-vyinkdxwUppGQATz55WyiWIzCY1Kt7lqaQHfAM1NgVdoCQ0stlulIO4LVepHRiAY
-HO4EPeQO6pVGGHWCzJyEcMcaBsYGpr9DndSNd66O+Gyeq8QobKnvTH25kwVt/8t1
-9nS+7NLwBrqXCISeDrOQYq5XeCdvpAuJy4CEN5muQWRdUPekE2dh7qcVUdROepq0
-1wMemkmgTLlA0Md7ZdZqsllKhVQ7/HOFzshEaj/VcFrQshuIAjDZFN/OrGLX/NcL
-tcaBmD9lZSQ3CyxnBUTeMdJCOLOK050jNvsEsM89FL+g
-=bJWl
------END PGP PUBLIC KEY BLOCK-----
-</pre>
-
-## Management of the key ##
-
-The archive signing key is currently under the control of [Daniel Kahn
-Gillmor](http://cmrg.fifthhorseman.net/dkg), though the task of being
-the archive maintainer may be taken over by a different developer in
-the future.
-
-In the event of a new archive maintainer, the entire archive will be
-rebuilt from signed tags in [the monkeysphere git
-repository](/community), rather than trying to re-verify the entire
-old archive.
-
-## Maintaining the archive ##
-
-To create a new archive including a single monkeysphere package from
-tag `$TAG` on architecture `$ARCH`, do:
-
- git clone git://git.monkeysphere.info/monkeysphere
- cd monkeysphere
- git tag -v "$TAG"
- git checkout "$TAG"
- debuild -uc -us
- cd repo
- reprepro -C monkeysphere include experimental "../$TAG_$ARCH.changes"
-
-When you get a binary package built from a separate architecture
-`$NEWARCH` that you want to include with the archive, do:
-
- cd repo
- reprepro -C monkeysphere includedeb experimental "../$TAG_$NEWARCH.deb"
-
-To publish the archive, make sure you have access to
-`archivemaster@george.riseup.net`, and then do:
-
- cd repo
- ./publish
diff --git a/website/bugs.mdwn b/website/bugs.mdwn
deleted file mode 100644
index 91ff025..0000000
--- a/website/bugs.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta title="Open Bugs"]]
-
-# Bugs #
-
-The Monkeysphere is moving to a [new issue tracking
-system](https://labs.riseup.net/code/projects/show/monkeysphere),
-hosted at [Riseup Labs](https://labs.riseup.net/code). We're leaving
-this old bug list up during the transition.
-
-If you use [Debian](htt[://debian.org), please consider submitting
-your bug to the [Debian BTS](http://bugs.debian.org/monkeysphere).
-
-You can also browse our [completed bugs](done).
-
-Please feel free to also ask any questions on the [the monkeysphere
-mailing list](/community).
-
-[[!inline pages="./bugs/* and !./bugs/done and !link(done)
-and !*/Discussion" actions=yes postform=yes show=0]]
diff --git a/website/bugs/add-identity-certifier-behaves-oddly-without-pty.mdwn b/website/bugs/add-identity-certifier-behaves-oddly-without-pty.mdwn
deleted file mode 100644
index 1962fe5..0000000
--- a/website/bugs/add-identity-certifier-behaves-oddly-without-pty.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-When executing `monkeysphere-server add-identity-certifier` across a
-link without a pseudo-terminal, it behaves oddly (prompts are created
-that are only halfway-readable, gpg gives error messages about lacking
-access to a `/dev/tty`, etc.
-
-You can try this directly if you have remote ssh access to the
-superuser on a monkeysphere-enabled host, assuming that `$GPGID` is
-set to the full fingerprint of a key you want to add as a trusted
-identity certifier:
-
- ssh root@example.org monkeysphere-server add-identity-certifier $GPGID
-
-Compare this behavior with:
-
- ssh -t root@example.org monkeysphere-server add-identity-certifier $GPGID
diff --git a/website/bugs/add-man-pages-to-website.mdwn b/website/bugs/add-man-pages-to-website.mdwn
deleted file mode 100644
index 0aaee21..0000000
--- a/website/bugs/add-man-pages-to-website.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!meta title="Add man pages to web site"]]
-
-We should publish the various monkeysphere man pages in browsable form
-somewhere under http://web.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/allow-publishing-to-public-keyservers.mdwn b/website/bugs/allow-publishing-to-public-keyservers.mdwn
deleted file mode 100644
index 5d4ce4c..0000000
--- a/website/bugs/allow-publishing-to-public-keyservers.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta title="monkeysphere-server publish-key does not work"]]
-
-Currently, if you try to run `monkeysphere-server publish-key`, you
-can get the following output:
-
- Really publish key to subkeys.pgp.net? (y/N) y
- NOT PUBLISHED (to avoid permanent publication errors during monkeysphere development).
- The following command should publish the key:
- monkeysphere-server gpg-authentication-cmd '--keyserver subkeys.pgp.net --send-keys foo.example.org'
-
-I think we've demonstrated that this system works enough to warrant
-using the public keyserver infrastructure.
-
-I suggest that we should actually enable this feature explicitly.
-(leaving in the prompt is fine, though it would be nice to be able to
-`--force` it or something).
-
----
-
-[[bugs/done]] 2008-08-15 in 6fb350a883fa4d8b1bc9b5e01cc3b01c96354d08
diff --git a/website/bugs/authorized_keys-options.mdwn b/website/bugs/authorized_keys-options.mdwn
deleted file mode 100644
index 69e62fa..0000000
--- a/website/bugs/authorized_keys-options.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta title="Monkeysphere support for options in authorized_keys"]]
-
-OpenSSH [allows users to control the capabilities granted to remote
-key-based
-logins](http://www.hackinglinuxexposed.com/articles/20030109.html) by
-supplying options that should limit the use of the key.
-
-For example, specifying `no-pty` means that `sshd` should not allocate
-a pseudo-terminal for sessions created based on an authentication with
-that key.
-
-It is unclear if it is possible to do this sort of limiting in
-`~/.monkeysphere/authorized_user_ids`, and if it is possible, how
-you'd actually do it.
-
- --dkg
diff --git a/website/bugs/authorized_keys_not_cleared.mdwn b/website/bugs/authorized_keys_not_cleared.mdwn
deleted file mode 100644
index 0c4dbb6..0000000
--- a/website/bugs/authorized_keys_not_cleared.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!meta title="users with missing or empty authorized keys and User IDs should have MS-generated keys cleared" ]]
-
-I had a user who had a bunch of entries in
-`~/.monkeysphere/authorized_user_ids`, and a bunch of raw keys in
-`~/.ssh/authorized_keys`. My system's `monkeysphere-server` handled
-this situation appropriately, and populated
-`/var/lib/monkeysphere/authorized_keys/user` with the full set.
-
-Then i wanted to wipe out all key entries for that user. So i did:
-
- mkdir ~user/backup
- mv ~user/.ssh ~user/.monkeysphere ~user/backup
- monkeysphere-server update-users user
-
-I expected this to either remove
-`/var/lib/monkeysphere/authorized_keys/user`, or truncate it to 0
-bytes. However, it just remained untouched, and the old keys
-persisted.
-
-This seems like a potential security problem.
-
----
-
-[[bugs/done]] on 2008-10-26 in c8ab71b24b566967fdb39818d071f6548dc056c8
diff --git a/website/bugs/cssh-connection-timeout.mdwn b/website/bugs/cssh-connection-timeout.mdwn
deleted file mode 100644
index 343d5af..0000000
--- a/website/bugs/cssh-connection-timeout.mdwn
+++ /dev/null
@@ -1,93 +0,0 @@
-[[!meta title="Monkeysphere interferes with clusterssh"]]
-
-clusterssh is a package that allows you to control multiple ssh xterm
-sessions at the same time.
-
-When the monkeysphere-ssh-proxycommand is enabled and I launch 5 or more
-cssh sessions, intermittently one or two out of every five will fail
-with: Connection timed out during banner exchange.
-
-I tried to debug by running:
-
- MONKEYSPHERE_LOG_LEVEL=debug cssh -D -d <server1> <server2> etc.
-
-However, while it produced some private data, it didn't give me any
-insight into what was going wrong. Also, it didn't output any
-Monkeysphere debugging info.
-
-I had no luck with google and the error message being output.
-
-This isn't a huge priority (it's not hard to disable the
-monkeysphere-ssh-proxycommand before running cssh), however, it would be
-nice to figure out why it's not working.
-
----
-
-What do you mean by "produced some private data" when you set the log
-level to DEBUG? Monkeysphere does not output any "private" data in
-the sense of private keys or passwords or anything like that. Maybe
-you mean the cssh debug mode outputs private data? or do you just
-mean "info that you don't want to post here"? It might be useful to
-see some output, so maybe you could just block out the nasty bits?
-But I'm not sure it will help.
-
-The problem may be due to the locking of the known\_hosts file while
-the proxycommand is running. At the moment, the
-monkeysphere-ssh-proxycommand can only be run serially, since each
-invocation will lock the known\_hosts file while it updates it. I
-think this is required, since we obviously can't have two invocations
-modifying the file at the same time. However, it's probably possible
-to decrease the amount of time it takes to update the file. It's not
-done very efficiently at the moment. The file is locked basically at
-the very begining, and is locked while all gpg interactions are done,
-which are slow. I think it should be possible to take the gpg
-interactions out of the loop.
-
-I just tried cssh and it doesn't seem to work very well with my ssh
-setup at all. For instance, the simultaneous ssh connections cause
-simultaneous calls to the agent to get my permission to use the key,
-which don't interact very well with each other. This of course is not
-a monkeysphere problem but a general problem with trying to make
-simultaneous ssh connections with an agent that want key use
-confirmation.
-
--- jrollins
-
----
-
-I can get cssh to work fine with a confirmation-required agent if i
-turn off the monkeysphere proxycommand:
-
- cssh -l username -o '-oProxyCommand=none' $(cat hostlist.txt)
-
-with the proxycommand, i definitely get the "Connection timed out
-during banner exchange" message.
-
-However, i'm also able to get the cssh connection to work if i assert
-that a longer connection timeout is acceptable:
-
- cssh -l username -o '-oConnectTimeout=30' $(cat hostlist.txt)
-
-Perhaps this is an acceptable workaround?
-
--- dkg
-
----
-
-Sorry for not being more clear. Monkeysphere debug does not reveal personal
-information - but cluster cssh -d -D exposes the hosts in my ssh config file.
-
-dkg's approach seems to work. His suggestion, as written, didn't work for me.
-But that's because I ran cssh -u > $HOME/.csshrc, which generates a default
-cssh config file (that specifies ConnectTimeout=10). That file seems to
-override the command linke (perhaps a cssh bug?). I changed the ConnectTimeout
-to 30 in my ~/.csshrc file and now everything works.
-
-I think jrollins' assessment is probably right - the extra delay due to locking
-causes the timeout. I think tweaking ConnectTimeout parameter via the .csshrc
-file or via the command line is a reasonable fix for this bug, so I'm closing
-as [[bugs/done]].
-
--- Sir Jam Jam
-
-I just [posted the cssh bug in debian](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498968).
diff --git a/website/bugs/done.mdwn b/website/bugs/done.mdwn
deleted file mode 100644
index e29587c..0000000
--- a/website/bugs/done.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-[[!meta title="Completed Bugs"]]
-
-Recently fixed [[bugs]].
-
-[[!inline pages="./* and link(./done) and !*/Discussion" sort=mtime show=10]]
diff --git a/website/bugs/genericize-filesystem-locations-for-testsuite.mdwn b/website/bugs/genericize-filesystem-locations-for-testsuite.mdwn
deleted file mode 100644
index 6cc3773..0000000
--- a/website/bugs/genericize-filesystem-locations-for-testsuite.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!meta title="genericize all filesystem locations to enable test suite:" ]]
-
-I'm in the process of writing a testsuite for the monkeysphere so that
-we can verify that it actually performs all the basic expected duties
-properly.
-
-It occurs to me that lines like these:
-
- ETC="/etc/monkeysphere"
- VARLIB="/var/lib/monkeysphere"
-
-Actually make it very difficult to generically test the tool without
-it being installed system-wide.
-
-Is there any reason that we should not allow these directories to be
-overridden with environment variables in the same way that
-`/usr/share/monkeysphere/share` is handled?
-
- SHARE=${MONKEYSPHERE_SHARE:-"/usr/share/monkeysphere"}
-
-I guess i'm proposing something like:
-
- SYSCONFIGDIR=${MONKEYSPHERE_SYSCONFIGDIR:-"/etc/monkeysphere"}
- SYSDATADIR=${MONKEYSPHERE_SYSDATADIR:-"/var/lib/monkeysphere"}
-
-Thoughts?
-
---dkg
-
----
-
-[[bugs/done]] on 2008-10-11
diff --git a/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn b/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn
deleted file mode 100644
index d10a164..0000000
--- a/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-In monkeysphere-server, the gpg\_authentication function, and
-consequently the gpg\_authentication\_cmd, currently requires that all
-arguments be put in a single quoted argument, eg:
-
- gpg_authentication "--list-key --with-colons --with-fingerprint 0x${keyID}!"
-
-This is obviously a little lame, but it seems to be necessary to do
-the necessary argument passing from the function, to the su function
-called as the monkeysphere user that controls the gpg authentication
-keyring.
-
-I'm not sure how to fix it. I think the problem is mostly in how
-arguments are passed to su.
-
--- Big Jimmy.
diff --git a/website/bugs/handle-passphrase-locked-secret-keys.mdwn b/website/bugs/handle-passphrase-locked-secret-keys.mdwn
deleted file mode 100644
index 5143db6..0000000
--- a/website/bugs/handle-passphrase-locked-secret-keys.mdwn
+++ /dev/null
@@ -1,117 +0,0 @@
-[[!meta title="MonkeySphere can't deal with passphrase-locked primary keys"]]
-
-At the moment, the only tool we have to export passphrase-locked
-secret keys from the GPG keyring is `gpg` itself (and `gpg2`, which
-has roughly the same behavior).
-
-As a result, we have the `seckey2sshagent` hack, which is unfriendly
-and awkward to use.
-
-Ideally, `openpgp2ssh` would be able to convert passphrase-locked
-secret keys into clean subkeys. However, i've tried to do this via
-GnuTLS, and that library is not ready for this.
-
-OpenCDK, which is the component of GnuTLS which reads OpenPGP-style
-keys, cannot cope with encrypted secret key material. I have had
-[some
-success](http://lists.gnu.org/archive/html/gnutls-devel/2008-06/msg00092.html)
-in getting GnuTLS's OpenCDK to accept the existence of encrypted
-secret key packets, [i learned that OpenCDK as included in GnuTLS is
-incapable of dealing with the encrypted packets
-themselves](http://lists.gnu.org/archive/html/gnutls-devel/2008-07/msg00012.html).
-
-
-Some possible resolutions:
-
----------
-
-If we can assume that the passphrase-encrypted key we want to use is
-actually a subkey, and if we could fix GnuTLS to ignore the use of the
-"gnu-dummy S2K" produced by `gpg --export-secret-subkeys` for the
-primary key, then something like the following script should actually
-work for reasonable values of `$KEYID`:
-
- TMPDIR=$(mktemp -d)
- umask 077
- mkfifo "$TMPDIR/passphrase"
- kname="MonkeySphere Key $KEYID"
- mkfifo "$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"
-
-Good news! [I've crafted a patch for GnuTLS to enable it to read
-exported subkeys using this GNU
-extension](http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html),
-so if we can get it incorporated into upstream (and/or into debian),
-we have a possible solution, as long as the authentication key is a
-subkey, and not a primary key.
-
-As of version 0.11-1, `monkeysphere subkey-to-ssh-agent` implements
-this particular strategy (and fails cleanly if the version of GnuTLS
-present doesn't support the GNU dummy S2K extension).
-
----------
-
-Ben Laurie and Rachel Willmer's
-[OpenPGPSDK](http://openpgp.nominet.org.uk) is a candidate: this is a
-C-based library that intends to implement RFC 4880 functionality.
-
-We could potentially re-write `openpgp2ssh` using this library, and it
-*should* be able to handle everything we need from the OpenPGP side
-(though it might need to be re-linked to OpenSSL to handle PEM-encoded
-exports.
-
-Concerns:
-
-* OpenPGPSDK is not in debian yet, and doesn't currently (2008-08-13)
- build with gcc 4.2 or 4.3.
-
-* OpenPGPSDK uses the apache license and appears to link to OpenSSL,
- which has a GPL-incompatible license. I think this would mean that
- `openpgp2ssh` could not remain GPL (though the rest of the
- monkeysphere could).
-
----------
-
-We could try to use perl. The last time i checked, the pure-perl
-OpenPGP implementations all depended on Math::PARI, which [is not in
-debian](http://bugs.debian.org/440527). The most likely candidate is
-[Crypt::OpenPGP](http://search.cpan.org/~btrott/Crypt-OpenPGP),
-despite [some
-bugginess](http://cpanratings.perl.org/dist/Crypt-OpenPGP).
-
-Concerns:
-
-* the aforementioned buggy reviews
-
-* there's a lot of dependency chasing to get anything like this
- available in debian.
-
----------
-
-Other alternatives?
-
---------
-
-Can this bug be closed? dkg [reported in a comment for a related
-bug](/bugs/install-seckey2sshagent-in-usr-bin/):
-
- Version 0.11-1 now has the monkeysphere subkey-to-ssh-agent
- subcommand, which works cleanly in the presence of a
- functionally-patched GnuTLS.
-
---------
-
-Even with the patched GnuTLS, monkeysphere currently can't currently
-deal with passphrase-locked primary keys. I've changed the title of
-this bug, but i'd like to keep it open until we are able to deal with
-that. The other comments here seem still quite relevant to that
-need.
-
-I've changed the title of this bug to reflect the narrowed scope.
-
- --dkg
diff --git a/website/bugs/headless-servers-take-too-long-to-generate-host-key.mdwn b/website/bugs/headless-servers-take-too-long-to-generate-host-key.mdwn
deleted file mode 100644
index c7912de..0000000
--- a/website/bugs/headless-servers-take-too-long-to-generate-host-key.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta title="Running `monkeysphere gen-key` on a headless server takes way too long"]]
-
-When i try to generate a key on a headless machine (no kbd, no mouse,
-no Human Input Device (HID) at all), `monkeysphere gen-key` hangs for
-a *very* long time (over an hour so far!) during the generation
-process, particularly at this point:
-
- ms: generating server key...
-
- Not enough random bytes available. Please do some other work to give
- the OS a chance to collect more entropy! (Need 197 more bytes)
-
-And sure enough, there really is very little entropy in these systems
-at the time requested:
-
- 0 chomsky:~# cat /proc/sys/kernel/random/entropy_avail
- 32
- 0 chomsky:~#
-
-It's not clear to me how to increase the entropy available to the
-kernel without an HID.
-
-I've seen this happen on two machines now in the last week, and was
-able to resolve it on the first one by plugging in a keyboard and
-"massaging" it. This won't work for a machine that's out of physical
-range, and has no keyboard to be plugged in anyway.
-
-One thing that might help is to suggest that the system administrator
-install a package like `bsdgames` and play console-based games as a
-non-privileged user, since that seems to feed the entropy count
-somewhat.
diff --git a/website/bugs/hostkeyalias-confuses-monkeysphere.mdwn b/website/bugs/hostkeyalias-confuses-monkeysphere.mdwn
deleted file mode 100644
index 4f7df66..0000000
--- a/website/bugs/hostkeyalias-confuses-monkeysphere.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-Consider the following snippet in `~/.ssh/config`:
-
- Host foo
- HostKeyAlias bar
-
-for a host which is *not* participating in the monkeysphere.
-
-For such a host, when using `monkeysphere-ssh-proxy-command`, the
-public keyservers will be queried on each attempted ssh connection
-(even after a successful connection).
-
-This appears to be because:
-
-* `ssh` itself will write a line to `~/.ssh/known_hosts`, but it will
- be labeled with `bar` because of the `HostKeyAlias`.
-
-* `monkeysphere` won't be able to find any mention of it in the
- keyring (it's not in the monkeysphere)
-
-* `monkeysphere-ssh-proxycommand` won't be able to find it in the
- `known_hosts` file because it looks for `foo`, which is never
- matched.
-
-excessive keyserver querying is bad behavior, because it causes delays
-for the users, and puts excessive load on the public keyserver
-infrastructure.
-
-How can we resolve this?
diff --git a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
deleted file mode 100644
index 04322a4..0000000
--- a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
+++ /dev/null
@@ -1,59 +0,0 @@
-[[!meta title="Install seckey2sshagent in /usr/bin/"]]
-
-I know it's a hack - but installing seckey2sshagent in /usr/bin/ would make it
-much easier for people to use.
-
----
-
-I'm not sure I really want to include this hack with the debs. It's
-really not useful for any kind of regular use. I would rather focus
-on getting openpgp2ssh to support passprotected keys.
-
-As another possibility, I was planning on modifying the script so that
-it could export to a passprotected file. I think this would be a lot
-more useful. Let me get that working, then let's revist the issue of
-including it in the packaging.
-
--- Big Jimmy
-
----
-
-Ok - sounds good to me. I'm thinking in terms of getting other people to try
-out the Monkeysphere - maybe the README should just say: we're only half
-done. You can verify the identity of servers, but we haven't completed the
-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 subkey-to-ssh-agent`,
-which would fail in the absence of a functionally-patched GnuTLS.
-
-Would this proposal be sufficient to resolve this bug?
-
---dkg
-
----
-
-Version 0.11-1 now has the `monkeysphere subkey-to-ssh-agent`
-subcommand, which works cleanly in the presence of a
-functionally-patched GnuTLS.
-
---dkg
-
----
-
-I'm marking this bug as [[bugs/done]] - I no longer think we should install
-seckey2sshagent in bin now that we have a clean way of accomplishing that task.
-Nice work dkg!
-
---sjj
diff --git a/website/bugs/list-id-certifiers-should-run-non-priv.mdwn b/website/bugs/list-id-certifiers-should-run-non-priv.mdwn
deleted file mode 100644
index 32116c0..0000000
--- a/website/bugs/list-id-certifiers-should-run-non-priv.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!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/make-tarball-is-not-idempotent.mdwn b/website/bugs/make-tarball-is-not-idempotent.mdwn
deleted file mode 100644
index 8e207e4..0000000
--- a/website/bugs/make-tarball-is-not-idempotent.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!meta title="make tarball is not idempotent" ]]
-
-The current monkeysphere Makefile has a "tarball" target, which
-produces the "upstream tarball". Unfortunately, it is not idempotent.
-That is, if you run it twice in a row (without changing any other
-source), the second .orig.tar.gz file is bytewise different from the
-first.
-
-We should fix this so that the tarball generated is the same at least
-as long as no local file has been touched.
-
---dkg
diff --git a/website/bugs/missing-known_hosts-causes-error.mdwn b/website/bugs/missing-known_hosts-causes-error.mdwn
deleted file mode 100644
index 5be0a44..0000000
--- a/website/bugs/missing-known_hosts-causes-error.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!meta title="Missing `~/.ssh/known_hosts` file causes errors from monkeysphere-ssh-proxycommand"]]
-
-As a user, if you don't have a `~/.ssh/known_hosts` file,
-`monkeysphere-ssh-proxycommand` produces some bogus output, like:
-
- cat: /home/foo/.ssh/known_hosts: No such file or directory
-
-this should be fixable with a simple test.
-
-------
-
-Fixed in 70674cae8b3d69d0e750125387b26c0d5857c5ba.
-
-[[bugs/done]] 2008-08-12
diff --git a/website/bugs/monkeysphere-gen-key-should-guess-KeyID.mdwn b/website/bugs/monkeysphere-gen-key-should-guess-KeyID.mdwn
deleted file mode 100644
index 0cab051..0000000
--- a/website/bugs/monkeysphere-gen-key-should-guess-KeyID.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta title="`monkeysphere gen-key` should guess at KeyID if none provided"]]
-
-Currently, if you have a single private key in your GnuPG keyring, and
-you call:
-
- monkeysphere gen-key
-
-(with no additional arguments), it will report an error.
-
-It would be more user-friendly if we could guess which key to use. I
-suggest:
-
-* If the user only has no GPG secret keys at all, it should fail, and
- suggest that the user create a key first, then re-run `monkeysphere
- gen-key`. (`monkeysphere` could actually invoke `gpg --gen-key` for
- the user directly, if the user wants that)
-
-* If the user only has one GPG secret key, it should use that key.
-
-* If the user has more than one GPG secret key, `monkeysphere` should
- fail, and report the different key IDs that they user might want to
- select (reporting which keys already have authorization subkeys or
- the authorization capability on the primary key would be useful too)
-
-[[bugs/done]] completed 2008-08-08 09:40:33-0400 (to be released in 0.8-1)
diff --git a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn b/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn
deleted file mode 100644
index 1e33439..0000000
--- a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn
+++ /dev/null
@@ -1,144 +0,0 @@
-[[!meta title="monkeysphere --gen-subkey seems to fail if no gpg-agent is running"]]
-
-Consider the following transcript of a user who starts with no OpenPGP
-key in the first place:
-
- 0 wt215@squeak:~$ monkeysphere gen-subkey
- You have no secret key available. You should create an OpenPGP
- key before joining the monkeysphere. You can do this with:
- gpg --gen-key
- 255 wt215@squeak:~$ gpg --gen-key
- 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.
-
- Please select what kind of key you want:
- (1) DSA and Elgamal (default)
- (2) DSA (sign only)
- (5) RSA (sign only)
- Your selection? 5
- RSA keys may be between 1024 and 4096 bits long.
- What keysize do you want? (2048) 1024
- Requested keysize is 1024 bits
- Please specify how long the key should be valid.
- 0 = key does not expire
- <n> = key expires in n days
- <n>w = key expires in n weeks
- <n>m = key expires in n months
- <n>y = key expires in n years
- Key is valid for? (0) 1
- Key expires at Sat 09 Aug 2008 09:41:34 AM EDT
- Is this correct? (y/N) y
-
- You need a user ID to identify your key; the software constructs the user ID
- from the Real Name, Comment and Email Address in this form:
- "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
-
- Real name: Foo T. Bar
- Email address: monkey@example.org
- Comment: DO NOT USE!
- You selected this USER-ID:
- "Foo T. Bar (DO NOT USE!) <monkey@example.org>"
-
- Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
- You need a Passphrase to protect your secret key.
-
- We need to generate a lot of random bytes. It is a good idea to perform
- some other action (type on the keyboard, move the mouse, utilize the
- disks) during the prime generation; this gives the random number
- generator a better chance to gain enough entropy.
- +++++
- gpg: key A09F70B7 marked as ultimately trusted
- public and secret key created and signed.
-
- gpg: checking the trustdb
- gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
- gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
- gpg: next trustdb check due at 2008-08-09
- pub 1024R/A09F70B7 2008-08-08 [expires: 2008-08-09]
- Key fingerprint = C3D3 1063 7CA1 5809 9EB9 7A63 F4E4 8D01 A09F 70B7
- uid Foo T. Bar (DO NOT USE!) <monkey@example.org>
-
- Note that this key cannot be used for encryption. You may want to use
- the command "--edit-key" to generate a subkey for this purpose.
- 0 wt215@squeak:~$ monkeysphere gen-subkey
- Please specify how long the key should be valid.
- 0 = key does not expire
- <n> = key expires in n days
- <n>w = key expires in n weeks
- <n>m = key expires in n months
- <n>y = key expires in n years
- Key is valid for? (0) 2
- ms: generating subkey...
- 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/A09F70B7 created: 2008-08-08 expires: 2008-08-09 usage: SC
- trust: ultimate validity: ultimate
- [ultimate] (1). Foo T. Bar (DO NOT USE!) <monkey@example.org>
-
- Key is protected.
-
- You need a passphrase to unlock the secret key for
- user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>"
- 1024-bit RSA key, ID A09F70B7, created 2008-08-08
-
- gpg: Invalid passphrase; please try again ...
-
- You need a passphrase to unlock the secret key for
- user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>"
- 1024-bit RSA key, ID A09F70B7, created 2008-08-08
-
- gpg: Invalid passphrase; please try again ...
-
- You need a passphrase to unlock the secret key for
- user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>"
- 1024-bit RSA key, ID A09F70B7, created 2008-08-08
-
- gpg: Key generation failed: bad passphrase
-
-
- Invalid command (try "help")
-
- ms: done.
- 0 wt215@squeak:~$
-
-This user does not have `use-agent` configured in `~/.gnupg/gpg.conf`.
-
-This problem can be resolved by the user doing:
-
- echo use-agent >> ~/.gnupg/gpg.conf
- gpg-agent --daemon monkeysphere --gen-subkey
-
-Then they will be prompted for their passphrase during key creation.
-
-If we're OK with relying on `gpg-agent`, we should make make that an
-explicit dependency, and ensure that an agent is running (or start one
-up specifically for the process).
-
-If we're not OK with relying on the agent, `--gen-subkey` needs
-fixing.
-
----
-
-I think requiring the agent and using it for getting the passphrase is
-fine. That should make this bug fairly easy to fix, so I'll get on
-it.
-
--- BJ (jgr)
-
----
-
-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-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn b/website/bugs/monkeysphere-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn
deleted file mode 100644
index 3c7e804..0000000
--- a/website/bugs/monkeysphere-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-If you have a revoked authentication subkey in your keyring,
-monkeysphere gen-subkey thinks that I have an authentication subkey
-already, which I do, but it probably shouldn't care about it, since it
-is revoked:
-
- 21:30@pond> monkeysphere gen-subkey F67E2A5D1CF2D62A
- An authentication subkey already exists for key 'F67E2A5D1CF2D62A'.
- Are you sure you would like to generate another one? (y/N)
-
-However: this key was revoked on 2008-04-28 by DSA key 1CF2D62A Micah Anderson <micah@riseup.net>
- sub 1024R/866F47D3 created: 2008-02-25 revoked: 2008-04-28 usage: A
-
-I can continue to create a new authorization subkey, so its not a
-blocker or anything (I suppose I could also delete the revoked key
-from my keyring as well, although thats less than ideal).
-
-It seems like the secret keyring doesn't mention that it has been
-revoked, so probably monkeysphere needs to be looking at gpg's
-computed validity from the public keyring instead of the secret
-keyring to be able to get the "r" flag from field 2, in addition to
-the "e" flag from field 12.
-
----
-
-So the problem is that there is no field 2 for secret keys. From
-/usr/share/doc/gnupg/DETAILS.gz:
-
- 2. Field: A letter describing the calculated trust. This is a single
- letter, but be prepared that additional information may follow
- in some future versions. (not used for secret keys)
-
-Why would secret keys not have this field? They have validity too,
-right? This doesn't make any sense. I verify that indeed there is no
-output in field 2 for secret keys. I would say this is a bug in gpg,
-but it's clearly done on purpose. Any ideas?
-
--- jrollins
diff --git a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn b/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn
deleted file mode 100644
index 421587a..0000000
--- a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta title="Monkeysphere should consult keyserver setting in gpg.conf"]]
-
-Currently, monkeysphere-ssh-proxycommand checks the following places to
-determine which keyserver to use (in order of priority):
-
- * environment variable (MONKEYSPHERE_KEYSERVER)
- * KEYSERVER variable in ~/.monkeysphere/monkeysphere.conf
- * default value of subkeys.pgp.net
-
-It would be useful if monkeysphere also consulted ~/.gnupg/gpg.conf, using the
-following order instead:
-
- * environment variable (MONKEYSPHERE_KEYSERVER)
- * KEYSERVER variable in ~/.monkeysphere/monkeysphere.conf
- * keyserver variable in ~/.gnupg/gpg.conf
- * 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
deleted file mode 100644
index b814d35..0000000
--- a/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn
+++ /dev/null
@@ -1,251 +0,0 @@
-I don't mind the monkeysphere-ssh-proxycommand output on regular connections.
-
-For me it looks something like this with a server not participating in the
-monkey sphere:
-
- ms: processing host: chavez.mayfirst.org
- ms: - key not found.
-
-And like this for a server participating:
-
- ms: processing host: george.riseup.net
- ms: primary key found: 7353A74E3B757F8C
- ms: * acceptable key found.
- ms: known_hosts file updated.
-
-However, I have some batch scripts that run ssh that also provide
-output, so the monkeysphere output clutters things up.
-
-I would really like to either have a -q/--quiet option, or, preferable for me
-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
-
-------
-
-I just completed this feature. I published it to a separate branch
-(called quiet-mode). I haven't committed it to my master branch for a
-couple reasons:
-
- * I made some significant changes and wanted to ask Big Jimmy to take
- a look since it's mostly his stuff I mucked about with.
-
- * Sometime between starting my hacking and mid-way through, my
- ~.ssh/known_hosts file got truncted to nothing. I recovered from a
- backup. I couldn't figure out what caused that to happen and couldn't
- replicate it. I was debugging my bash and what I was debugging
- involved bash redirection, so it's reasonable to think that something
- I did caused the problem. However, before committing we incorporate
- this, I would appreciate another set of eyes on my code to make sure
- I'm not doing something dangerous or just dumb :).
-
-Here's an overview of what I did:
-
-There were two function defined in common that handle sending messages
-to the user: log and loge. They both echo the argument passed to
-standard error. The first one also echo's "ms: " (as a preface to the
-message). loge was only called in two places and I think is left over
-cruft (let me know if I'm wrong please!).
-
-I've added drop in replacement functions: notice, info, and
-debug. I've replaced all instances of log and loge with info.
-
-If you use notice, your message will always be sent to standard error.
-If you use info, it will be sent to standard error if the env variable
-`MONKEYSPHERE_OUTPUT_QUIET` is set to off (it is off by default). If
-you use debug, it will be sent to standard error only if
-`MONKEYSPHERE_OUTPUT_DEBUG` is set to on (it's off by default).
-
-Lastly, in monkeysphere-ssh-proxycommand, I've set
-`MONKEYSPHERE_QUIET_MODE` to on by default.
-
-So the result is: when using monkeysphere-ssh-proxycommand, you will
-not get any output unless you set `MONEKYSPHERE_OUTPUT_QUIET` to off
-or `MONKEYSPHERE_OUTPUT_DEBUG` to on. All other commands should work
-exactly like they did in the past.
-
-And... we can go through the code and change calls to the info
-function to either notice (if we want them to be sent regardless of
-the `QUIET` variable) or debug (if we want it only sent if `DEBUG` is
-set).
-
-I'm open to suggestions, problems, etc :).
-
--- SJJ
-
-------
-
-Hey, your Royal Highness. I do think it's good that I look over these
-changes, because there are definitely some stuff (ie. key processing)
-that requires that things go to stderr and definitely not to stdout.
-I can see that if that were changed, it's possible that things could
-go wrong (ie. cause a `known_hosts` file to get truncated maybe).
-
-I have to say that I'm still not sure I totally see why it's necessary
-to implement such nuanced output switches. All of the stuff you were
-worried about when you reported this bug, and all the stuff that
-starts with "ms:", goes to stderr. If you didn't want to see it, can
-you not just redirect stderr to /dev/null?
-
-For what it's worth, I'm not sure *I* can ever imagine *not* wanting
-to see that stuff, since it effectively reports on whether the host
-you're connecting to is acceptable or not. I feel like I would always
-want to see that. I guess that's neither here nor there, though,
-cause if a user thinks it would be a good switch to have, and it's not
-too difficult to implement (as this is), then it's worth implementing.
-
-I think before we really start trying to tackle this, though, we
-should outline what is the behavior we ultimately want. What output
-do we want to go to stdout, and do we want to be able to turn that off
-or on? What output do we want to go to stderr, and do we want to be
-able to turn that off or on? At the moment, most output is really
-just info for the user, which is why I was sending it all to stderr.
-Should all output then just go to stderr, with a switch to either turn
-it off or on?
-
-I should point out that we're sort of hitting a bit of a bash
-limitation here. Some monkeysphere internal functions pass info on to
-other stuff via stdout, but also need to report stuff to the user as
-well, which means this stuff can only be passed to the user via
-stderr.
-
-In any event, I just want to outline a straightforward policy about
-output so we can know how to best handle it.
-
--- Big Jimmy.
-
------
-
-I think it's important to be able to suppress "normal operation,
-everything is fine" messages *without* directing stderr to
-`/dev/null`. This is the normal state of UNIX-style tools, especially
-tools like SSH which are used as piece of a larger toolchain. If
-every tool in a toolchain emitted some output during successful
-operation, many scripts would be hopeless seas of noise, as it's not
-unusual for even a simple backup script to make use of a half-dozen
-separate tools.
-
-What you really want is to see some output from when a tool knows
-something is wrong. With the proxycommand, the job of complaining
-will often be left up to `ssh` itself, after `~/.ssh/known_hosts` has
-been appropriately modified. But sometimes, the proxycommand itself
-will fail, and if you've already directed stderr to `/dev/null` you
-won't get any reasonable information about the failure at the time it
-happens.
-
-As for the interface to adjust the verbosity, HRH SJJ's current
-proposal with a large number of environment variables seems confusing
-and overly-complex to me.
-
-i think we should follow OpenSSH's lead (since all monkeysphere users
-are likely to be somewhat familiar with it) and use a single variable
-that is set to a level. For example, see `LogLevel` in
-`ssh_config(5)`. It should probably default to `INFO`, same as
-`/usr/bin/ssh`. If there was a way to extract this value from the
-user's SSH configuration/invocation itself and adopt it in the
-ProxyCommand, that would be even better, but i don't think that's a
-possibility with OpenSSH 5.1p1 at this point.
-
-Also, i agree with HRH SJJ that the distinction in the monkeysphere
-source between `log` and `loge` is unclear, and one of them should be
-dropped (or they should be better-documented in `/src/common`).
-
- --dkg
-
-----
-
-Thanks Big Jimmy and dkg all for the good feedback.
-
-I think you're right Big Jimmy about the sterr/stout. I may have
-accidentally output to stout instead of sterr. In any event - I think
-all of the logging should go to sterr to avoid that.
-
-Here's a proposed fix based on both of your responses - it tries to make
-my changes a bit simpler and more consistent with ssh behavior:
-
- * Use on environmental variable: `MONKEYSPHERE_LOG_LEVEL` that can be set
- to `ERROR` or `INFO`, with the default being `INFO`.
- `monkeysphere-ssh-proxycommand`, however, will set the
- `MONKEYSPHERE_LOG_LEVEL` to `ERROR` unless the user overrides that setting.
-
- * Use two functions for reporting messages to the user via sterr that
- will replace the existing log/loge functions: info (for outputting
- "normal operation, everything's fine" messages) and error (for
- outputting messages that indicate a problem that we think a user should
- know about). Reporting a message to the user with the info function
- will only be sent if the `MONKEYSPHERE_LOG_LEVEL` setting is `INFO`.
- Reporting a message to the user with the error function will always be
- output regardless of the `MONKEYSPHERE_LOG_LEVEL` value.
-
- * Go through the code and, for each use of the current log/loge
- function, determine if they should be replaced with info or error
- depending on how critical we think the message is.
-
-How does that sound?
-
- --Sir Jam Jam
-
------
-
-Sir Jam Jam's proposal sounds good to me, but why make it two separate
-functions? Given the number of log levels used by OpenSSH, i'd prefer
-to make a single function that takes two arguments: the first argument
-is the level of the log, and the second argument is the data to be
-logged itself. So you'd say:
-
- log error "This is really terrible and broken!"
- log info "The fuzzy bunny just smiled at you and nodded."
-
-Is that a reasonable amendment? It seems like it will make it easier
-to add more levels if we find we need them, and it makes it easy to
-find every single log message in the source code at the same time.
-
- --dkg
-
------
-
-I just implemented the proposal (incorporating dkg's suggestion about
-only having one function). It's committed in my quiet-mode branch (still
-not merged with master - pending review).
-
-Thanks for all the feedback!
-
--- SJJ
-
-----
-
-Ok, this plans makes sense. I'll merge SJJ's patches as soon as I get
-the chance.
-
--- BJ
-
-----
-
-I implemented a variant of SJJ's proposed changes in
-bb2427c28bf40179c4881b22c23f23f9bea78f55 (0.12 pre). I tried to make
-it so that we could more easily expand the number of levels if need
-be. I made a first pass at specifying which output is what priority,
-but folks should please speak up if they think the priority of any
-particular output should be changed.
-
-I'll leave the bug open for a bit until it get more tested and 0.12
-gets pushed out.
-
--- BJ
-
----
-
-I think this is [[/bugs/done]] as of version 0.12-1.
diff --git a/website/bugs/multiple-hostnames.mdwn b/website/bugs/multiple-hostnames.mdwn
deleted file mode 100644
index 9189ba8..0000000
--- a/website/bugs/multiple-hostnames.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!meta title="Support multiple host names for monkeysphere-enabled servers"]]
-
-Some monkeysphere-enabled hosts answer to multiple host names, but the
-current `monkeysphere-server` only generates a single User ID
-corresponding to a single hostname.
-
-We should make it easier for machines with multiple names to create
-multiple User IDs at `gen-key` time.
-
-We should also make it easy to add new hostnames (and remove outdated
-ones).
-
-For example: `george.riseup.net` is now also known as
-`monkeysphere.info`. It'd be nice to have a convenient way to add
-that hostname to the key without mucking around with gpg directly.
-
----
-
-So how do we imagine the behavior here? I assume that basically it
-would just add/remove user ID's to/from the host key locally. I guess
-we will continue to rely on the "publish-key" subcommand to actually
-publish all changes to the keys.
-
--- BJ (jgr)
-
----
-
-I think [when we reorganize the `monkeysphere-server`
-shortcuts](reorganize-monkeysphere-server-shortcuts) it'll make it
-clearer what the right interface should be.
-
-As for what should actually happen, i think that the server should
-actively revoke old User IDs, rather than removing them. It should
-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/posix_compliance.mdwn b/website/bugs/posix_compliance.mdwn
deleted file mode 100644
index d418e98..0000000
--- a/website/bugs/posix_compliance.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-It would be nice to make all of the Monkeysphere scripts POSIX
-compliant, for portability and light-weightedness. Better POSIX
-compliance would probably at least be better for compatibility with
-o{ther,lder} versions of bash. Unfortunately there are quite a few
-bashism at the moment, so this may not be trivial. For instance:
-
- servo:~/cmrg/monkeysphere/git 0$ checkbashisms -f src/monkeysphere-server 2>&1 | wc -l
- 50
- servo:~/cmrg/monkeysphere/git 0$
-
-It looks like the biggest complication for this would be the
-occasional use of bash arrays.
diff --git a/website/bugs/postinst-clobbers-gpg.conf-settings.mdwn b/website/bugs/postinst-clobbers-gpg.conf-settings.mdwn
deleted file mode 100644
index f7f2137..0000000
--- a/website/bugs/postinst-clobbers-gpg.conf-settings.mdwn
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!meta title="debian packaging postinst script clobbers gpg.conf settings in /var/lib/monkeysphere" ]]
-
-Do we want to allow the system administrator to make adjustments to
-the `gpg.conf` config files found in `/var/lib/monkeysphere`? At the
-moment, there are two such files:
-
- * `/var/lib/monkeysphere/gnupg-authentication/gpg.conf`
- * `/var/lib/monkeysphere/gnupg-host/gpg.conf`
-
-In the debian postinst scripts (`debian/monkeysphere.postinst`), the
-contents of those files are overwritten on every upgrade/reinstall,
-effectively clobbering any changes made by the local admin.
-
-Maybe we *do* want to do this clobbering, though. Stuff in `/var` is
-generally not expected to be modified by hand. I see two possible
-resolutions to this:
-
- * when we clobber those files, include a comment along the lines of:
- # do not make changes to this file! It is overwritten on each upgrade!
-
- * Avoid clobbering the files, and treat them as config files.
-
-the latter approach suggests that they should be more properly stored
-in `/etc/`, though. This would give us all the conf-file tracking
-apparatus, which is nice. If we do want to do that, I guess we'd
-symlink to them from the monkeysphere-specific `$GNUPGHOME`s in
-`/var/lib/monkeysphere`, since `gpg` does not seem to allow for
-overriding the location of the `gpg.conf` independent of `$GNUPGHOME`.
-
----
-
-All the gpg.conf files now reside in /etc/monkeysphere, and are linked
-in into the GNUPGHOMEs in /var/lib/monkeysphere.
-
-[[bugs/done]] on 2008-10-11
diff --git a/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn b/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn
deleted file mode 100644
index 02e23e5..0000000
--- a/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn
+++ /dev/null
@@ -1,121 +0,0 @@
-[[!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
-
-Here is an example when using monkeysphere-server
-add-identity-certifier on a host with a newly-installed monkeysphere
-installaton. Note that running the same command a second time works
-as expected:
-
- 0 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
- gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net
- gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
- gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied
- gpg: failed to rebuild keyring cache: file open error
- gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
- gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
- gpg: next trustdb check due at 2009-03-30
- gpg: Total number processed: 1
- gpg: imported: 1 (RSA: 1)
- Could not receive a key with this ID from the 'pool.sks-keyservers.net' keyserver.
- 255 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
- gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net
- gpg: key D21739E9: "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" not changed
- gpg: Total number processed: 1
- gpg: unchanged: 1
-
- key found:
- pub 4096R/D21739E9 2007-06-02 [expires: 2012-05-31]
- Key fingerprint = 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9
- uid [ unknown] Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- uid [ unknown] Daniel Kahn Gillmor <dkg@openflows.com>
- uid [ unknown] Daniel Kahn Gillmor <dkg@astro.columbia.edu>
- uid [ unknown] Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
- uid [ unknown] [jpeg image of size 3515]
- sub 2048R/4BFA08E4 2008-06-19 [expires: 2009-06-19]
- sub 4096R/21484CFF 2007-06-02 [expires: 2012-05-31]
-
- Are you sure you want to add the above key as a
- certifier of users on this system? (y/N) y
- gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
- gpg: Total number processed: 1
- gpg: imported: 1 (RSA: 1)
- gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
- gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
- gpg: next trustdb check due at 2009-03-30
- 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.
-
-
- pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC
- trust: unknown validity: unknown
- [ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- [ unknown] (2) Daniel Kahn Gillmor <dkg@openflows.com>
- [ unknown] (3) Daniel Kahn Gillmor <dkg@astro.columbia.edu>
- [ unknown] (4) Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
- [ unknown] (5) [jpeg image of size 3515]
-
-
- pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC
- trust: unknown validity: unknown
- Primary key fingerprint: 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9
-
- Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Daniel Kahn Gillmor <dkg@openflows.com>
- Daniel Kahn Gillmor <dkg@astro.columbia.edu>
- Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
- [jpeg image of size 3515]
-
- This key is due to expire on 2012-05-31.
- Please decide how far you trust this user to correctly verify other users' keys
- (by looking at passports, checking fingerprints from different sources, etc.)
-
- 1 = I trust marginally
- 2 = I trust fully
-
-
- Please enter the depth of this trust signature.
- A depth greater than 1 allows the key you are signing to make
- trust signatures on your behalf.
-
-
- Please enter a domain to restrict this signature, or enter for none.
-
-
- Are you sure that you want to sign this key with your
- key "ssh://pip.fifthhorseman.net" (9B83C17D)
-
- The signature will be marked as non-exportable.
-
-
- gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied
- gpg: failed to rebuild keyring cache: file open error
- gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
- gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
- gpg: depth: 1 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 1f, 0u
- gpg: next trustdb check due at 2009-03-30
-
- Identity certifier added.
- 0 pip:~#
diff --git a/website/bugs/reorganize-monkeysphere-server-shortcuts.mdwn b/website/bugs/reorganize-monkeysphere-server-shortcuts.mdwn
deleted file mode 100644
index c29a6f1..0000000
--- a/website/bugs/reorganize-monkeysphere-server-shortcuts.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta title="Reorganize monkeysphere-server shortcuts"]]
-
-Currently, `monkeysphere-server` supports three subcommands to adjust
-the "identity certifiers":
-
-* `add-identity-certifier` (`a`)
-* `remove-identity-certifier` (`r`)
-* `list-identity-certifier` (`l`)
-
-Since [we also want to be able to add/remove multiple
-hostnames](multiple-hostnames), i think we should change the shortcuts
-from `a`, `r`, and `l` to `c+`, `c-`, and `c`.
-
-This would let us create new subcommands like:
-
-* `add-host-name` (`n+`)
-* `revoke-host-name` (`n-`)
-* `list-host-names` (`n`)
-
----
-
-[[bugs/done]] 2008-08-14 in 0181b6fc50824941e4f7ac3f535a216b8189568e
diff --git a/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn b/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn
deleted file mode 100644
index 33224db..0000000
--- a/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn
+++ /dev/null
@@ -1,94 +0,0 @@
-[[!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/bugs/setup-subcommand-for-monkeysphere-server.mdwn b/website/bugs/setup-subcommand-for-monkeysphere-server.mdwn
deleted file mode 100644
index 99c6149..0000000
--- a/website/bugs/setup-subcommand-for-monkeysphere-server.mdwn
+++ /dev/null
@@ -1,56 +0,0 @@
-[[!meta title="proposed new monkeysphere-server subcommand: setup" ]]
-
-What if everything that's done in the package post-installation
-scripts (aside from maybe the creation of the monkeysphere user
-itself) was done with a single call to something like
-
- monkeysphere-server setup
-
-This would make things more obvious to folks installing from source
-directly, and put less maintenance load on porters. The end of
-`monkeysphere-server setup` could also invoke `monkeysphere-server
-diagnostics` to get the admin pointed in the right direction.
-
-Think of this as a sort of automated "Getting Started" documentation.
-
-Of course, a hypothetical *full* setup command would do things like
-`gen-key`, auto-modify `sshd_config`, etc. We wouldn't want to do
-those things automatically without the guiding hand of the local
-sysadmin.
-
-But perhaps we could even smooth that process with:
-
- monkeysphere-server setup --full
-
-I'd like to know what other folks think about these possibilities.
-Would either of these be useful? Are they confusing? Could they be
-clarified?
-
---dkg
-
----
-
-I'm not sure how I feel about this idea. I feel like it should just
-be the job of the package to setup the initial server environment. I
-don't really feel like the admin should have to worry about it. But
-then again, I can sort of see it from the point of view of someone
-just installing from source (but who the hell really does that
-anymore anyway?).
-
-I'm also sort of mixed about the setup --full idea as well. At first
-I thought that it wasn't a good idea, and that I didn't like the idea
-of monkeysphere monkeying around with the config files of other
-packages (ie. ssh). However, once I started to think about setting up
-monkeysphere on lots of servers, I started to think that it's maybe a
-good idea. It might be good to have a single command that would just
-end with the server being on the monkeysphere:
-
- * generate the server key
- * modify sshd to point to it
- * restart ssh
- * publish the key to the keyserver
-
-So I'm starting to think that this might be a good idea. Also curious
-what other think.
-
--- jrollins
diff --git a/website/bugs/setup-test-server-for-public.mdwn b/website/bugs/setup-test-server-for-public.mdwn
deleted file mode 100644
index 6df1fbf..0000000
--- a/website/bugs/setup-test-server-for-public.mdwn
+++ /dev/null
@@ -1,84 +0,0 @@
-[[!meta title="Setup test public server/gpg key"]]
-
-It would be really useful for people trying out the monkeysphere to be able to
-test it with a participating server as soon as they've finished setting things
-up. Minimally - just testing the acceptance of the server's identity would be
-great.
-
----
-
-I guess we don't really want to use george for this purpose? Does
-someone have a spare virtual machine that we could use for this
-purpose? The test machine wouldn't actually have to do any user
-authentication, I guess.
-
--- Big Jimmy.
-
----
-
-Maybe we should use George? As you point out - it doesn't actually
-have to do any user authentication. It seems like a waste to have a
-virtual machine that does nothing but deny people's ssh connections.
-And - george is already setup and ready to go.
--- Sir Jam Jam
-
----
-
-I like the idea of using George for this. There's nothing wrong with
-denying people's ssh connections. Also, we could make public user
-account with limited shells that we could add User IDs that we want to
-encourage to try out the monkeysphere from that perspective. For
-example, if one of the George admins who is listed as an
-identity-certifier has already certified Foo T. Bar's key, we could
-write a simple note like:
-
- Dear Foo T. Bar--
-
- The user account "foo@george.riseup.net" has been created for
- you. You can ssh into it by adding an authentication subkey
- to your OpenPGP key and publishing it to the public keyservers
- (or to george.riseup.net). The easiest way to do this is with
- the monkeysphere.
-
- You can verify george's ssh host key with the monkeysphere
- before you connect to the host. Here's how...
-
---dkg
-
----
-
-So do we agree that george is doing what we want, and we can therefore
-close this bug?
-
--- BJ (jgr)
-
----
-
-I'm fine with closing this bug, unless we want to set up the limited
-shell access/welcome letter like i described above. If we want to do
-that, it'd be worth keeping it open until those scripts are written.
-
-I envision a script you'd invoke like:
-
- root@george# addmsuser foo 'Foo T. Bar <foo@example.org>'
-
-Which would create the `foo` account, populate
-`~foo/.monkeysphere/authorized_user_ids`, make a note in a log
-someplace, and send a welcome letter.
-
---dkg
-
----
-
-That idea really seems like a lot more trouble than it's worth to me,
-and I'm not really willing to maintain it myself, but if someone else
-wants to handle that, that would be fine with me.
-
--- jgr
-
----
-
-i'm not really willing to maintain anything extra either, so i'm
-closing this ticket as [[bugs/done]].
-
---dkg
diff --git a/website/bugs/ssh-connection-refused-with-proxycommand.mdwn b/website/bugs/ssh-connection-refused-with-proxycommand.mdwn
deleted file mode 100644
index afd59f1..0000000
--- a/website/bugs/ssh-connection-refused-with-proxycommand.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-I added the following to my .ssh/config:
-
- Host *
- ProxyCommand monkeysphere-ssh-proxycommand %h %p
-
-So that the monkeysphere would be used for all my connections.
-
-However, I can no longer connect to any hosts. Here's example out put:
-
- 0 jamie@liberace:bugs$ ssh root@chavez.mayfirst.org
- ms: processing host: chavez.mayfirst.org
- ms: - key not found.
- ssh_exchange_identification: Connection closed by remote host
- 255 jamie@liberace:bugs$
-
-The server auth.log has nothing in it.
-
-------
-
-The problem was that the shebang line was `#!/bin/sh -e` instead of
-plain ol' `#!/bin/sh`
-
-[[bugs/done]] 2008-07-29 11:18:42-0400 (released in 0.6-1)
diff --git a/website/bugs/ssh_config_files_not_parsed.mdwn b/website/bugs/ssh_config_files_not_parsed.mdwn
deleted file mode 100644
index ca851a8..0000000
--- a/website/bugs/ssh_config_files_not_parsed.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-In `~/.ssh/config`, i have:
-
- HashKnownHosts No
-
-But when `monkeysphere-ssh-proxycommand` adds new hosts to
-`~/.ssh/known_hosts`, they appear to be added in a hashed form,
-instead of in the clear.
-
-fwiw: i'm using OpenSSH 5.1p1 on a debian lenny system (backported
-from sid)
-
----
-
-I can confirm this too (I'm running openssh-client 1:4.7p1-12)
-
--- Jamie (Jam Jam)
-
----
-
-There is absolutely no attempt by any monkeysphere utility to parse
-any ssh or sshd config file. This will probably need to be delt with
-down the line, but it's not a particular easy task at the moment.
-
--- Big Jimmy.
-
----
-
-I've [posted to the `openssh-unix-dev` list to see if there is a
-possibility of openssh making our lives easier
-here](http://marc.info/?l=openssh-unix-dev&m=121804767122918&w=2), but
-i haven't had much of a response yet.
-
---dkg
-
----
-
-For some reason this didn't get mentioned in this bug earlier, but
-there is a monkeysphere config variable about hashing known_hosts
-lines, which is set to true by default (to be in sync with the Debian
-openssh-client package).
-
-I think this bug is really more about the fact that monkeysphere does
-not parse the ssh config files for any directives relavent to what the
-monkeysphere is doing. I'm changing the name of this bug to reflect
-what the real issue is.
-
--- Big Jimmy.
diff --git a/website/bugs/use_getopts_instead_of_getopt.mdwn b/website/bugs/use_getopts_instead_of_getopt.mdwn
deleted file mode 100644
index 2ec68d6..0000000
--- a/website/bugs/use_getopts_instead_of_getopt.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-Since Monkeysphere is using bash, it would be nice to use the shell
-build in getopts function, instead of the external getopt program.
-This would reduce an external dependency, which would definitely be
-better for portability.
-
----
-
-So it looks like the sh built-in getopts does not include long options
-(eg. "--expire"). Is it worth getting rid of the long options for
-this?
-
----
-
-Why not just get rid of getopts altogether and perform a simple
-argument-processing loop with bash string tests? We're only invoking
-getopt in three places, and each invocation is no more complex than
-three arguments -- and most arguments take a separate parameter, which
-means that handling tricky arg blobs like -aCxr are not gonna be
-supported anyway.
diff --git a/website/bugs/useful_information.mdwn b/website/bugs/useful_information.mdwn
deleted file mode 100644
index 025d678..0000000
--- a/website/bugs/useful_information.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-I would like to know, at INFO (default) log level, when the
-monkeyspehere makes a "real" modification to my known\_hosts file; that
-is, when it adds or deletes a key.
-
-Apparently this is hard because monkeysphere is currently configured to
-delete all keys and then add good keys, so a key added for the first
-time seems to the monkeysphere very similar to a key re-added ten
-seconds after last login.
-
-Still, from a UI perspective, I want to know what monkeysphere is doing.
-
-------
-
-It looks like jrollins committed a change for reporting at INFO level
-when a host key gets added by the monkeysphere:
-2459fa3ea277d7b9289945748619eab1e3441e5c
-
-When i connect to a host whose key is not already present in my
-known_hosts file, i get the following to stderr:
-
- ms: * new key for squeak.fifthhorseman.net added to known_hosts file.
-
-This doesn't fully close this bug, because we aren't notifying on key
-deletion, afaict.
-
-------
-
-So current log level DEBUG will output a message if the known host
-file has been modified. If the issue is that you want to know at the
-default log level everytime the known\_hots file is modified, then we
-should just move this message to INFO instead of debug, and then maybe
-remove the message that I added above. I was under the impression
-that the issue was more about notification that a *new* key was added
-to the known\_hosts file, and therefore the new INFO message above
-fixed that problem. Should we do this instead?
-
-In general, more verbose log levels *do* tell the user what the
-monkeysphere is doing. Moving to DEBUG log level will tell you pretty
-much everything that happens. I do *not* think that this should be
-the default log level, though.
-
-------
-
-I wouldn't want to see an extremely verbose default log level. But i
-do think that saying something like "key blah blah blah was stripped
-from your known\_hosts file because it was expired" (for example)
-would be useful. I think this case would occur infrequently enough
-that it is worth reporting in the UI at the regular log level.
-
- --dkg
diff --git a/website/community.mdwn b/website/community.mdwn
deleted file mode 100644
index 13e9900..0000000
--- a/website/community.mdwn
+++ /dev/null
@@ -1,69 +0,0 @@
-[[!meta title="The Monkeysphere Community"]]
-
-# The Monkeysphere Community #
-
-## Mailing list ##
-
-The Monkeysphere project is a new project with just one mailing list
-at the moment. Its where we roll our sphere, discuss development
-issues, the project, and various complicated conundrums involving
-subjects around the web of trust.
-
-[Join us](https://lists.riseup.net/www/info/monkeysphere), we're a
-friendly bunch. You can also [look through our
-archives](https://lists.riseup.net/www/arc/monkeysphere) if you don't
-believe us.
-
-## Internet Relay Chat ##
-
-We're currently holding down an IRC channel on the `irc.oftc.net`
-network. You can find us in `#monkeysphere` if you prefer to
-communicate this way.
-
-## Development ##
-
-The Monkeysphere uses a distributed development model with
-[git](http://git.or.cz/). Once you've [installed
-git](http://www.spheredev.org/wiki/Git_for_the_lazy), you can [git
-clone](http://www.kernel.org/pub/software/scm/git/docs/git-clone.html)
-from this web site:
-
- git clone git://git.monkeysphere.info/monkeysphere
-
-If you would like to build a deb package from the latest release, you can type
-the following from inside the monkeysphere top level directory:
-
- make debian-package
-
-This command will build an upstream tarball, attach the debian packaging
-directory, and build a sample deb.
-
-If you want to help extend the scope of the Monkeysphere, take a look
-at our
-[list of environments that could make use of the project](/expansion).
-
-### Individual developer repositories ###
-
-You might also be interested in the repositories of individual
-developers, which may contain branches or features not yet in the main
-offering:
-
-[Daniel Kahn Gillmor](http://cmrg.fifthhorseman.net/wiki/dkg):
-
- git clone git://lair.fifthhorseman.net/~dkg/monkeysphere
-
-[Jameson Rollins](http://cmrg.fifthhorseman.net/wiki/jrollins):
-
- git clone git://lair.fifthhorseman.net/~jrollins/monkeysphere
-
-Micah Anderson:
-
- git clone git://labs.riseup.net/~micah/monkeysphere
-
-## Contact ##
-
-Please feel free to contact any of the Monkeysphere developers or post
-to the mailing list with questions, comments, bug reports, requests,
-etc. If you contact a developer individually, please indicate if
-there is any part of your note that can be made public (we might want
-to post it to the web here).
diff --git a/website/doc.mdwn b/website/doc.mdwn
deleted file mode 100644
index 3960893..0000000
--- a/website/doc.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-[[!meta title="Documentation"]]
-
-# Documentation #
-
-## Getting started ##
-
- * [Downloading and installing](/download)
- * Getting started as a [user](/getting-started-user)
- * Getting started as a [server admin](/getting-started-admin)
-
-## Going further ##
-
- * [Advanced Monkeysphere usage](/advanced-user)
- * [Signing host keys](/signing-host-keys)
- * [Understanding trust models](/trust-models)
-
-## Under the hood ##
-
- * [Developing the Monkeysphere](/community)
- * [Technical details](/technical-details)
-
-## References ##
-
- * [OpenSSH](http://openssh.com/)
- * [GnuPG](http://www.gnupg.org/)
- * [OpenPGP (RFC 4880)](http://tools.ietf.org/html/rfc4880)
- * [Secure Shell Authentication Protocol (RFC 4252)](http://tools.ietf.org/html/rfc4252)
- * [URI scheme for SSH, RFC draft](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/)
- * [Initial Monkeysphere specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH)
-
-## Other ##
-
- * [Similar Projects](/similar) (other attempts at a PKI for SSH)
- * [Mirroring the website](/mirrors)
diff --git a/website/download.mdwn b/website/download.mdwn
deleted file mode 100644
index 7ffa8ed..0000000
--- a/website/download.mdwn
+++ /dev/null
@@ -1,145 +0,0 @@
-[[!meta title="Download"]]
-
-# Downloading and Installing #
-
-Once you've installed the packages, please see the [documentation
-page](/doc) to read up on how to get started [as a regular
-user](/getting-started-user) or [as a systems
-administrator](/getting-started-admin).
-
-# Installing the Firefox/Iceweasel add-on #
-
-To use the Monkeysphere for website validation, you will need the
-Firefox/Iceweasel add-on, the monkeysphere package and the
-validation agent.
-
-[Download and install the Firefox/Iceweasel
-add-on](http://archive.monkeysphere.info/xul-ext/monkeysphere.xpi)
-
-Once you have installed the add-on, you will need to restart your
-browser, and then proceed to install the monkeysphere package and
-validation agent below.
-
-# Installing the Monkeysphere package and validation agent #
-
-## Dependencies ##
-
-Monkeysphere relies on:
-
- * [OpenSSH](http://openssh.com/)
- * [GnuPG](http://gnupg.org/)
- * [Perl](http://www.perl.org/) (including the [Crypt::OpenSSL::RSA](http://search.cpan.org/dist/Crypt-OpenSSL-RSA/) and [Digest::SHA](http://search.cpan.org/dist/Digest-SHA/) modules and their dependencies)
-
-## Debian ##
-
-If you are running a [Debian](http://www.debian.org/) system, the
-[monkeysphere is available in the Debian archive](http://packages.debian.org/search?keywords=monkeysphere&searchon=names&section=all&suite=all)
-
-If you are running Debian unstable or testing install the latest monkeysphere
-version as follows:
-
- aptitude install monkeysphere
-
-If you are running Debian stable, you can get the monkeysphere package
-from [backports.org](http://backports.org/dokuwiki/doku.php?id=instructions)
-
-To get started using the Monkeysphere for website validation, you will
-need to install the Monkeysphere Validation Agent. Currently the perl
-version of the agent is available in Debian sid, or directly from our
-APT repository (see below):
-
- aptitude install msva-perl
-
-## Debian derivatives (including Ubuntu) ##
-
-You can also install the Monkeysphere directly from the Monkeysphere
-APT repository. You can add this archive to your system by putting
-the following lines in `/etc/apt/sources.list.d/monkeysphere.list`:
-
- deb http://archive.monkeysphere.info/debian experimental monkeysphere
- deb-src http://archive.monkeysphere.info/debian experimental monkeysphere
-
-The repository is currently signed by [The Monkeysphere archive
-signing key](/archive-key), key id EB8AF314 (fingerprint: `2E8D D26C
-53F1 197D DF40 3E61 18E6 67F1 EB8A F314`). To cryptographically
-verify the packages, you'll want to [add this key to your apt
-configuration after verifying its integrity](/archive-key).
-
-Note: Ubuntu shipped Monkeysphere 0.22 in their "Jaunty Jackalope"
-release (9.04). The Monkeysphere developers think that [Ubuntu
-shipping Monkeysphere 0.22-1 is a bad
-idea](https://bugs.launchpad.net/ubuntu/+source/monkeysphere/+bug/345054).
-If you are an Ubuntu user, we would prefer that you install from the
-APT archive above rather than run 0.22, which we no longer consider
-supported.
-
-Ubuntu users running "Karmic Koala" (9.10) or later should see version
-0.26-1 or later in the standard Ubuntu universe repository, so please
-use the regular Ubuntu repositories if you're running Karmic or later.
-
-## FreeBSD ##
-
-There is [a FreeBSD port
-available](http://www.freebsd.org/cgi/ports.cgi?query=monkeysphere)
-for the Monkeysphere, built and tested against FreeBSD 7.1.
-
-You should be able to build and install the latest port with:
-
- cd /usr/ports/security/monkeysphere
- make package
-
-Enjoy!
-
-## Slackware ##
-
-Silvio Rhatto has made [a SlackBuild
-script](http://slack.sarava.org/slackbuilds/net/misc/monkeysphere/)
-for the Monkeysphere, tested against Slackware 12.2.
-
-This is generated by [the mkbuild system](http://simplepkg.sarava.org)
-from [its .mkbuild
-source](http://slack.sarava.org/mkbuilds/net/misc/monkeysphere/).
-
-Thanks, rhatto!
-
-## Source ##
-
-For those that would like to download the source directly, [the source
-is available](/community) via [git](http://git.or.cz/).
-
-The [latest
-tarball](http://archive.monkeysphere.info/debian/pool/monkeysphere/m/monkeysphere/monkeysphere_0.29.orig.tar.gz)
-is also available, and has these checksums:
-
-<pre>
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA512
-
-checksums for the monkeysphere 0.29 release:
-
-MD5:
-009e26cc77d38e25697cdea06eecd5ab monkeysphere_0.29.orig.tar.gz
-
-SHA1:
-db1074d6c5f424859ddec31cff0a0b6214789f16 monkeysphere_0.29.orig.tar.gz
-
-SHA256:
-0e3c683b7d8a07e6ceae80cb0d3acf647c3f8c74cbaab527f73608dcdd1b01fb monkeysphere_0.29.orig.tar.gz
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1.4.10 (GNU/Linux)
-
-iQIVAwUBS52/UhjmZ/HrivMUAQr98g/7B+6CCN9vrJFNZp2KX+jTcxBLRxY/2cJp
-fIjtaNzoyr86Q6gXzsgavB6E+olqhM3YR2gy6Z+fzNe8CdI74ikFCb0b8JpbzU6a
-F5et7RqQ/pkQrCawrVPTZnompqfJrWBPYZU5is85SJgX4jJrgUFrGbvTq2PsJDbC
-w9H8oOxELmCGYUAxRYGcQKdhQTBoRYz0a7/DzKt4sQHYbNblO1T2YNuqBxn372Wp
-bd8xholyfO6EjCfoEJPee8Uf1sxE4nhsYFYIHsuckqLbcdoE8crAmjeDdDt+yVCO
-N35Y/SRKNbIe/Nj8NSwAobd8N2DWj1qBWtHbT8Mw5kyd65kRPnfTQII5W0/3m3rT
-DwcXGsMMfOsPEMtAYfmGOaIdEH9y2O7tmV1Om2CGx0AV9F9F3RnyNlYB6mfVaUVO
-fZOJuUU61FoGRYCb/R4DF0IdFUhy0yMgTgT5tAYGMFpHd5ZTYgzIAWrIbV7QhrHs
-9LgrnJYffScHjjsE6NjjvOZQe9RrI25ZLHZEMo/zhZEMMzdIne8IZUXvz68v1wN9
-mLcGRMG8B1CT4gXyi1uy1he7Zw0Hmz2Kbq619alRmyV8CqNhNrvMQicRqklKvcuW
-mwKQx+bOxpwZgW4/46EDHJ4nUOaGjVXIwoDdisvKU5jDIMZBXB4lLJtPNFFsv18D
-AxOLE3KlzF0=
-=372c
------END PGP SIGNATURE-----
-</pre>
diff --git a/website/expansion.mdwn b/website/expansion.mdwn
deleted file mode 100644
index 662be86..0000000
--- a/website/expansion.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-[[!meta title="Expanding the Monkeysphere"]]
-
-# Expanding the Monkeysphere #
-
-The Monkeysphere currently has implementations that support two
-popular protocols in use on the internet today:
-
- * SSH: Monkeysphere supports the OpenSSH implementation of the Secure
- Shell protocol, for authenticating both hosts and users.
-
- * HTTPS: Monkeysphere supports secure web traffic by allowing users
- of Mozilla-based browsers (such as
- [Firefox](http://www.mozilla.com/en-US/firefox) or
- [Iceweasel](http://wiki.debian.org/Iceweasel)) to authenticate web
- sites that are not authenticated by the browser's built-in X.509
- verification. This should work with any HTTPS-capable web server.
-
-But there are many protocols and implementations on the 'net that
-could use the Monkeysphere for key-based authentication but currently
-do not. Here are some examples of places we think it could be useful.
-If you can help with these (or suggest others), please pitch in!
-
- * HTTPS client authentication: web servers should be able to
- authenticate clients that use asymmetric crypto. That is, the
- client holds an RSA secret key, offers a (potentially self-signed)
- X.509 Cert to the server as part of the TLS handshake, and the
- server verifies the key material and commonName or subjectAltName
- in the cert via the OpenPGP web of trust.
-
- * Other TLS connections: for example, SMTP services using STARTTLS
- (server-to-server and client-to-server), IMAP or POP daemons (using
- STARTTLS or a direct TLS wrapper), LDAP servers (or LDAPS), XMPP
- connections (client-to-server and server-to-server)
-
- * IRC connections: this could be at the TLS layer, or maybe via some
- exchange with the NickServ?
-
- * [OTR](http://www.cypherpunks.ca/otr) client-to-client handshakes.
-
- * Integration with
- [OpenPGP Certificates for TLS (RFC 5081)](http://tools.ietf.org/html/rfc5081)
- -- TLS clients or servers who receive an OpenPGP certificate from
- their peer should be able to ask some part of the Monkeysphere
- toolchain if the particular certificate is valid for the
- connection.
-
- * [PKINIT](http://tools.ietf.org/html/rfc4556) for
- [Kerberos](http://web.mit.edu/Kerberos/)
-
diff --git a/website/favicon.ico b/website/favicon.ico
deleted file mode 100644
index 13b5efc..0000000
--- a/website/favicon.ico
+++ /dev/null
Binary files differ
diff --git a/website/features.mdwn b/website/features.mdwn
deleted file mode 100644
index f676d1e..0000000
--- a/website/features.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-[[!meta title="Features"]]
-
-# Features #
-
diff --git a/website/getting-started-admin.mdwn b/website/getting-started-admin.mdwn
deleted file mode 100644
index ab0acc6..0000000
--- a/website/getting-started-admin.mdwn
+++ /dev/null
@@ -1,182 +0,0 @@
-Monkeysphere Server Administrator README
-========================================
-
- Note: This documentation is for Monkeysphere version 0.28 or later.
- If you are running a version prior to 0.28, we recommend that you upgrade.
-
-As the administrator of an SSH server, you can take advantage of the
-Monkeysphere in two ways:
-
-1. you can publish the host key of your machine to the Web of Trust
-(WoT) so that your users can automatically verify it, and
-
-2. you can set up your machine to automatically identify connecting
-users by their presence in the OpenPGP Web of Trust.
-
-These two pieces are independent: you can do one without the other.
-
-Monkeysphere for host verification (monkeysphere-host)
-======================================================
-
-Server host key publication
----------------------------
-
-To begin, you must first import an ssh host key. This assumes that
-you have the ssh server installed, and that you have generated a host
-RSA key. Once that has been done, import the key:
-
- # monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key ssh://server.example.net
-
-This will generate an OpenPGP certificate for the server. The primary
-user ID for this certificate will be the ssh service URI for the host,
-(e.g. `ssh://server.example.net`). Remember that the name you provide
-here should probably be a fully qualified domain name for the host in
-order for your users to find it.
-
-Now you can display information about the host key's certificate with
-the 'show-key' command:
-
- # monkeysphere-host show-key
-
-Once the host key's certificate has been generated, you'll probably
-want to publish it to the public keyservers which distribute the Web
-of Trust:
-
- # monkeysphere-host publish-key
-
-But anyone could publish a simple self-signed certificate to the WoT
-with any name attached. Your users should be able to tell that
-someone they know and trust with the machine (e.g. *you*, the
-administrator) has verified that this particular key is indeed the
-correct key. So your next step is to sign the host's key with your
-own OpenPGP key.
-
-On your (the admin's) local machine retrieve the host key (it may take
-several minutes for the key to propagate across the keyserver
-network), and sign it:
-
- $ gpg --search '=ssh://server.example.net'
- $ gpg --sign-key '=ssh://server.example.net'
-
-Make sure you compare the fingerprint of the retrieved certificate
-with the output from the 'show-key' command above!
-
-Next, find out your key's Key ID, which is a hexadecimal string like "ABCDEF19"
-
- $ gpg --list-keys '=ssh://server.example.net'
-
-which will output something like:
-
- pub 2048R/ABCDEF19 2009-05-07
- uid [ full ] ssh://server.example.net
-
-Finally, publish your signatures back to the keyservers, so that your
-users can automatically verify your machine when they connect:
-
- $ gpg --send-key ABCDEF19
-
-See http://web.monkeysphere.info/signing-host-keys/ for more info
-signing host keys.
-
-Monkeysphere for user authentication (monkeysphere-authentication)
-==================================================================
-
-A host can maintain ssh-style `authorized_keys` files automatically
-for its users with the Monkeysphere. This frees you (the
-administrator) from the task of manually checking/placing SSH keys,
-and enables users to do relatively painless key transitions, and to
-quickly and universally revoke access if they find that their ssh key
-has become compromised.
-
-You simply tell the system what *person* (identified by her OpenPGP
-User ID) should have access to an account, the Monkeysphere takes care
-of generating the proper `authorized_keys` file and keeping it
-up-to-date, and `sshd` reads the generated `authorized_keys` files
-directly.
-
-Monkeysphere authorized_keys maintenance
-----------------------------------------
-
-For each user account on the server, the userids of people authorized
-to log into that account would be placed, one per line, in:
-
- ~/.monkeysphere/authorized_user_ids
-
-For example, this file could contain:
-
- Joe User <joe@example.net>
- Joe User at Work <joe@example.org>
-
-Provided that those exact strings are among the uids for which the user's gpg
-key is valid.
-
-The server will use the Monkeysphere to look up matching OpenPGP
-certificates, validate them, and generate an `authorized_keys` file.
-
-To validate the OpenPGP certificates, the server needs to know who it
-can trust to correctly identify users. The individuals trusted to
-identify users like this are known in the Monkeysphere as "Identity
-Certifiers". One obvious choice is to trust *you*, the administrator,
-to be an Identity Certifier.
-
-You will need to know your full 40 hex character gpg fingerprint. This can be learned by doing:
-
- gpg --with-colons --fingerprint user@example.org
-
-Replacing "user@example.org" with either your gpg key id, or your gpg uid.
-The output of this command is very long and difficult to read. Look for a line like:
-
- fpr:::::::::D8E6414012D371BFC5AB8E2540D6B49E0E708ADF:
-
-The portion between the ":::::::::" and ":" is your 40 digit fingerprint.
-
-With your OpenPGP 40-digit hex fingerprint replacing `$GPGFPR`, then
-run the following command on the server:
-
- # monkeysphere-authentication add-identity-certifier $GPGFPR
-
-You'll probably only set up Identity Certifiers when you set up the
-machine. After that, you'll only need to add or remove Identity
-Certifiers when the roster of admins on the machine changes, or when
-one of the admins switches OpenPGP keys.
-
-Now that the server knows who to trust to identify users, the
-Monkeysphere can generate ssh-style `authorized_keys` quickly and
-easily:
-
-To update the Monkeysphere-generated `authorized_keys` file for user
-"bob", run:
-
- # monkeysphere-authentication update-users bob
-
-To update the monkeysphere `authorized_keys` file for all users on the
-the system, run the same command with no arguments:
-
- # monkeysphere-authentication update-users
-
-You probably want to set up a regularly scheduled job (e.g. with cron)
-to do this automatically.
-
-Update OpenSSH server AuthorizedKeysFile configuration
-------------------------------------------------------
-
-Generating the `authorized_keys` files is not quite enough, because
-`sshd` needs to know where to find the generated keys.
-
-
-You can do this by adding the following line to
-`/etc/ssh/sshd_config`, commenting out any other `AuthorizedKeysFile`
-directives.
-
- AuthorizedKeysFile /var/lib/monkeysphere/authorized_keys/%u
-
-Warning: Be aware that with this change in configuration, only those users whose
-authorized keys files appear under the above path will be able to log in via
-ssh. This includes the root user if root has ssh access. Remember to run
-'monkeysphere-authentication update-users' if you are unsure whether any users'
-authorized_keys files have been updated.
-
-You'll need to restart `sshd` to have your changes take effect. As
-with any change to `sshd_config`, if you're doing this remotely, be
-sure to retain an existing session to the machine while you test your
-changes so you don't get locked out if something went wrong.
diff --git a/website/getting-started-user.mdwn b/website/getting-started-user.mdwn
deleted file mode 100644
index 22a135f..0000000
--- a/website/getting-started-user.mdwn
+++ /dev/null
@@ -1,181 +0,0 @@
-Monkeysphere User README
-========================
-
- Note: This documentation is for Monkeysphere version 0.23 or later.
- If you are running a version prior to 0.23, we recommend that you upgrade.
-
-You don't have to be an OpenSSH or OpenPGP expert to use the
-Monkeysphere. However, you should be comfortable using secure shell
-(ssh), and you should already have an OpenPGP key before you begin.
-
-As a user, the Monkeysphere lets you do two important things:
-
-1. You can use the OpenPGP Web of Trust (WoT) to automatically verify
-the identity of hosts you connect to.
-
-2. You can manage your own ssh identity on all Monkeysphere-enabled
-servers using the WoT.
-
-These two features are independent: you can do one without the other.
-
-
-Identifying servers through the Web of Trust
-============================================
-
-The simplest way to identify servers through the Web of Trust is to
-tell `ssh` to use `monkeysphere ssh-proxycommand` to connect, instead
-of connecting to the remote host directly. This command will make sure
-the `known_hosts` file is up-to-date for the host you are connecting
-to with ssh.
-
-You can try this out when connecting to a server which has published
-their host key to the monkeysphere with:
-
- $ ssh -oProxyCommand='monkeysphere ssh-proxycommand %h %p' server.example.net
-
-If you want to have `ssh` always do this, just add the following line
-to the "Host *" section of your `~/.ssh/config` file:
-
- ProxyCommand monkeysphere ssh-proxycommand %h %p
-
-The "Host *" section specifies what ssh options to use for all
-connections. If you don't already have a "Host \*" line, you can add it
-by entering:
-
- Host *
-
-On a line by itself. Add the ProxyCommand line just below it.
-
-Note that the Monkeysphere will help you identify servers whose host
-keys are published in the WoT, and which are signed by people who you
-know and trust to identify such things!
-
-If you aren't connected to your administrator(s) through the Web of
-Trust, you should talk to them and establish that relationship. If
-you have already established that relationship, but a server's host
-key isn't published, you might suggest to your administrator that they
-publish it.
-
-
-Managing your SSH identity through the Web of Trust
-===================================================
-
-You've already got an OpenPGP identity in the Web of Trust. But you
-probably don't currently use it to identify yourself to SSH servers.
-
-To do that, you'll need to add an authentication-capable subkey to
-your OpenPGP identity. You can do that with:
-
- $ monkeysphere gen-subkey
-
-If you have more than one secret key, you'll need to specify the key
-you want to add the subkey to on the command line.
-
-Since this is a change to your key, you probably want to re-publish
-your key to the public keyservers. If your key ID is $GPGID:
-
- $ gpg --keyserver pool.sks-keyservers.net --send-key $GPGID
-
-This way, remote services that use the monkeysphere for user
-authentication will know about your SSH identity.
-
-You may need to wait a few minutes for your new key to propagate
-around the keyserver network, and another little while for any remote
-host running the monkeysphere to pick up the new subkey.
-
-
-Using your OpenPGP authentication key for SSH via ssh-agent(1)
---------------------------------------------------------------
-
-Once you have created an OpenPGP authentication subkey, you will need
-to feed it to your `ssh-agent`. Your agent can then manage the key
-for all of your ssh sessions.
-
-First make sure you have an agent running:
-
- $ ssh-add -l
-
-Then hand off the authentication subkey to the agent:
-
- $ monkeysphere subkey-to-ssh-agent
-
-You can supply normal ssh-add(1) flags to this command if you want to
-give the agent different instructions. For example, if you want the
-agent to always ask for confirmation before using this key, you should
-do this instead:
-
- $ monkeysphere subkey-to-ssh-agent -c
-
-You can verify that the key is in the agent just as you normally
-would:
-
- $ ssh-add -l
-
-Now you can connect to hosts that use the monkeysphere for user
-authentication using that key:
-
- $ ssh server.example.net
-
-
-Using your OpenPGP authentication key for SSH without the agent
----------------------------------------------------------------
-
-Currently, the monkeysphere does not support using your SSH subkey
-without the ssh-agent :( It's not impossible, we just haven't gotten
-around to it yet. Patches are welcome!
-
-If you are not running an agent, and you just want a single session
-with the key, you could cobble something together a one-shot agent
-like this:
-
- $ ssh-agent sh -c 'monkeysphere subkey-to-ssh-agent && ssh server.example.net'
-
-Maintenance
-===========
-
-As a regular user of the monkeysphere, you probably want to do a few
-things to make sure that you get automatically notified of any
-re-keyings or revocation of monkeysphere-enabled hosts, and that your
-keys are properly managed.
-
-
-Keep your keyring up-to-date
-----------------------------
-
-Regularly refresh your GnuPG keyring from the keyservers. This can be
-done with a simple cronjob. An example of crontab line to do this is:
-
- 0 12 * * * /usr/bin/gpg --refresh-keys > /dev/null 2>&1
-
-This would refresh your keychain every day at noon.
-
-
-Keep your SSH identity up-to-date
----------------------------------
-
-If your SSH identity or your whole OpenPGP keyring is compromised, you
-should be sure to revoke it and publish the revocations to the
-keyserver. If only your SSH identity was compromised, you should just
-revoke the authentication subkey. For keys with small sizes, or which
-may have been otherwise compromised, you may wish to simply revoke the
-old authentication subkey, add a new one, and publish those changes to
-the public keyservers together.
-
-Many people believe that it is good security practice to only use
-asymmetric keys (such as the RSA keys used by SSH and the
-Monkeysphere) for a limited period of time, and prefer to transition
-from key to key every year or two.
-
-Without the monkeysphere, you would have needed to update your
-`authorized_keys` file on every host you connect to in order to effect
-such a transition. But all hosts that use the Monkeysphere to
-generate their authorized keys files will transition automatically to
-your new key, if you publish/revoke as described above.
-
-
-For those who want more
-=======================
-
-More documentation and details are available on the web at:
-
- http://web.monkeysphere.info/
diff --git a/website/index.mdwn b/website/index.mdwn
deleted file mode 100644
index bb74fa1..0000000
--- a/website/index.mdwn
+++ /dev/null
@@ -1,82 +0,0 @@
-[[!meta title="The Monkeysphere Project"]]
-[[!meta license="Unless otherwise noted, all content on this web site is licensed under the GPL version 3 or later"]]
-[[!meta copyright="All content on this web site is copyright by the author of that content. [Look in the revision control system](community) for details about who authored a particular piece of content."]]
-
-# The Monkeysphere Project #
-
-The Monkeysphere project's goal is to extend OpenPGP's web of trust to
-new areas of the Internet to help us securely identify each other
-while we work online.
-
-Specifically, monkeysphere currently offers a framework to leverage
-the OpenPGP web of trust for OpenSSH authentication.
-
-In other words, it allows you to use secure shell as you normally do,
-but to identify yourself and the servers you administer or connect to
-with your OpenPGP keys. OpenPGP keys are tracked via GnuPG, and
-monkeysphere manages the `known_hosts` and `authorized_keys` files
-used by OpenSSH for authentication, checking them for cryptographic
-validity.
-
-## Overview ##
-
-Everyone who has used secure shell is familiar with the prompt given
-the first time you log in to a new server, asking if you want to trust
-the server's key by verifying the key fingerprint. Unfortunately,
-unless you have access to the server's key fingerprint through a
-secure out-of-band channel, there is no way to verify that the
-fingerprint you are presented with is in fact that of the server
-you're really trying to connect to.
-
-Many users also take advantage of OpenSSH's ability to use RSA or DSA
-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 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
-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.
-
-The basic idea of the Monkeysphere is to create a framework that uses
-[GnuPG](http://www.gnupg.org/)'s keyring manipulation capabilities and
-public keyserver communication to manage the keys that OpenSSH uses
-for connection authentication.
-
-The Monkeysphere therefore provides an effective PKI for OpenSSH,
-including the possibility for key transitions, transitive
-identifications, revocations, and expirations. It also actively
-invites broader participation in the
-[OpenPGP](http://en.wikipedia.org/wiki/Openpgp) [web of
-trust](http://en.wikipedia.org/wiki/Web_of_trust).
-
-Under the Monkeysphere, both parties to an OpenSSH connection (client
-and server) explicitly designate who they trust to certify the
-identity of the other party. These trust designations are explicitly
-indicated with traditional GPG keyring trust models. Monkeysphere
-then manages the keys in the `known_hosts` and `authorized_keys` files
-directly, in such a way that is completely transparent to `ssh`. No
-modification is made to the SSH protocol on the wire (it continues to
-use raw RSA public keys), and no modification is needed to the OpenSSH
-software.
-
-To emphasize: ***no modifications to SSH are required to use the
-Monkeysphere***. OpenSSH can be used as is; completely unpatched and
-"out of the box".
-
-## License ##
-
-All Monkeysphere software is copyright, 2007-2010, by [the
-authors](community), and released under [GPL, version 3 or
-later](http://www.gnu.org/licenses/gpl-3.0.html).
-
-----
-
-This wiki is powered by [ikiwiki](http://ikiwiki.info).
diff --git a/website/local.css b/website/local.css
deleted file mode 100644
index 4a2d992..0000000
--- a/website/local.css
+++ /dev/null
@@ -1,134 +0,0 @@
-/* CSS for web.monkeysphere.info
-
-Copyright: 2008,2009
-
-Authors:
-Dan Scott,
-Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
-Jameson Rollins <jrollins@finestructure.net>,
-Jamie McClelland <jm@mayfirst.org>
-
-License: This stylesheet is licensed under the GNU GPL, version 3 or
-later (your choice).
-
-The full text of the GPL can be found at:
-
- http://www.gnu.org/licenses/gpl.html
-
- */
-
-h1 {
- -moz-border-radius: 4px;
- background-color: #B67B4E;
- color: black;
- display: block;
- font-weight: bold;
- padding: 0 0 0 10px;
- font-size: 1.4em;
-}
-
-h2 {
- -moz-border-radius: 4px;
- background-color: #B67B4E;
- color: black;
- display: block;
- font-weight: bold;
- padding: 0 0 0 10px;
- font-size: 1.1em;
-}
-
-body {
- color: #3F403F;
- font-family: "Liberation Sans",sans-serif;
- font-size: 0.95em;
-}
-
-*|*:visited {
- color: #f6a464;
-}
-
-*|*:-moz-any-link {
- text-decoration: none;
-}
-
-:-moz-any-link {
- cursor: pointer;
-}
-
-a:link {
- color: #CC6600;
- text-deoration: none;
-}
-
-a:visited {
- color: #c2772b;
-}
-
-a:hover {
- text-decoration: underline;
-}
-
-pre {
- background: #ddd;
- border: 1px solid #aaa;
- padding: 3px 3px 3px 3px;
- margin-left: 38px;
- margin-right: 5em;
- overflow: auto;
-}
-
-table.sitenav {
- border-bottom: 2px solid black;
- padding: 0px;
- width: 100%;
- font-size: larger;
-}
-
-table.sitenav img.logo {
- margin: 0em;
- padding: 0px;
- vertical-align: bottom;
-}
-
-table.sitenav img.title {
- margin: 0px;
- padding: 0px;
- vertical-align: top;
-}
-
-table.sitenav a {
- font-weight: bold;
- margin-right: 1em;
- font-size: smaller;
-}
-
-table.sitenav span.selflink {
- font-weight: bold;
- text-decoration: underline;
- margin-right: 1em;
- font-variant: small-caps;
-}
-
-div.header {
- text-align: right;
- display: none;
-}
-
-div.actions {
- text-align: right;
- display: none;
-}
-
-#sidebar {
- line-height: normal;
- width: 100%;
- float: none;
- margin: 0;
- padding: 0;
-}
-
-/* align main paragraphs to the right side of the monkey's finger */
-div#content > p {
- margin-left: 18px;
- margin-right: 5em;
-}
diff --git a/website/logo.png b/website/logo.png
deleted file mode 100644
index 33b3e78..0000000
--- a/website/logo.png
+++ /dev/null
Binary files differ
diff --git a/website/logo.simple.png b/website/logo.simple.png
deleted file mode 100644
index 5cc69eb..0000000
--- a/website/logo.simple.png
+++ /dev/null
Binary files differ
diff --git a/website/logo.title.png b/website/logo.title.png
deleted file mode 100644
index a203f8b..0000000
--- a/website/logo.title.png
+++ /dev/null
Binary files differ
diff --git a/website/mirrors.mdwn b/website/mirrors.mdwn
deleted file mode 100644
index 74d30c3..0000000
--- a/website/mirrors.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-[[!meta title="Mirroring the Monkeysphere web site"]]
-
-# Mirroring the Monkeysphere web site #
-
-In keeping with the distributed philosophy of distributed development, our web site is
-stored in our git repositories and converted into html by
-[ikiwiki](http://ikiwiki.info/).
-
-We're mirrored on several servers. Rather than using ikiwiki's [pinger/pingee
-approach to distribution](http://ikiwiki.info/tips/distributed_wikis/), we've
-opted for a simpler rsync of the ikiwiki-produced html files.
-
-## Initial steps to take on the mirror server ##
-
-Create a new user.
-
-Add web site configuration that the user has write access to. If you are
-using Apache, include the following rewrite:
-
- RewriteEngine On
- RewriteCond %{HTTP_HOST} !^(YOURHOSTNAME|web)\.monkeysphere\.info$ [NC]
- RewriteCond %{HTTP_HOST} !^$
- RewriteRule ^/(.*) http://web.monkeysphere.info/$1 [L,R]
-
-Add `webmaster@george`'s public key to this user's
-`~/.ssh/authorized_keys` file, restricting that user to rsync (modify
-path to web directory as needed):
-
- command="/usr/bin/rsync --server -vlogDtprz --delete . web/",no-pty,no-agent-forwarding,no-port-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0SCD6tAh7g1yyuelIm5zyh5OFX89NNbpNzyp+BxXNxMc/C1BS9SN5KlNDT30WdDbw3X0St0dBBC69TZWYbSUn4+/6BNmYpLH2orhedBv4w2jBLmtVEfnMWa3a11CnIagMEkEz7rBIWpl76WOqzoueQbAAa/7GziVmv+2qdjcDFxHluO+VL/+gEw8BqZc587oiDYkIw3oBnOLaxUWDtaMFKiL8sgdBmPxzc8PgHxL5ezVDJExw5krR4FK7hG7KpBOlSwKQPFy2pPhHSb1ZuFJmp2kr2wfJ0RO7By5s/GbrkJbnGoiJ5W0fUC9YoI82U3svC5saowvoSo19yToJW4QUw== webmaster@george
-
-## Admin steps to take to enable the configuration ##
-
-Add a new dns record for SERVERNAME.monkeysphere.info.
-
-If the mirror server is not participating in the monkeysphere, add the
-server to webmaster's known host file.
-
-Add the new server to `webmaster@george:~/mirrors` in the format:
-
- username@server:directory
-
-Test by manually running the git post-receive hook as
-`webmaster@george`:
-
- ~/monkeysphere.git/hooks/post-receive
-
-Add a new `A` record into the `web.monkeysphere.info` round robin.
diff --git a/website/news.mdwn b/website/news.mdwn
deleted file mode 100644
index 87fc861..0000000
--- a/website/news.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!meta title="News"]]
-
-# News #
-
-Here are the latest announcements about the Monkeysphere.
-
-[[!inline pages="./news/* and !*/Discussion" rootpage="news" show="30"]]
diff --git a/website/news/0.24-accepted-in-Debian-testing.mdwn b/website/news/0.24-accepted-in-Debian-testing.mdwn
deleted file mode 100644
index dd3fcdd..0000000
--- a/website/news/0.24-accepted-in-Debian-testing.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!meta title="Monkeysphere 0.24 accepted in Debian testing"]]
-
-[Monkeysphere 0.24 is now available in the Debian testing distribution
-("squeeze")](http://packages.debian.org/testing/monkeysphere).
-Monkeysphere 0.24 is our strongest release yet. If you are running
-Debian testing, installing the monkeysphere is now very easy:
-
- aptitude install monkeysphere
-
-See the [[download]] page for more information.
diff --git a/website/news/0.24-available-in-Backports-org.mdwn b/website/news/0.24-available-in-Backports-org.mdwn
deleted file mode 100644
index 989bb12..0000000
--- a/website/news/0.24-available-in-Backports-org.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!meta title="Monkeysphere 0.24 accepted as a Debian Backport"]]
-
-[Monkeysphere 0.24 is now available at [Backports.org](http://backports.org).
-If you are running Debian stable ("Lenny"), you can install this version
-of the monkeysphere package by following the [instructions for installing
-backports](http://backports.org/dokuwiki/doku.php?id=instructions).
-
-See the [[download]] page for more information.
diff --git a/website/news/FreeBSD-0.24-port-accepted.mdwn b/website/news/FreeBSD-0.24-port-accepted.mdwn
deleted file mode 100644
index 1681cc5..0000000
--- a/website/news/FreeBSD-0.24-port-accepted.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!meta title="FreeBSD 0.24 port accepted"]]
-
-FreeBSD's ports tree now contains [a port of the
-Monkeysphere](http://www.freebsd.org/cgi/ports.cgi?query=monkeysphere),
-version 0.24. If you run FreeBSD, [update your ports
-tree](http://www.freebsd.org/doc/en/books/handbook/ports-using.html),
-and then:
-
- cd /usr/ports/security/monkeysphere
- make package
-
diff --git a/website/news/FreeBSD-port-available.mdwn b/website/news/FreeBSD-port-available.mdwn
deleted file mode 100644
index 08d28c5..0000000
--- a/website/news/FreeBSD-port-available.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-[[!meta title="FreeBSD port available"]]
-
-Update: [FreeBSD's official ports tree now contains monkeysphere
-0.24](FreeBSD-0.24-port-accepted).
-
-There is now a FreeBSD port available for the Monkeysphere.
-
-It has been built and tested (so far) on a FreeBSD 7.1 AMD64 system,
-installed from the [BETA2
-ISOs](ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/7.1/). Many
-thanks to [Anarcat](http://anarcat.ath.cx/pgp) for his work in pulling
-this port together!
-
-While the monkeysphere is not officially included in the ports tree
-yet, [a problem
-report](http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128406) has
-been submitted, and the package itself is functional.
-
-The latest version of the ports directory can be found in [the git
-repository](/community) under
-`packaging/freebsd/security/monkeysphere`. Please [let us
-know](/community) if you encounter any problems with it on a FreeBSD
-system.
-
-If you have git installed on your FreeBSD system, you should be able
-to build the latest port with:
-
- git clone git://git.monkeysphere.info/monkeysphere
- cp -a monkeysphere/packaging/freebsd/security/monkeysphere /usr/ports/security
- cd /usr/ports/security/monkeysphere
- make && make install
-
-Happy Hacking!
-
diff --git a/website/news/Monkeysphere-in-Debian.mdwn b/website/news/Monkeysphere-in-Debian.mdwn
deleted file mode 100644
index 04843df..0000000
--- a/website/news/Monkeysphere-in-Debian.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta title="Monkeysphere now in Debian!"]]
-
-[The Monkeysphere has made it into
-Debian!](http://packages.debian.org/sid/monkeysphere)
-
-It is in Debian unstable ("sid") now, which means it won't make it
-into the next stable release ("lenny"), but hopefully will make it
-into the stable release after that ("squeeze").
-
-Congratulations to all the work by all the [monkeysphere
-developers](/community), and to Micah Anderson for being our Debian
-sponsor.
-
-Please feel free to start submitting bug reports to the [Debian
-BTS](http://bugs.debian.org/monkeysphere).
diff --git a/website/news/apt-repo-moved.mdwn b/website/news/apt-repo-moved.mdwn
deleted file mode 100644
index a56dccf..0000000
--- a/website/news/apt-repo-moved.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta title="APT repository moved"]]
-
-The monkeysphere APT repository has been moved from
-`http://monkeysphere.info/debian` to
-`http://archive.monkeysphere.info/debian`. You'll probably want to
-update your `sources.list` to match the [official lines](/download).
-
-The monkeysphere APT repository is also using [a new archive signing
-key](/archive-key):
-
- pub 4096R/EB8AF314 2008-09-02 [expires: 2009-09-02]
- Key fingerprint = 2E8D D26C 53F1 197D DF40 3E61 18E6 67F1 EB8A F314
- uid [ full ] Monkeysphere Archive Signing Key (http://archive.monkeysphere.info/debian)
-
-Apologies for any confusion or hassle this causes!
diff --git a/website/news/git-repo-moved.mdwn b/website/news/git-repo-moved.mdwn
deleted file mode 100644
index e4fa2f5..0000000
--- a/website/news/git-repo-moved.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!meta title="git repository moved"]]
-
-The monkeysphere git repository has been moved from
-`git://monkeysphere.info/monkeysphere` to
-`git://git.monkeysphere.info/monkeysphere`. You'll probably want to
-update your `.git/config` to match the [official clone
-target](/community).
-
-Apologies for any confusion or hassle this causes!
diff --git a/website/news/gnutls-2.6-enables-monkeysphere.mdwn b/website/news/gnutls-2.6-enables-monkeysphere.mdwn
deleted file mode 100644
index 756bc9e..0000000
--- a/website/news/gnutls-2.6-enables-monkeysphere.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!meta title="GnuTLS 2.6.x enables Monkeysphere to read authentication subkeys"]]
-
------
-
-**2009-04-05 UPDATE:** Since Monkeysphere no longer depends on GnuTLS
-at all ([moved to using Perl for key
-translation](news/release-0.24-1)), and GnuTLS 2.6 is now available in
-Debian testing, we have removed the GnuTLS patches from the repostiory
-(although they will continue to be available in the history, or
-course).
-
------
-
-We [announced earlier](/news/modified-gnutls-2.4.x-available) that the
-Monkeysphere project was providing patched versions of GnuTLS to
-support one piece of Monkeysphere functionality. Fortunately, those
-patches are no longer needed, because as of [version
-2.6](http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3135),
-GnuTLS contains the necessary functionality natively.
-
-Therefore, our project will no longer provide patched copies of
-GnuTLS, though we will continue to keep the patch alive in in [our git
-repository](/community) until GnuTLS 2.6 has been more widely adopted.
-
-If you were pulling patched versions of GnuTLS 2.4 from the
-Monkeysphere archive, you may prefer to pull GnuTLS 2.6 from [debian's
-experimental archive](http://wiki.debian.org/DebianExperimental) (at
-least until it GnuTLS 2.6 drops into unstable, which should happen
-shortly after the release of
-[lenny](http://wiki.debian.org/DebianLenny).
diff --git a/website/news/mailing-list.mdwn b/website/news/mailing-list.mdwn
deleted file mode 100644
index c0f7696..0000000
--- a/website/news/mailing-list.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-# The monkeysphere has a mailing list! #
-
-We've been working with a relatively bulky CC list since the inception
-of the monkeysphere concept, but we now have a
-[mailing-list!](http://lists.riseup.net/www/info/monkeysphere) It even
-has [archives!](https://lists.riseup.net/www/arc/monkeysphere)
-
-We started off with this CC list because we were interested in
-exploring distributed models of collaboration, communication and
-organization. Using the [git VCS](http://git.or.cz/) we were able to
-set up our development infrastructure to be totally distributed, but
-we soon realized that other aspects of the monkeysphere project needed
-to be accessible to the public, such as a project home page (although
-we could setup a system to distribute that), and a mailing list that
-people other than us could join and browse the archives (we've got
-some interesting ideas here too)...
-
-So, although our all-distributed model has cracked a bit, it's mostly
-for want of tools to facilitate the process, and although we are eager
-to explore the mechanisms to make these things happen, we didn't want
-to keep the monkeysphere back while we did so.
-
diff --git a/website/news/modified-gnutls-2.4.x-available.mdwn b/website/news/modified-gnutls-2.4.x-available.mdwn
deleted file mode 100644
index 4d481d7..0000000
--- a/website/news/modified-gnutls-2.4.x-available.mdwn
+++ /dev/null
@@ -1,66 +0,0 @@
-[[!meta title="Modified GnuTLS 2.4.x available"]]
-
------
-
-**2008-10-25 UPDATE:** [GnuTLS 2.6 has been released, and it contains the
-functionality we needed](/news/gnutls-2.6-enables-monkeysphere).
-Please upgrade to GnuTLS 2.6 if you need Monkeysphere to deal with
-passphrase-protected authentication subkeys. The information on this
-page is now of historical interest only.
-
------
-
-The MonkeySphere project is now making available a patched version of
-[GnuTLS](http://gnutls.org/) version 2.4.x, which enhances the utility
-of the `monkeysphere` package by enabling it to read authentication
-subkeys emitted by [GnuPG](http://gnupg.org/) under certain
-circumstances.
-
-You can track this package in debian lenny by adding the following
-lines to `/etc/apt/sources.list`:
-
- deb http://archive.monkeysphere.info/debian experimental gnutls
- deb-src http://archive.monkeysphere.info/debian experimental gnutls
-
-Or you can patch and build the packages yourself with the patches and
-scripts provided in [the MonkeySphere git repo](/download).
-
-The only modification needed simply enables the library to parse a GNU
-extension to the String-to-key (S2K) mechanism as laid out in [RFC
-4880](http://tools.ietf.org/html/rfc4880#section-3.7).
-
-The specific S2K extension supported is known as gnu-dummy, and it
-simply allows a "secret" key block to be written *without* storing any
-of the secret key material. This is used by GnuPG on the primary key
-when the `--export-secret-subkeys` argument is given.
-
-GnuPG's [DETAILS
-file](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/DETAILS?root=GnuPG)
-describes this extension this way:
-
- GNU extensions to the S2K algorithm
- ===================================
- S2K mode 101 is used to identify these extensions.
- After the hash algorithm the 3 bytes "GNU" are used to make
- clear that these are extensions for GNU, the next bytes gives the
- GNU protection mode - 1000. Defined modes are:
- 1001 - do not store the secret part at all
- 1002 - a stub to access smartcards (not used in 1.2.x)
-
-And [`gpg(1)`](http://linux.die.net/man/1/gpg) says of `--export-secret-subkeys`:
-
-
- [This] command has the special property to render the secret
- part of the primary key useless; this is a GNU extension to
- OpenPGP and other implementations can not be expected to
- successfully import such a key.
-
-A version of this patch was first proposed [on
-`gnutls-dev`](http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html),
-and looks like it will be adopted upstream in the GnuTLS 2.6.x series,
-at which point these packages will be unnecessary.
-
-Until that time, these packages are provided to tide over users of
-`monkeysphere` on debian lenny (or compatible systems) who want to be
-able to hand off the authentication-capable OpenPGP subkeys in their
-GnuPG keyring to their SSH agent.
diff --git a/website/news/msva-perl-0.2.mdwn b/website/news/msva-perl-0.2.mdwn
deleted file mode 100644
index cb01bb8..0000000
--- a/website/news/msva-perl-0.2.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta title="Monkeysphere Validation Agent (Perl) 0.2 released!"]]
-
-Version 0.2 of the Perl implementation of the Monkeysphere Validation
-Agent has been released.
-
-Notes from the changelog:
-
-<pre>
- * can now be invoked with a sub-command; will run until subcommand
- completes, and then terminate with the same return code (this is
- similar to the ssh-agent technique, and enables inclusion in
- Xsession.d; see monkeysphere 0.29 package for automatic startup).
- * chooses arbitrary open port by default (can still be specified with
- MSVA_PORT environment variable)
- * minimized logging spew by default.
- * now shipping README.schema (notes about possible future MSVA
- implementations)
- * cleanup Makefile and distribution strategies.
-</pre>
-
diff --git a/website/news/plans-for-the-bezoar.mdwn b/website/news/plans-for-the-bezoar.mdwn
deleted file mode 100644
index ce061ee..0000000
--- a/website/news/plans-for-the-bezoar.mdwn
+++ /dev/null
@@ -1,45 +0,0 @@
-[[!meta title="Plans for The Golden Bezoar"]]
-
-A workday with several Monkeysphere contributors on 2009-01-31
-resulted in a significant reorganization of the project in several
-areas, primarily driven by the realization that there are two
-fundamentally different concepts on the server side:
-
-* publishing host keys via the Web-of-Trust (WoT), and
-* authenticating users via the WoT.
-
-For simplicity and clarity, those two concepts should be independent
-from each other, but earlier releases of the Monkeysphere tangled the
-two up together more than we probably should have.
-
-So the next release, version 0.23 (a.k.a. *The Golden Bezoar*) will
-have the following significant changes:
-
-* __user interface__: `/usr/sbin/monkeysphere-server` is no more, and
- its functionality will be split out into
- `/usr/sbin/monkeysphere-host` (for functionality dealing with
- publishing the ssh host key through the WoT) and
- `/usr/sbin/monkeysphere-authentication` (for functionality dealing
- with authenticating users via the
- WoT). `/usr/bin/monkeysphere-ssh-proxycommand` has been folded into
- `/usr/bin/monkeysphere` itself as a new subcommand.
-
-* __code__: the subfunctions are now stored in their own separate
- files, and sourced as-needed by the three top-level commands. The
- test suite has also been re-written to reflect the above UI changes.
-
-* __documentation__: in addition to making the man pages reflect the
- above UI changes, we're rewriting the "getting started"
- [documentation](/doc/) to use the conceptually-cleaner distinctions
- above.
-
-* __data storage__: `/var/lib/monkeysphere` itself has been
- re-organized with the aim of keeping the host/authentication
- distinction clear, simplifying the internal use of `gpg`, and
- facilitating privilege-separated access.
-
-*The Golden Bezoar* will also feature the ability to painlessly
-publish your current ssh host key to the WoT without needing to re-key
-the server. If you're considering adopting the Monkeysphere in the
-near future, we recommend waiting for 0.23 to be released, as it
-should be conceptually clearer and easier to use.
diff --git a/website/news/release-0.10-1.mdwn b/website/news/release-0.10-1.mdwn
deleted file mode 100644
index e70b0a8..0000000
--- a/website/news/release-0.10-1.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-[[!meta title="MonkeySphere 0.10-1 released!"]]
-
-# MonkeySphere 0.10-1 released! #
-
-MonkeySphere 0.10-1 has been released. This is a bugfix-only release,
-fixing an critical inverted test in 0.9-1. [[download]] it now!
diff --git a/website/news/release-0.11-1.mdwn b/website/news/release-0.11-1.mdwn
deleted file mode 100644
index 9fff82b..0000000
--- a/website/news/release-0.11-1.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!meta title="MonkeySphere 0.11-1 released!"]]
-
-# MonkeySphere 0.11-1 released! #
-
-MonkeySphere 0.11-1 has been released. This release includes bugfixes
-and a new `monkeysphere subkey-to-ssh-agent` subcommand.
-
-Using the new subcommand requires that your system's [GnuTLS library
-can deal with the gnu-dummy S2K
-extension](http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html),
-but it should fail gracefully if that's not possible.
-
-[[download]] it now!
diff --git a/website/news/release-0.12-1.mdwn b/website/news/release-0.12-1.mdwn
deleted file mode 100644
index 33dd033..0000000
--- a/website/news/release-0.12-1.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!meta title="MonkeySphere 0.12-1 released!"]]
-
-# MonkeySphere 0.12-1 released! #
-
-MonkeySphere 0.12-1 has been released. This release includes
-documentation updates, and a re-organized logging subsystem with
-various levels of verbosity, modeled after LogLevel in OpenSSH.
-
-[[download]] it now!
diff --git a/website/news/release-0.13-1.mdwn b/website/news/release-0.13-1.mdwn
deleted file mode 100644
index 732eb0a..0000000
--- a/website/news/release-0.13-1.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!meta title="MonkeySphere 0.13-1 released!"]]
-
-# MonkeySphere 0.13-1 released! #
-
-MonkeySphere 0.13-1 has been released. In this release we moved the
-user config directory from ~/.config/monkeysphere to ~/.monkeysphere,
-over concerns that the old location is not quite standard enough.
-
-[[download]] it now!
diff --git a/website/news/release-0.14-1.mdwn b/website/news/release-0.14-1.mdwn
deleted file mode 100644
index 2b93c64..0000000
--- a/website/news/release-0.14-1.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!meta title="MonkeySphere 0.14-1 released!"]]
-
-# MonkeySphere 0.14-1 released! #
-
-MonkeySphere 0.14-1 has been released.
-
-This release introduces packaging and distribution changes only, so
-that we can offer a clean tarball to non-debian users who might be
-interested.
-
-[[Download]] it now!
diff --git a/website/news/release-0.15-1.mdwn b/website/news/release-0.15-1.mdwn
deleted file mode 100644
index 8124f55..0000000
--- a/website/news/release-0.15-1.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta title="MonkeySphere 0.15-1 released!"]]
-
-# MonkeySphere 0.15-1 released! #
-
-MonkeySphere 0.15-1 has been released.
-
-From the changelog:
-
-<pre>
- * porting work and packaging simplification: clarifying makefiles,
- pruning dependencies, etc.
- * added tests to monkeysphere-server diagnostics
- * moved monkeysphere(5) to section 7 of the manual
- * now shipping TODO in /usr/share/doc/monkeysphere
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.16-1.mdwn b/website/news/release-0.16-1.mdwn
deleted file mode 100644
index 3e177df..0000000
--- a/website/news/release-0.16-1.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta title="Monkeysphere 0.16-1 released!"]]
-
-# Monkeysphere 0.16-1 released! #
-
-Monkeysphere 0.16-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- [ Daniel Kahn Gillmor ]
- * replaced "#!/bin/bash" with "#!/usr/bin/env bash" for better
- portability.
- * fixed busted lockfile arrangement, where empty file was being locked
- * portability fixes in the way we use date, mktemp, hostname, su
- * stop using /usr/bin/stat, since the syntax appears to be totally
- unportable
- * require GNU getopt, and test for getopt failures (look for getopt in
- /usr/local/bin first, since that's where FreeBSD's GNU-compatible
- getopt lives.
- * monkeysphere-server diagnostics now counts problems and suggests a
- re-run after they have been resolved.
- * completed basic test suite: this can be run from the git sources or
- the tarball with: cd tests && ./basic
-
- [ Jameson Graef Rollins ]
- * Genericize fs location variables.
- * break out gpg.conf files into SYSCONFIGDIR, and not auto-generated at
- install.
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.17-1.mdwn b/website/news/release-0.17-1.mdwn
deleted file mode 100644
index ae3e742..0000000
--- a/website/news/release-0.17-1.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta title="Monkeysphere 0.17-1 released!"]]
-
-# Monkeysphere 0.17-1 released! #
-
-Monkeysphere 0.17-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- [ Jameson Graef Rollins ]
- * Fix some bugs in, and cleanup, authorized_keys file creation in
- monkeysphere-server update-users.
- * Move to using the empty string for not adding a user-controlled
- authorized_keys file in the RAW_AUTHORIZED_KEYS variable.
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.18-1.mdwn b/website/news/release-0.18-1.mdwn
deleted file mode 100644
index bacb8a4..0000000
--- a/website/news/release-0.18-1.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta title="Monkeysphere 0.18-1 released!"]]
-
-# Monkeysphere 0.18-1 released! #
-
-Monkeysphere 0.18-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- [ Jameson Graef Rollins ]
- * Fix bugs in authorized_{user_ids,keys} file permission checking.
- * Add new monkeysphere tmpdir to enable atomic moves of authorized_keys
- files.
- * chown authorized_keys files to `whoami`, for compatibility with test
- suite.
- * major improvements to test suite, added more tests.
-
- [ Daniel Kahn Gillmor ]
- * update make install to ensure placement of
- /etc/monkeysphere/gnupg-{host,authentication}.conf
- * choose either --quick-random or --debug-quick-random depending on
- which gpg supports for the test suite.
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.19-1.mdwn b/website/news/release-0.19-1.mdwn
deleted file mode 100644
index eb340c9..0000000
--- a/website/news/release-0.19-1.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta title="Monkeysphere 0.19-1 released!"]]
-
-# Monkeysphere 0.19-1 released! #
-
-Monkeysphere 0.19-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- [ Daniel Kahn Gillmor ]
- * simulating an X11 session in the test script.
- * updated packaging so that symlinks to config files are correct.
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.20-1.mdwn b/website/news/release-0.20-1.mdwn
deleted file mode 100644
index 0279b7c..0000000
--- a/website/news/release-0.20-1.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta title="Monkeysphere 0.20-1 released!"]]
-
-Monkeysphere 0.20-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- [ Daniel Kahn Gillmor ]
- * ensure that tempdirs are properly created, bail out otherwise instead
- of stumbling ahead.
- * minor fussing with the test script to make it cleaner.
-
- [ Jameson Graef Rollins ]
- * clean up Makefile to generate more elegant source tarballs.
- * make myself the maintainer.
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.21-1.mdwn b/website/news/release-0.21-1.mdwn
deleted file mode 100644
index 2577f2a..0000000
--- a/website/news/release-0.21-1.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!meta title="Monkeysphere 0.21-1 released!"]]
-
-Monkeysphere 0.21-1 has been released.
-
-Notes from the changelog:
-
-<pre>
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.22-1.mdwn b/website/news/release-0.22-1.mdwn
deleted file mode 100644
index 70fe7bd..0000000
--- a/website/news/release-0.22-1.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta title="Monkeysphere 0.22-1 released!"]]
-
-Monkeysphere 0.22-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- * New upstream release:
- [ Jameson Graef Rollins ]
-
- - added info log output when a new key is added to known_hosts file.
- - added some useful output to the ssh-proxycommand for "marginal"
- cases where keys are found for host but do not have full validity.
- - force ssh-keygen to read from stdin to get ssh key fingerprint.
-
- [ Daniel Kahn Gillmor ]
-
- - automatically output two copies of the host's public key: one
- standard ssh public key file, and the other a minimal OpenPGP key with
- just the latest valid self-sig.
- - debian/control: corrected alternate dependency from procfile to
- procmail (which provides /usr/bin/lockfile)
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.23-1.mdwn b/website/news/release-0.23-1.mdwn
deleted file mode 100644
index 83f8456..0000000
--- a/website/news/release-0.23-1.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta title="Monkeysphere 0.23-1 released!"]]
-
-Monkeysphere 0.23-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- "The Golden Bezoar Release"
-
- * New upstream release.
- * rearchitect UI:
- - replace monkeysphere-server with monkeysphere-{authentication,host}
- - fold monkeysphere-ssh-proxycommand into /usr/bin/monkeysphere
-
- * new ability to import existing ssh host key into monkeysphere. So now
- m-a import-key replaces m-s gen-key.
- * provide pem2openpgp for translating unencrypted PEM-encoded raw key
- material into OpenPGP keys (introduces new perl dependencies)
- * get rid of getopts dependency
- * added version output option
- * better checks for the existence of a host private key for
- monkeysphere-host subcommands that need it.
- * better checks on validity of existing authentication subkeys when
- doing monkeysphere gen_subkey.
- * add transition infrastructure for major changes between releases (see
- transitions/README.txt)
- * implement and document two new monkeysphere-host subcommands:
- revoke-key and add-revoker
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.23.1-1.mdwn b/website/news/release-0.23.1-1.mdwn
deleted file mode 100644
index 493d366..0000000
--- a/website/news/release-0.23.1-1.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!meta title="Monkeysphere 0.23.1-1 released!"]]
-
-Monkeysphere 0.23.1-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- * New Upstrem "Brown Paper Bag" Release:
- - adjusts internal version numbers
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.24-1.mdwn b/website/news/release-0.24-1.mdwn
deleted file mode 100644
index 340a706..0000000
--- a/website/news/release-0.24-1.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!meta title="Monkeysphere 0.24-1 released!"]]
-
-Monkeysphere 0.24-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- * New upstream release:
- - fixed how version information is stored/retrieved
- - now uses perl-based keytrans for both pem2openpgp and openpgp2ssh
- - no longer needs base64 in PATH
- - added "test" make target
- - improved transitions/0.23 script so it no longer fails in common
- circumstances (Closes: #517779)
- - RSA only: no longer handles DSA keys
- - added ability to specify subkeys to add to ssh agent with
- new MONKEYSPHERE_SUBKEYS_FOR_AGENT environment variable
- * update/cleanup maintainer scripts
- * remove GnuTLS dependency
- * remove versioned coreutils | base64 dependency
- * added Build-Deps for dh_autotest
- * switch to Architecture: all
- * added cron to Recommends
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.25-1.mdwn b/website/news/release-0.25-1.mdwn
deleted file mode 100644
index c88dba6..0000000
--- a/website/news/release-0.25-1.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!meta title="Monkeysphere 0.25-1 released!"]]
-
-Monkeysphere 0.25-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- * New upstream release:
- - update/fix the marginal ui output
- - use msmktempdir everywhere (avoid unwrapped calls to mktemp for
- portability)
- - clean out some redundant "cat"s
- - fix monkeysphere update-known_hosts for sshd running on non-standard
- ports
- - add 'sshfpr' subcommand to output the ssh fingerprint of a gpg key
- - pem2openpgp now generates self-sigs over SHA-256 instead of SHA-1
- (changes dependency to libdigest-sha-perl)
- - some portability improvements
- - properly handle translation of keys with fingerprints with leading
- all-zero bytes.
- - resolve symlinks when checking paths (thanks Silvio Rhatto)
- (closes MS #917)
- - explicitly set and use MONKEYSPHERE_GROUP from system "groups"
- (closes: #534008)
- - monkeysphere-host now uses keytrans to add and revoke hostname
- (closes MS #422)
- * update Standard-Version to 3.8.2 (no changes needed)
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.26-1.mdwn b/website/news/release-0.26-1.mdwn
deleted file mode 100644
index ba196fc..0000000
--- a/website/news/release-0.26-1.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta title="Monkeysphere 0.26-1 released!"]]
-
-Monkeysphere 0.26-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- * New upstream release:
- - add 'refresh-keys' subcommand to monkeysphere-authentication
- - improve marginal UI (closes MS #1141)
- - add MONKEYSPHERE_STRICT_MODES configuration to avoid
- permission-checking (closes MS #649)
- - test scripts use STRICT_MODES to avoid failure when built under /tmp
- (Closes: #527765)
- - do permissions checks with a perl script instead of non-portable
- readlink GNUisms
- - bail on permissions check if we hit the home directory (helpful on
- Mac OS and other systems with loose /home or /Users (closes MS #675)
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.27-1.mdwn b/website/news/release-0.27-1.mdwn
deleted file mode 100644
index f9c94ed..0000000
--- a/website/news/release-0.27-1.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta title="Monkeysphere 0.27-1 released!"]]
-
-Monkeysphere 0.27-1 has been released.
-
-Notes from the changelog:
-
-<pre>
- * New upstream release:
- - fixed monkeysphere gen-subkey subcommand that was erroneously
- creating DSA subkeys due to unannounced change in gpg edit-key UI.
- Now tests for gpg version (closes MS #1536)
- - add new monkeysphere keys-from-userid subcommand to output all
- acceptable keys for a given user ID literal
- * updated debian/copyright to match the latest revision of DEP5.
- * updated standards version to 3.8.3 (no changes needed)
- * add cpio to Build-Depends (used in test suite) (Closes: #562444)
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.28.mdwn b/website/news/release-0.28.mdwn
deleted file mode 100644
index b18b6a6..0000000
--- a/website/news/release-0.28.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta title="Monkeysphere 0.28 released!"]]
-
-Monkeysphere 0.28 has been released.
-
-Notes from the changelog:
-
-<pre>
- * Major rework of monkeysphere-host to handle multiple host keys. We
- also no longer assume ssh service keys. monkeysphere-host is now a
- general-purpose host service OpenPGP key management UI.
- * Rename keys-from-userid command to more accurate keys-for-userid
- * separate upstream and debian changelogs
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.29.mdwn b/website/news/release-0.29.mdwn
deleted file mode 100644
index e113614..0000000
--- a/website/news/release-0.29.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta title="Monkeysphere 0.29 released!"]]
-
-Monkeysphere 0.29 has been released.
-
-Notes from the changelog:
-
-<pre>
- * This is mainly a bugfix release
- * Fix man page typo about monkeysphere authorized_keys location
- * Monkeysphere should work properly even if the user has "armor" in
- their gpg.conf (closes MS #1625)
- * monkeysphere keys-for-userid now respects MONKEYSPHERE_CHECK_KEYSERVER
- environment variable (and defaults to true)
- * introduce monkeysphere sshfprs-for-userid (deprecates sshfpr), closes
- MS #1436
- * respect CHECK_KEYSERVER in more places (closes MS #1997)
- * warn on keyserver failures for monkeysphere-authentication (closes MS
- #1750)
- * avoid checking trustdb for monkeysphere-host (closes MS #1957)
- * allow monkeysphere-authentication to use hkps with trusted X.509 root
- certificate authorities in
- /etc/monkeysphere/monkeysphere-authentication-x509-anchors.crt
-</pre>
-
-[[Download]] it now!
diff --git a/website/news/release-0.5-1.mdwn b/website/news/release-0.5-1.mdwn
deleted file mode 100644
index 6a9cc0f..0000000
--- a/website/news/release-0.5-1.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-# MonkeySphere 0.5-1 released! #
-
-MonkeySphere 0.5-1 has been released. It includes updates to
-documentation and a few adjustments to behavior in the corner case
-where `authorized_user_ids` files are empty or missing. [[download]]
-it now!
diff --git a/website/news/release-0.7-1.mdwn b/website/news/release-0.7-1.mdwn
deleted file mode 100644
index 1d744e5..0000000
--- a/website/news/release-0.7-1.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-# MonkeySphere 0.7-1 released! #
-
-MonkeySphere 0.7-1 has been released. This release contains bugfixes,
-a new `monkeysphere-server diagnostics` subcommand, and marks a
-transition to the new [Git-based debian packaging
-format](http://wiki.debian.org/GitSrc). [[download]] it now!
diff --git a/website/news/release-0.8-1.mdwn b/website/news/release-0.8-1.mdwn
deleted file mode 100644
index ff95b0e..0000000
--- a/website/news/release-0.8-1.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-[[!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
deleted file mode 100644
index b4ce4dc..0000000
--- a/website/news/release-0.9-1.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!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/news/website-launched.mdwn b/website/news/website-launched.mdwn
deleted file mode 100644
index 9936a29..0000000
--- a/website/news/website-launched.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-# The monkeysphere web site is launched! #
-
-dkg registered monkeysphere.info and monkesphereproject.net (due to the
-failure of Chase to implement the monkeysphere, they were not able to properly
-verify my credit card number).
-
-And ... they are both now resolving to an actual real web site.
-
-I just took the following steps to put the web site in place (skip to the
-bottom to see what this all means if you want to modify the web site):
-
- * Created a new subdirectory of my git repo: website
-
- * Copied the default files for setting up an ikiwiki software project into
- this repository.
-
- * I deleted the contact page, Makefile (for generating a html
- doc directory for the project), and documentation page. I'm not opposed to
- these pages, I was just in a hurry to get something published and wasn't sure
- what to do with these files. We can always add them later.
-
- * I edited the remaining files to reflect the project (as best I could).
-
- * I created a user and web directory on the same server as my published
- monkeysphere git repository.
-
- * I created a clone of my monkeysphere git repository owned by this new user.
-
- * I created an ikiwiki setup file that:
- * Specifies the clone as the "srcdir"
-
- * Specifies my new web directory as the web directory
-
- * Generates a setuid binary, owned by the web directory owner, that will
- update the src repo and re-generate the web pages.
-
- * In my published git repo, I added this setuid binary file to my
- post-update script so that when I push to my git repo, it will trigger
- ikiwiki to auto-generate the html
-
-What does this all means if you want to edit the web site?
-
-At the moment, we're betraying our all-distributed, all-the-time mode of
-operations. I'm acting as the web manager (kinda like a release manager).
-
-That means that if you want a web site change, you should publish it to your
-git repo and then let me know. Then, I pull in your change and push it to my
-published repo which in turn pushes it to the web site.
-
-Also - of note - web edits are not allowed, although that's technically
-possible with ikiwiki.
-
-In general, I'm going with simplicity first - we can get more fancy later.
-
-Oh... the files are written in the markdown language, which is ikiwiki default
-(http://daringfireball.net/projects/markdown/syntax).
-
diff --git a/website/screenshots.mdwn b/website/screenshots.mdwn
deleted file mode 100644
index 96ca630..0000000
--- a/website/screenshots.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta title="Screenshots"]]
-
-# Screenshots #
-
-This is a screenshot of the "marginal UI" output of the monkeysphere
-ssh-proxycommand. The user knows Jamie, and has assigned Marginal
-ownertrust to him, so his certification is visible but not sufficient
-on blanco's host key:
-
-![Simple Marginal UI screenshot](blanco.png "Simple Marginal UI screenshot")
-
-Here is a more complex situation, involving multiple hostnames (a
-common misspelling, in this instance) with different calculated
-validities, and multiple certifiers:
-
-![Complex Marginal UI screenshot](zimmerman.png "Complex Marginal UI screenshot")
-
-More screenshots may be available at [screenshots.debian.net](http://screenshots.debian.net/package/monkeysphere).
diff --git a/website/screenshots/blanco.png b/website/screenshots/blanco.png
deleted file mode 100644
index c1cd5a1..0000000
--- a/website/screenshots/blanco.png
+++ /dev/null
Binary files differ
diff --git a/website/screenshots/zimmerman.png b/website/screenshots/zimmerman.png
deleted file mode 100644
index 99229dd..0000000
--- a/website/screenshots/zimmerman.png
+++ /dev/null
Binary files differ
diff --git a/website/sidebar.mdwn b/website/sidebar.mdwn
deleted file mode 100644
index 8d5a72f..0000000
--- a/website/sidebar.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-<table class="sitenav" cellpadding="0" cellspacing="0">
-<colgroup span="1" width="120" />
-<tr>
-<td rowspan="2"><a href="/"><img class="logo" src="/logo.simple.png" alt="monkeysphere" /></a></td>
-<td><a href="/"><img class="title" src="/logo.title.png" alt="monkeysphere" /></a></td>
-</tr><tr>
-<td>
-[[WHY?|why]]
-[[DOWNLOAD|download]]
-[[SCREENSHOTS|screenshots]]
-[[DOCUMENTATION|doc]]
-[[NEWS|news]]
-[[COMMUNITY|community]]
-<a href="https://labs.riseup.net/code/wiki/monkeysphere">WIKI</a>
-<a href="https://labs.riseup.net/code/projects/monkeysphere/issues">BUGS</a>
-[[VISION|vision]]
-</td>
-</tr>
-</table>
-
diff --git a/website/signing-host-keys.mdwn b/website/signing-host-keys.mdwn
deleted file mode 100644
index 1eb61a0..0000000
--- a/website/signing-host-keys.mdwn
+++ /dev/null
@@ -1,127 +0,0 @@
-# Signing a host's SSH key using OpenPGP #
-
-This page is meant to address the issue of signing OpenPGP-based SSH
-host keys. Machines are not people, so the circumstances under which
-one should sign a host key are different from those under which one
-should sign another person's key.
-
-# Why are signatures on an SSH host key important? #
-
-In order for users to validate a host (an SSH server) in a
-monkeysphere-enabled network, the host key must have *full* calculated
-validity from the perspective of the connecting user. If the user has
-not themselves signed the server's key, then the server's key can only
-be valid if other people that the user trusts have signed the key.
-
-If only one person has signed the server's key, then the user must
-fully trust the single person who has signed the host key. Full trust
-should be granted sparingly and with consideration, though, so unless
-the user knows the server admin very well, they will in general not
-have full trust of this person.
-
-However, full trust of the host key can also be achieved if the
-server key has been signed by three or more people that the user has
- *marginal* trust of. In other words, three or more *marginally*
-trusted signatures equals one *fully* trusted signature. It is much
-more common for users to have marginal trust of other users in the Web
-of Trust. For this reason, it is advisable to have as many people
-sign the server key as possible.
-
-## What information should you have before signing a host key? ##
-
-Before signing the key of a person, you want to do two things:
-
-1. verify the identity of the person.
-2. verify that the person is actually in control of the key that you
-are signing.
-
-For a server, you want to do basically the same thing:
-
-1. verify the identity of the server.
-2. verify that the server is actually in control of the key that you
-are signing.
-
-However, verifying these things for a server is less intuitive than it
-is for a human.
-
-Verifying that the host is in control of the key is, in principle,
-straightforward. If you are logged on to the machine in question,
-then you can check directly that the key exists on the system.
-
-What is not so straightforward is what exactly it means to "verify the
-identity" of a remote server on the internet? The identity in this
-case is the fully qualified domain name (FQDN) of the host. Verifying
-this identity amounts to being sure that the host in question really
-is located at that FQDN.
-
-## Signing the host key ##
-
-If you are the person (or persons) that actually setup the server and
-configured Monkeysphere and ssh on the server, then you should sign
-the host key as part of that process. When the server is first set
-up, the administrators who set it up are the only ones who can
-actually vouch for the server key, so their signatures are necessary
-to get things going. Their signatures are also necessary so that they
-can validate the host key themselves and log into the server via
-monkeysphere-enabled ssh in the future.
-
-If you did not set up the server initially, you do not have an
-accumulated full trust of the person(s) who did, and you do not
-necessarily have console access to the server directly, it's hard to
-confidently verify the server identity and key ownership. You would
-like to be able to walk up to the server, log in at the console, and
-get the fingerprint of the ssh host key directly. But this is usually
-impossible.
-
-However, it is still possible to verify the server identity *and*
-server ownership of the key, even in this case.
-
-## Remotely verifying host identity and key possession ##
-
-It is in fact possible to verify the identity and key ownership of a
-server in one fell swoop with monkeysphere-enabled ssh. Here is the
-procedure:
-
-> **Attempt to make a monkeysphere-enabled ssh connection to the host in
-question. Monkeysphere will check that the ssh host key offered by the
-host matches the OpenPGP key with the correct host FQDN user ID. If
-the ssh host key and the OpenPGP key with the correct user ID match,
-then you will have effectively:**
-
->**1. verified the host identity, because you actually connected to the
-host in question, which you know because you:**
-
->**2. verified the host is in control of the key, because the ssh host
-key offered by the host matches the OpenPGP key with correct host FQDN
-user ID.**
-
-Here is an example:
-
- servo:~ 0$ ssh zimmermann.mayfirst.org
- -------------------- Monkeysphere warning -------------------
- Monkeysphere found OpenPGP keys for this hostname, but none had full validity.
- An OpenPGP key matching the ssh key offered by the host was found:
-
- pub 2048R/860E8F9C 2008-10-29 [expires: 2009-02-26]
- uid [marginal] ssh://zimmermann.mayfirst.org
- sig! 76CC057D 2008-11-15 Jamie McClelland <jamie@mayfirst.org>
- sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org
- sig! D21739E9 2008-10-29 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- sig! 1CF2D62A 2008-11-16 Micah Anderson <micah@riseup.net>
-
- RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e.
- -------------------- ssh continues below --------------------
- The authenticity of host 'zimmermann.mayfirst.org (<no hostip for proxy command>)' can't be established.
- RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e.
- No matching host key fingerprint found in DNS.
- Are you sure you want to continue connecting (yes/no)? no
- Host key verification failed.
- servo:~ 255$
-
-I have attempted to connect to the host zimmermann.mayfirst.org.
-zimmermann's host key has only *marginal* validity for the FQDN user
-ID in question, so I am not able to connect. However, the
-Monkeysphere has checked that the ssh host key actually does match the
-OpenPGP key with the correct user ID `ssh://zimmermann.mayfirst.org`.
-I have therefore verified the identity of zimmermann, and verified
-that zimmermann is in possession of the key in question.
diff --git a/website/similar.mdwn b/website/similar.mdwn
deleted file mode 100644
index aef9c6f..0000000
--- a/website/similar.mdwn
+++ /dev/null
@@ -1,135 +0,0 @@
-[[!meta title="Similar Projects"]]
-
-The monkeysphere isn't the only project intending to implement a PKI
-for OpenSSH. We provide links to these other projects because they're
-interesting, though we have concerns with their approaches.
-
-[[toc ]]
-
-All of the other projects we've found so far require a patched version
-of OpenSSH, which makes adoption more difficult. Most people don't
-build their own software, and simply overlaying a patched binary is
-associated with significant maintenance (and therefore security)
-problems.
-
-While ultimately contributing a patch to
-[OpenSSH](http://openssh.com/) (or
-[any](http://mina.apache.org/sshd/)
-[free](http://www.chiark.greenend.org.uk/~sgtatham/putty/)
-[SSH](http://www.lysator.liu.se/~nisse/lsh/)
-[implementation](http://matt.ucc.asn.au/dropbear/dropbear.html)) is
-not a bad thing, we hope to be able to better establish the use of a
-PKI without resorting to source modification.
-
-## openssh-gpg ##
-
-[openssh-gpg](http://www.red-bean.com/~nemo/openssh-gpg/) is a patch
-against OpenSSH to support OpenPGP certificates. According to its
-documentation, it is intended to support [`pgp-sign-rsa` and
-`pgp-sign-dss` public key algorithms for hosts, as specified by the
-IETF](http://tools.ietf.org/html/rfc4253#section-6.6).
-
-Some concerns with `openssh-gpg`:
-
- * This patch is old; it doesn't appear to have been maintained beyond
- OpenSSH 3.6p1. As of this writing, OpenSSH 5.1p1 is current.
-
- * It only provides infrastructure in one direction: the user
- authenticating the host by name. There doesn't seem to be a
- mechanism for dealing with identifying users by name, or allowing
- users to globally revoke or update keys.
-
- * The choice of User ID (`anything goes here (and here!)
- <ssh@foo.example.net>`) for host keys overlaps with the current use
- of the User ID space. While it's unlikely that someone actually
- uses this e-mail address in the web of trust, it would be a nasty
- collision, as the holder of that key could impersonate the server
- in question. The monkeysphere uses [User IDs of the form
- `ssh://foo.example.net`](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/)
- to avoid collisions with existing use.
-
- * It's not clear that `openssh-gpg` acknowledges or respects the
- [usage flags](http://tools.ietf.org/html/rfc4880#section-5.2.3.21)
- on the host keys. This means that it could accept a "sign-only"
- key as suitable for authenticating a host, despite the
- clearly-marked intentions of the key-holder.
-
-## Perspectives OpenSSH client ##
-
-[The Perspectives project](http://www.cs.cmu.edu/~perspectives/) at
-CMU has released an [openssh client that uses network
-notaries](http://www.cs.cmu.edu/~perspectives/openssh.html) to bolster
-your confidence in newly-seen keys. This offers a defense against a
-narrow MITM attack (e.g. by someone who controls your local gateway)
-by simply verifying that other machines from around the network see
-the same keys for the remote host that you're seeing.
-
-This tactic is quite useful, but doesn't take the system as far as it
-could go, and doesn't tie into any existing web of trust.
-
-Some concerns with the Perspectives OpenSSH client:
-
- * This client won't help if you are connecting to machines behind
- firewalls, on NAT'ed LANs, with source IP filtering, or otherwise
- in a restricted network state, because the notaries won't be able
- to reach it.
-
- * There is still a question of why you should trust these particular
- notaries during your verification. Who are the notaries? How
- could they be compromised?
-
- * It only provides infrastructure in one direction: the user
- authenticating the host by name. There is no mechanism for dealing
- with identifying users by name, or allowing users to globally
- revoke or change keys.
-
- * It doesn't provide any mechanism for key rotation or revocation:
- Perspectives won't help you if you need to re-key your machine.
-
- * The most common threat which Perspectives protects against (a
- narrow MITM attack, e.g. the attacker controls your gateway) often
- coincides with the ability of the attacker to filter arbitrary
- traffic to your node. But in this case, the attacker could filter
- out your traffic to the notaries (or the responses from the
- notaries). Such filtering (rejecting unknown UDP traffic, as
- Perspectives appears to use UDP port 15217) is unfortunately
- common, particuarly on public networks, even when the gateway is
- not malicious. This reduces the utility of the Perspectives
- approach.
-
-## OpenSSH with X.509v3 certificates ##
-
-Roumen Petrov [maintains a patch to OpenSSH that works with the X.509
-PKI model](http://www.roumenpetrov.info/openssh/). This is the
-certificate hierarchy commonly used by TLS (and SSL).
-
-Some concerns about OpenSSH with X.509v3:
-
- * the X.509 certificate specification itself [encourages corporate
- consolidation and centralized global "trust" because of its
- single-issuer architectural
- limitation](http://lair.fifthhorseman.net/~dkg/tls-centralization/).
- This results in an expensive and cumbersome system for smaller
- players, and it also doesn't correspond to the true distributed
- nature of human-to-human trust. Furthermore, centralized global
- "trusted authorities" create a tempting target for attack, and a
- single-point-of-failure if an attack is successful.
-
- Depending on how you declare your trust relationships, OpenPGP is
- capable of providing the same hierarchical structure as X.509, but
- it is not limited to such a structure. The OpenPGP Web of Trust
- model is more flexible and more adaptable to represent real-world
- trust than X.509's rigid hierarchy.
-
- * X.509 certificates can identify hosts by name, but not by
- individual service. This means that a compromised web or e-mail
- server with access to the X.509 key for that service could re-use
- its certificate as an SSH server, and it would be able to
- masquerade successfully.
-
- The monkeysphere uses [User IDs of the form
- `ssh://foo.example.net`](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/),
- so they are not by-default shared across services on the same host
- (you can still share a key across services on the same host if you
- like, but the service User IDs can be certified independently of
- one another).
diff --git a/website/technical-details.mdwn b/website/technical-details.mdwn
deleted file mode 100644
index 08198b1..0000000
--- a/website/technical-details.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta title="Technical Details"]]
-
-# Technical Details #
-
-Under construction.
-
-## Host key verification ##
-
-When an ssh connection is initiated, the ssh client checks that the
-host key presented by the server matches one found in the connecting
-user's `known_hosts` file. If so, the ssh client allows the
-connection to continue. If not, the client asks the user if they
-would like to accept the host key for future session by asking the
-user to verify the host key's fingerprint.
-
-### Adding a server to the monkeysphere ###
-
-Servers are "monkeysphere enabled" by generating an OpenPGP
-authentication key for the server, translating the key into on ssh
-key, and publishing the host key to the Web of Trust.
-
-### Verifying a host key ###
-
-## User authentication ##
-
-### Adding an individual to the monkeysphere ###
-
-### Verifying a user key ###
diff --git a/website/trust-models.mdwn b/website/trust-models.mdwn
deleted file mode 100644
index 37928eb..0000000
--- a/website/trust-models.mdwn
+++ /dev/null
@@ -1,203 +0,0 @@
-[[!meta title="OpenPGP Trust Models"]]
-
-# OpenPGP Trust Models #
-
-Monkeysphere relies on GPG's definition of the OpenPGP web of trust,
-so it's important to understand how GPG calculates User ID validity
-for a key.
-
-The basic question that a trust model tries to answer is: For a given
-User ID on a specific key, given some set of valid certifications
-(signatures), and some explicit statements about whose certifications
-you think are trustworthy (ownertrust), should we consider this User
-ID to be legitimately attached to this key (a "valid" User ID)?
-
-It's worth noting that there are two integral parts in this
-calculation:
-
- * the certifications themselves -- this is the objective part: the
- correctness of these signatures can be calculated with a known
- algorithm which everyone knows and agrees on, based on the public
- keys involved.
-
- * the ownertrust -- this is the subjective part: Who do you trust to
- identify other entities on the network? And *how much* do you
- trust them to make these identifications correctly? Everyone could
- (and should!) answer this question differently, based on their
- values and their relationships to the entities in question.
-
- I might trust my sister's certifications because we've talked about
- what sorts of certifications we feel comfortable making, and i
- agree with her choices ("full" or "complete" ownertrust). You
- might not know her at all, and have no reason to treat her
- certifications as valid (no ownertrust).
-
- I might decide that the local municipality's procedures for
- obtaining identity documents are a joke, and not trust their
- certifications at all (no ownertrust), while you might feel that
- their certifications are helpful as corroboration, but not to be
- trusted on their own ("marginal" or "partial" ownertrust). (Note:
- I wish my municipality actually made cryptographic certifications
- of identity, regardless of the ownertrust i'd put in them!)
-
-## What does "validity" mean anyway? ##
-
-You see the term "validity" a lot in this context, but it has several
-subtly different meanings:
-
-First of all, someone might speak of the validity of a key itself,
-which could mean two things:
-
- * The key is cryptographically well-formed, not revoked, not expired,
- and has reasonable self-signatures on its User ID packets.
-
- * It is *also* sometimes used to mean something like "the maximum
- validity of any associated User ID or [User
- Attribute](http://tools.ietf.org/html/rfc4880#section-5.12)". This
- definition is often not very useful; because if you care about User
- IDs at all, you usually care about a *specific* User ID.
-
-So the more useful definition of validity is actually *User ID
-validity*:
-
- * Given that:
-
- * the key itself is valid, in the first narrow sense used above, and
- * given the UserID's set of cryptographically-correct certifications, and
- * given your personal subjective declarations about who you trust to make certifications (and *how much* you trust them to do this),
-
- is this User ID bound to its key with an acceptable trust path?
-
-## Examining your GPG trust database ##
-
-You can see your trust database parameters like this:
-
- gpg --with-colons --list-key bogusgarbagehere 2>/dev/null | head -n1
-
-for me, it looks like this:
-
- tru::1:1220401097:1220465006:3:1:5
-
-These colon-delimited records say (in order):
-
- * `tru`: this is a trust database record
- * `<empty>`: the trust database is not stale (might be 'o' for old, or 't' for "built with different trust model and not yet updated")
- * `1`: uses new "PGP" trust model (0 would be the "Classic trust model") -- see below
- * `1220401097`: seconds since the epoch that I created the trust db.
- * `1220465006`: seconds after the epoch that the trustdb will need to be rechecked (usually due to the closest pending expiration, etc)
- * `3`: Either 3 certifications from keys with marginal ownertrust ...
- * `1`: Or 1 certification from a key with full ownertrust is needed for full User ID+Key validity
- * `5`: `max_cert_depth` (i'm not sure exactly how this is used, though the name is certainly suggestive)
-
-
-## Classic trust model ##
-
-As far as i can tell, the basic trust model is just the `3` and `1`
-from the above description:
-
- * how many certifications from keys with marginal ownertrust are
- needed to grant full validity to a User ID on a key?
-
- * how many certifications from keys with full ownertrust are needed
- to grant full validity for a User ID on a key?
-
-If either of these are satisfied, the User ID is considered to be
-legitimately attached to its key (it is "fully" valid).
-
-If there are no certifications from anyone you trust, the User ID is
-considered to have unknown validity, which basically means "not
-valid".
-
-If there are *some* certifications from people who you trust, but not
-enough to satisfy either condition above, the User ID has "marginal
-validity".
-
-## PGP trust model (Classic trust model + trust signatures) ##
-
-Note that so far, your ability to express ownertrust is relatively
-clumsy. You can say "i trust the certifications made by this
-keyholder completely", or "a little bit", or "not at all". And these
-decisions about ownertrust are an entirely private matter. You have
-no formal way to declare it, or to automatically interpret and act on
-others' declarations. There is also no way to limit the scope of this
-ownertrust (e.g. "I trust my co-worker to properly identify anyone in
-our company, but would prefer not to trust him to identify my bank").
-
-[Trust
-signatures](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) are a
-way to address these concerns. With a trust signature, I can announce
-to the world that i think my sister's certifications are legitimate.
-She is a "trusted introducer". If i use "trust level 1", this is
-equivalent to my ownertrust declaration, except that i can now make it
-formally public by publishing the trust signature to any keyserver.
-
-If you trust my judgement in this area ([the
-spec](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) calls my
-role in this scenario a "!meta introducer"), then you should be able to
-automatically accept certifications made by my sister by creating a
-level 2 trust signature on my key. You can choose whether to publish
-this trust signature or not, but as long as your `gpg` instance knows
-about it, my sister's certifications will be treated as legitimate.
-
-Combining trust signatures with [regular
-expressions](http://tools.ietf.org/html/rfc4880#section-5.2.3.14)
-allows you to scope your trust declarations. So, for example, if you
-work at ExampleCo, you might indicate in a standard level 1 trust
-signature on your co-worker's key that you trust them to identify any
-User ID within the `example.com` domain.
-
-### Problems and Questions with Chained Trust ###
-
-How do partial/marginal ownertrust and chained trust connections
-interact? That is, if:
-
- * `A` privately grants "marginal" ownertrust for `B`, and
- * `B` issues a "marginal" trust signature at level 1 for `C`, and
- * `C` certifies `D`'s User ID and key,
-
-Then what should `A` see as the calculated validity for `D`'s User ID?
-Surely nothing more than "marginal", but if `A` marginally trusts two
-other certifications on `D`, should that add up to full validity?
-
-What if the chain goes out more levels than above? Does "marginal"
-get more attenuated somehow as a chain of marginals gets deeper? And
-how exactly does `max_cert_depth` play into all this?
-
-What about regex-scoped trust signatures of level > 1? Does the
-scoping apply to all dependent trust signatures? Has this sort of
-thing been tested?
-
-
-## "ultimate" ownertrust in GnuPG ##
-
-Note that for a key under your sole control, which you expect to use
-to certify other people's User IDs, you would typically give that key
-"ultimate" ownertrust, which for the purposes of the calculations
-described here is very similar to "full".
-
-The difference appears to be this: If a key with "full" ownertrust
-*but with no valid User IDs* makes a certification, that certification
-will not be considered. But if the certifying key has "ultimate"
-ownertrust, then its certifications *are* considered.
-
-So "full" ownertrust on a key is only meaningful as long as there is a
-trust path to some User ID on that key already. "ultimate" ownertrust
-is meaningful anyway, because presumably you control that key.
-
-## Other references ##
-
- * Much of this was gathered from experimenting with
- [GnuPG](http://gnupg.org/), and reading [gpg's
- `DETAILS`](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/DETAILS?root=GnuPG&view=markup).
- Unfortunately, `DETAILS` seems to often conflate the ideas of trust
- and validity, which can make it confusing to read.
-
- * [RFC 4880](http://tools.ietf.org/html/rfc4880) is the canonical
- modern OpenPGP reference. If you want to understand the pieces to
- this puzzle in detail, this is the place to go. However, it
- doesn't describe the trust model calculations discussed here
- directly, but only points at them obliquely, through [the
- definition of trust
- signatures](http://tools.ietf.org/html/rfc4880#section-5.2.3.13).
- How your particular OpenPGP client chooses to calculate User ID
- validity is therefore implementation-specific.
diff --git a/website/validation-agent.mdwn b/website/validation-agent.mdwn
deleted file mode 100644
index d95e7d4..0000000
--- a/website/validation-agent.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!meta title="Monkeysphere Validation Agent"]]
-
-# Monkeysphere Validation Agent #
-
-The Monkeysphere Validation Agent offers a local service for systems
-to validate certificates (both X.509 and OpenPGP) and other public
-keys in their proper contexts.
-
-Among other reasons, having a validation agent is a good thing
-because:
-
-* Multiple tools can rely on the same PKI (e.g. the user's web browser
- and the user's ssh client).
-* A single validation agent can present a consistent UI to the user
- (when used in an end-user context), or provide a unified trust model
- to various services (when used in a server-side context).
-* Authentication/certificate validation code can potentially be
- isolated to a protected environment.
-
-## Implementations ##
-
-There are currently two implementations of the validation agent:
-
- * msva-perl
- * msva-ruby
-
-## Protocol ##
-
-The Monkeysphere Validation Agent protocol (MSVA) is defined as a
-minimal HTTP server with JSON-encapsulated requests and responses.
-You may want to read [more protocol details](protocol).
-
diff --git a/website/validation-agent/protocol.mdwn b/website/validation-agent/protocol.mdwn
deleted file mode 100644
index 4e6811a..0000000
--- a/website/validation-agent/protocol.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!meta title="Validation Agent Protocol"]]
-
-# Validation Agent Protocol #
-
-In its current form, the
-[Monkeysphere Validation Agent](/validation-agent) is conceived of as
-a minimalistic HTTP server that accepts two different requests:
-
- GET / -- initial contact query, protocol version compatibility.
- (no query parameters)
- (returns: protoversion, server, available)
-
- POST /reviewcert -- request validation of a certificate
- (query parameters: uid, context, pkc)
- (returns: valid, message)
-
-Query parameters are posted as a JSON blob (*not* as
-www-form-encoded).
-
-The variables that are returned are application/json as well.
-
-* PKC means: public key carrier: raw key, OpenPGP cert, or X.509 cert
-* UID means: User ID (like in OpenPGP)
-* context refers to the setting in which the certificate is offered. For example, "https" means: "this certificate was offered by an HTTPS server"
diff --git a/website/vision.mdwn b/website/vision.mdwn
deleted file mode 100644
index 2580c7d..0000000
--- a/website/vision.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-[[!meta title="Our vision for the future of the monkeysphere"]]
-
-## External Validation Agent ##
-
-This is probably at the crux of the Monkeysphere vision for the future:
-
-* [Simon Josefsson proposed out-of-process certificate verification model in gnutls-devel](http://news.gmane.org/find-root.php?group=gmane.comp.encryption.gpg.gnutls.devel&article=3231)
-* [Werner Koch's dirmngr](http://www.gnupg.org/documentation/manuals/dirmngr/)
-* [GnuTLS wiki external validation](http://redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation)
-* [Pathfinder PKI validation](http://code.google.com/p/pathfinder-pki/) (includes validation plugins for OpenSSL and LibNSS).
-
-## TLS transition strategies ##
-
-While [RFC 5081](http://tools.ietf.org/html/rfc5081) is quite a while
-off from widespread adoption, it would be good to have an interim
-translation step. This is analogous to the SSH work we've done, where
-the on-the-wire protocol remains the same, but the keys themselves are
-looked up in the OpenPGP WoT.
-
-Firefox extensions that deal with certificate validation seem to be
-the easiest path toward demonstrating this technique. We should look
-at:
-
-* [SSL Blacklist](http://codefromthe70s.org/sslblacklist.aspx)
-* [Perspectives](http://www.cs.cmu.edu/~perspectives/firefox.html)
-* there is another firefox extension that basically disables all TLS certificate checking. The download page says things like "this is a bad idea" and "do not install this extension", but i'm unable to find it at the moment.
-
-## Related discussions ##
-
-* [Wandering Thoughts blog discussion about Web of Trust flaws](http://utcc.utoronto.ca/~cks/space/blog/tech/WebOfTrustFlaws?showcomments)
-* [Wandering Thoughts blog discussion about certificate authorities](http://utcc.utoronto.ca/~cks/space/blog/web/SSLCANeed?showcomments)
-* [Zooko's Conjecture: Decentralized, Secure, Human-Meaningful: Choose two](https://zooko.com/distnames.html)
-* [Mark Stiegler's Introduction to Petnames](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html)
diff --git a/website/why.mdwn b/website/why.mdwn
deleted file mode 100644
index d1c15c2..0000000
--- a/website/why.mdwn
+++ /dev/null
@@ -1,182 +0,0 @@
-[[!meta title="Why should you be interested in the Monkeysphere?"]]
-
-# Why should you be interested in the Monkeysphere? #
-
-[[!toc levels=2]]
-
-## 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
-verify that the host you are connecting to actually is the host you
-mean to connect to? 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
-lost 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?
-
-[Get started with the monkeysphere as a user!](/getting-started-user)
-
-## As a system administrator ##
-
-As a system administrator, have you ever tried to re-key an SSH
-server? How did you communicate the key change to your users? How
-did you keep them from getting the big scary warning message that the
-host key had changed?
-
-Have you ever wanted to allow a remote 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 add or revoke the ability of a
-user's key to authenticate across an entire infrastructure you manage,
-without touching each host by hand?
-
-[Get started with the monkeysphere as an administrator!](/getting-started-admin)
-
-## What's the connection? ##
-
-All of these issues are related to a lack of a [Public Key
-Infrastructure (or
-PKI)](http://dictionary.die.net/public%20key%20infrastructure) for
-SSH. A PKI at its core is a mechanism to provide answers to a few
-basic questions:
-
-* Do we know who (or what host) 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: welcome to the Monkeysphere!
-
-## 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. The
-Monkeysphere on `foo` then verifies Bob's identity through the OpenPGP
-Web of Trust and automatically add's Bob's SSH key to the
-authorized_keys file for the `bob` account.
-
-Bob's first connection to his new `bob` account on `foo.example.org`
-is seamless, because the Monkeysphere on Bob's computer automatically
-verifies the host key for `foo.example.org` for Bob. 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), or
-
-* strict centralized Certificate Authorities (much like proposed X.509
- models), or
-
-* 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".
-
-You may also be interested in [some thoughts about alternate PKIs for
-SSH](/similar).
-
-## Philosophy ##
-
-Humans (and
-[monkeys](http://www.scottmccloud.com/comics/mi/mi-17/mi-17.html))
-have the innate capacity to keep track of the identities of only a
-finite number of people. After our social sphere exceeds several dozen
-or several hundred (depending on the individual), our ability to
-remember and distinguish people begins to break down. In other words,
-at a certain point, we can't know for sure that the person we ran into
-in the produce aisle really is the same person who we met at the party
-last week.
-
-For most of us, this limitation has not posed much of a problem in our
-daily, off-line lives. With the Internet, however, we have an ability
-to interact with vastly larger numbers of people than we had
-before. In addition, on the Internet we lose many of our tricks for
-remembering and identifying people (physical characteristics, sound of
-the voice, etc.).
-
-Fortunately, with online communications we have easy access to tools
-that can help us navigate these problems.
-[OpenPGP](http://en.wikipedia.org/wiki/Openpgp) (a cryptographic
-protocol commonly used for sending signed and encrypted email
-messages) is one such tool. In its simplest form, it allows us to
-sign our communication in such a way that the recipient can verify the
-sender.
-
-OpenPGP goes beyond this simple use to implement a feature known as
-the [web of trust](http://en.wikipedia.org/wiki/Web_of_trust). The web
-of trust allows people who have never met in person to communicate
-with a reasonable degree of certainty that they are who they say they
-are. It works like this: Person A trusts Person B. Person B verifies
-Person C's identity. Then, Person A can verify Person C's identity
-because of their trust of Person B.
-
-The Monkeyshpere's broader goals are to extend the use of OpenPGP from
-email communications to other activities, such as:
-
- * conclusively identifying the remote server in a remote login session
- * granting access to servers to people we've never directly met