diff options
Diffstat (limited to 'website')
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§ion=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 Binary files differdeleted file mode 100644 index 13b5efc..0000000 --- a/website/favicon.ico +++ /dev/null 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 42d75f7..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, 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 Binary files differdeleted file mode 100644 index 33b3e78..0000000 --- a/website/logo.png +++ /dev/null diff --git a/website/logo.simple.png b/website/logo.simple.png Binary files differdeleted file mode 100644 index 5cc69eb..0000000 --- a/website/logo.simple.png +++ /dev/null diff --git a/website/logo.title.png b/website/logo.title.png Binary files differdeleted file mode 100644 index a203f8b..0000000 --- a/website/logo.title.png +++ /dev/null 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: - - - -Here is a more complex situation, involving multiple hostnames (a -common misspelling, in this instance) with different calculated -validities, and multiple certifiers: - - - -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 Binary files differdeleted file mode 100644 index c1cd5a1..0000000 --- a/website/screenshots/blanco.png +++ /dev/null diff --git a/website/screenshots/zimmerman.png b/website/screenshots/zimmerman.png Binary files differdeleted file mode 100644 index 99229dd..0000000 --- a/website/screenshots/zimmerman.png +++ /dev/null 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 |
