+++ /dev/null
-<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
-<base href="http://redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation"><div style="margin:-1px -1px 0;padding:0;border:1px solid #999;background:#fff"><div style="margin:12px;padding:8px;border:1px solid #999;background:#ddd;font:13px arial,sans-serif;color:#000;font-weight:normal;text-align:left">This is Google's cache of <a href="http://redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation" style="text-decoration:underline;color:#00c">http://redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation</a>. It is a snapshot of the page as it appeared on Dec 15, 2008 14:31:48 GMT. The <a href="http://redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation" style="text-decoration:underline;color:#00c">current page</a> could have changed in the meantime. <a href="http://www.google.com/intl/en/help/features_list.html#cached" style="text-decoration:underline;color:#00c">Learn more</a><br><br><div style="float:right"><a href="http://74.125.47.132/search?q=cache:TK3CfB0McV4J:redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation+http://redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation&hl=en&gl=us&strip=1" style="text-decoration:underline;color:#00c">Text-only version</a></div>
-<div>These terms only appear in links pointing to this page: <span style="font-weight:bold">http</span> <span style="font-weight:bold">redmine</span> <span style="font-weight:bold">josefsson</span> <span style="font-weight:bold">org</span> <span style="font-weight:bold">wiki</span> <span style="font-weight:bold">gnutls</span> <span style="font-weight:bold">gnutlsexternalvalidation</span> </div></div></div><div style="position:relative">
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
-<head>
-<title>GnuTLS - GnuTLSExternalValidation - Redmine</title>
-<meta http-equiv="content-type" content="text/html; charset=utf-8" />
-<meta name="description" content="Redmine" />
-<meta name="keywords" content="issue,bug,tracker" />
-<link href="/stylesheets/application.css?1227251496" media="all" rel="stylesheet" type="text/css" />
-<script src="/javascripts/prototype.js?1224248241" type="text/javascript"></script>
-<script src="/javascripts/effects.js?1224248241" type="text/javascript"></script>
-<script src="/javascripts/dragdrop.js?1224248241" type="text/javascript"></script>
-<script src="/javascripts/controls.js?1224248241" type="text/javascript"></script>
-<script src="/javascripts/application.js?1224248241" type="text/javascript"></script>
-<link href="/stylesheets/jstoolbar.css?1224248241" media="screen" rel="stylesheet" type="text/css" />
-<!--[if IE]>
- <style type="text/css">
- * html body{ width: expression( document.documentElement.clientWidth < 900 ? '900px' : '100%' ); }
- body {behavior: url(/stylesheets/csshover.htc?1224248241);}
- </style>
-<![endif]-->
-
-<!-- page specific tags -->
-
- <link href="/stylesheets/scm.css?1224248241" media="screen" rel="stylesheet" type="text/css" />
-</head>
-<body>
-<div id="wrapper">
-<div id="top-menu">
- <div id="account">
- <ul><li><a href="/login" class="login">Sign in</a></li>
-<li><a href="/account/register" class="register">Register</a></li></ul> </div>
-
- <ul><li><a href="/" class="home">Home</a></li>
-<li><a href="/projects" class="projects">Projects</a></li>
-<li><a href="http://www.redmine.org/guide" class="help">Help</a></li></ul></div>
-
-<div id="header">
- <div id="quick-search">
- <form action="/search/index/gnutls" method="get">
- <a href="/search/index/gnutls" accesskey="4">Search</a>:
- <input accesskey="f" class="small" id="q" name="q" size="20" type="text" />
- </form>
-
- </div>
-
- <h1>GnuTLS</h1>
-
- <div id="main-menu">
- <ul><li><a href="/projects/show/gnutls">Overview</a></li>
-<li><a href="/projects/activity/gnutls">Activity</a></li>
-<li><a href="/projects/roadmap/gnutls">Roadmap</a></li>
-<li><a href="/projects/gnutls/issues">Issues</a></li>
-<li><a href="/wiki/gnutls" class="selected">Wiki</a></li>
-<li><a href="/repositories/show/gnutls">Repository</a></li></ul>
- </div>
-</div>
-
-<div class="" id="main">
- <div id="sidebar">
-
- <h3>Wiki</h3>
-
-<a href="/wiki/gnutls">Start page</a><br />
-<a href="/wiki/gnutls/Page_index/special">Index by title</a><br />
-<a href="/wiki/gnutls/Date_index/special">Index by date</a><br />
-
-
- </div>
-
- <div id="content">
-
-
- <div class="contextual">
-
-
-
-
-
-
-
-
-<a href="/wiki/gnutls/GnuTLSExternalValidation/history" class="icon icon-history">History</a>
-</div>
-
-
-
-
-
-<div class="wiki">
- <h1 id="GnuTLSExternalValidation">GnuTLSExternalValidation<a href="#GnuTLSExternalValidation" class="wiki-anchor">¶</a></h1>
-
-
- <p>This page is intended to flesh out ideas to externalize the X.509 chain validation, X.509 private key handling, and possibly also OpenPGP validation and private key handling.</p>
-
-
- <p>It is important to realize that these are different problems, so the solution may be different. Let's first make the goals clear:</p>
-
-
- <ul>
- <li>Make it possible to store private keys in a process different from the process that runs the GnuTLS client/server.</li>
- <li>Make it possible to perform X.509 chain validation in a different process.</li>
- <li>Make it possible to perform OpenPGP key validation in a different process.</li>
- </ul>
-
-
- <p>One must decide whether the external agent should be responsible for making authentication decisions, authorization decisions, or both. Possibly it should be able to make both kind of decisions. The GnuTLS process can always make further authorization decisions as well.</p>
-
-
- <p>For private keys, there is the PKCS#11 interface. GnuTLS has a branch that supports it. However, PKCS#11 doesn't solve the problem with an external process. It seems better to move the PKCS#11 interface to the external agent, rather than adding PKCS#11 interface to GnuTLS itself. Btw, GnuTLS already has PKCS#11 support on a special branch, and has been tested against the Scute PKCS#11 provider together with a Swedish eID X.509 smartcard.</p>
-
-
- <p>The solution should allow simple integration with GNOME components such as <a href="http://live.gnome.org/Seahorse" class="external">SeaHorse</a>.</p>
-
-
- <h2 id="Private-key-protocol">Private key protocol<a href="#Private-key-protocol" class="wiki-anchor">¶</a></h2>
-
-
- <p>Possible we should re-use GnuPG's external protocol here? What we need is an IPC protocol that does:</p>
-
-
- <pre><code>SIGN [ALG] [KEY-ID] [TLS-DATA]</code></pre>
-
-
- <p>Where KEY-ID somehow denotes a key to use, and TLS-DATA is the data that needs to be signed using the TLS algorithm. Given that TLS supports several algorithms, and even RSA is supported in more than one mode, there needs to be an ALG flag to indicate this.</p>
-
-
- <h2 id="X509-Chain-Validation">X.509 Chain Validation<a href="#X509-Chain-Validation" class="wiki-anchor">¶</a></h2>
-
-
- <p>GnuPG's dirmngr <a href="http://www.gnupg.org/documentation/manuals/dirmngr/Dirmngr-Protocol.html#Dirmngr-Protocol" class="external">has a protocol for doing this</a>, using <a href="http://www.gnupg.org/documentation/manuals/assuan/" class="external">assuan</a>. Unfortunately, <a href="http://www.gnupg.org/documentation/manuals/assuan/Assuan.html#Assuan" class="external">assuan's design criteria</a> state "no protection against DoS needed". This might make it unsuitable for a TLS implementation or other online tool.</p>
-
-
- <p>It is not clear to me whether the trusted CAs should be sent over the IPC, or whether it is something that is assumed to be known by the agent. The latter seems safer, but the former may be useful in some scenarios. <em>(what scenarios?)</em> They aren't mutually incompatible, so maybe we can support both.</p>
-
-
- <p>Thus we need a command to send over a trusted certificate:</p>
-
-
- <pre><code>TRUSTED [b64pem...]</code></pre>
-
-
- <p>And also send over untrusted certificates provided by the TLS peer:</p>
-
-
- <pre><code>UNTRUSTED [b64pem...]</code></pre>
-
-
- <p>Finally, a request to perform chain validation on a particular certificate is performed using:</p>
-
-
- <pre><code>VALIDATE [b64pem...]</code></pre>
-
-
- <h2 id="Generic-Certificate-Validation">Generic Certificate Validation<a href="#Generic-Certificate-Validation" class="wiki-anchor">¶</a></h2>
-
-
- <p>It would be nice to be able to hand the agent any kind of certificate (OpenPGP or X.509), or even to be able to hand the agent a raw public key to see if it validates.</p>
-
-
- <p>The crucial request would be:</p>
-
-
- <pre><code>VALIDATE {LABEL} {CERTTYPE} {PEERNAME} {CERTIFICATE}</code></pre>
-
-
- <p>This says "I'm a program called LABEL. I'm about to send you a certificate of type CERTTYPE. I want you to tell me whether the specified PEERNAME matches one of the names stored in the certificate, and that the matching name in the certificate is cryptographically valid based on your knowledge of trusted certifiers."</p>
-
-
- <p>The agent can respond with VALID or INVALID. We maybe should consider whether INVALID might be implemented as an extensible set of reasons for invalidity (e.g. EXPIRED, NOMATCH, UNTRUSTED, SELFSIGNED, etc): would the potential extensibility from this outweigh the added implementation and semantic complexity?</p>
-
-
- <p>The possible options for CERTTYPE could be:</p>
-
-
- <ul>
- <li>RAWPUBKEY (maybe modelled after <a href="http://tools.ietf.org/html/rfc4253#section-6.6" class="external">ssh-dss and ssh-rsa in RFC 4253</a> ?)</li>
- <li>OPENPGP (after <a href="http://tools.ietf.org/html/rfc4880#section-11.1" class="external">section 11.1 of RFC 4880</a> either base-64 encoded or raw)</li>
- <li>X509 (after <a href="http://tools.ietf.org/html/rfc5280" class="external">RFC 5280</a>, either PEM or DER encoded)</li>
- </ul>
-
-
- <p>This would allow numerous clients and servers to make use of the validation agent. For example:</p>
-
-
- <ul>
- <li><a href="http://www.lysator.liu.se/~nisse/lsh/" class="external">lsh</a> could feed its fetched host keys to the validation agent instead of having to maintain ~/.lsh/host-acls</li>
- <li><a href="http://www.openldap.org/doc/admin24/tls.html#Client%20Certificates" class="external">slapd</a> could use the validation agent to identify the DN of the remote client.</li>
- <li><a href="http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn.sslcerts" class="external">subversion</a> could ask the validation agent to ensure that the OpenPGP certificate offered by a remote https server (using <a href="http://www.outoforder.cc/projects/apache/mod_gnutls/" class="external">mod_gnutls</a>) is in fact who it claims to be (and the mod_gnutls could validate the identity of the client in the same way).</li>
- </ul>
-
-
- <p>Additionally, it might be nice to have a command to offer intermediate certificates to the certificate store:</p>
-
-
- <pre><code>UNTRUSTED {LABEL} {CERTTYPE} {CERTIFICATE}</code></pre>
-
-
- <p>using UNTRUSTED with a RAWPUBKEY certificate wouldn't be a meaningful operation, but it could be used for intermediate X.509 certificates, or for the equivalent OpenPGP certificates (if such things were handy).</p>
-</div>
-
-
-
-
-
-
-<p class="other-formats">
-Also available in:
-<span><a href="/wiki/gnutls/GnuTLSExternalValidation?export=html&version=9" class="html">HTML</a></span>
-<span><a href="/wiki/gnutls/GnuTLSExternalValidation?export=txt&version=9" class="text">TXT</a></span>
-</p>
-
-
-
-
-
-
-
- </div>
-</div>
-
-<div id="ajax-indicator" style="display:none;"><span>Loading...</span></div>
-
-<div id="footer">
- Powered by <a href="http://www.redmine.org/">Redmine</a> © 2006-2008 Jean-Philippe Lang
-</div>
-</div>
-
-</body>
-</html>
+++ /dev/null
-THE MONKEYSPHERE
-================
-
-Monkeysphere is authentication layer that allows the sysadmin to
-perform authorization on OpenPGP user identities instead of on keys.
-It also allows end users to authenticate/identify the ssh server they
-are connecting to by checking the sysadmin's certification.
-
-* GENERAL GOAL - use openpgp web-of-trust to authenticate ppl for SSH
-* SPECIFIC GOAL - allow openssh to tie into pgp web-of-trust without
- modifying the openpgp spec, gpg or openssh
-* DESIGN GOALS - authentication, use the existing generic OpenSSH
- client, the admin can make it default, although end-user should be
- decide to use monkeysphere or not
-* DESIGN GOAL - use of monkeysphere should not radically change
- connecting-to-server experience
-
-Host identity piece of monkeysphere could be used without buying into
-the user authentication component.
-
-
-USE CASE
-========
-
-Dramatis Personae: http://en.wikipedia.org/wiki/Alice_and_Bob
-Backstory: http://www.conceptlabs.co.uk/alicebob.html
-
-Bob wants to sign on to the computer "mangabey.example.org" via
-monkeysphere framework. He doesn't yet have access to the machine,
-but he knows Alice, who is the admin of mangabey. Alice and Bob,
-being the conscientious netizens that they are, have already published
-their personal gpg keys to the web of trust, and being good friends,
-have both signed each other's keys and marked each others keys with
-"full" ownertrust.
-
-When Alice set up mangabey initially, she published an OpenPGP key for
-the machine with the special userid of "ssh://mangabey.example.org".
-She also signed mangabey's OpenPGP key and published this
-certification to commonly-used keyservers. Alice also configured
-mangabey to treat her own key with full ownertrust, so that it knows
-how to identify connecting users.
-
-Now, Alice creates a user account "bob" on mangabey, and puts Bob's
-userid ("Bob <bob@example.org>") in the authorized_user_ids file for
-user bob on mangabey. The monkeysphere automatically (via cron or
-inotify hook) takes each userid in bob's authorized_user_ids file, and
-looks on a keyserver to find all public keys associated with that user
-ID, with the goal of populating the authorized_keys file for
-bob@mangabey.
-
-In particular: for each key found, the server evaluates the calculated
-validity of the specified user ID based on the ownertrust rules it has
-configured ("trust alice's certifications fully", in this example).
-For each key for which the user ID in question is fully-valid, it
-extracts all DSA- or RSA-based primary or secondary keys marked with
-the authentication usage flag, and converts these OpenPGP public keys
-into ssh public keys. These keys are automatically placed into the
-authorized_keys file for bob.
-
-Bob now attempts to connect, by firing up a terminal and invoking:
-"ssh bob@mangabey.example.org". Bob's monkeysphere-enabled ssh client
-notices that mangabey.example.org isn't already available in bob's
-known_hosts file, and fetches the host key for mangabey from the
-public keyservers, with the goal of populating Bob's local known_hosts
-file.
-
-In particular: the monkeysphere queries its configured keyservers to
-find all public keys with User ID ssh://mangabey.example.org. For
-each public key found, it checks the relevant User ID's validity,
-converts any authentication-capable OpenPGP public keys into ssh
-public keys if the User ID validity is acceptable, and finally insert
-those keys into Bob's known_hosts file.
-
-On Bob's side, since mangabey's key had "full" validity (it was signed
-by Alice, whom he fully trusts), Bob's ssh client deems mangabey
-"known" and no further host key checking is required.
-
-On mangabey's side, since Bob's key has "full" validity (it had been
-signed by Alice, mangabey's trusted administrator), Bob is
-authenticated and therefore authorized to log into his account.
-
+++ /dev/null
-Next-Steps Monkeysphere Projects:
----------------------------------
-
-Detail advantages of monkeysphere: detail the race conditions in ssh,
- and how the monkeysphere can help you reduce these threat vectors:
- threat model reduction diagrams.
-
-Handle unverified monkeysphere hosts in such a way that they're not
- always removed from known_hosts file. Ask user to lsign the host
- key?
-
-Resolve the bugs listed in openpgp2ssh(1):BUGS.
-
-Understand and document the output of gpg --check-trustdb:
- gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
- gpg: depth: 0 valid: 2 signed: 20 trust: 0-, 0q, 0n, 0m, 0f, 2u
- gpg: depth: 1 valid: 20 signed: 67 trust: 15-, 0q, 1n, 3m, 1f, 0u
- gpg: next trustdb check due at 2008-10-09
-
-Understand and document the numeric values between sig! and the keyid
- in "gpg --check-sigs $KEYID" . Compare with the details found from
- "gpg --with-colons --check-sigs $KEYID". This has to do with trust
- signatures.
-
-Fix gpg's documentation to clarify the difference between validity and
- ownertrust. Include better documentation for trust signatures.
-
-Make it easier to do domain-relative ssh host trust signatures with
- gnupg. (e.g. "i trust Jamie McClelland (keyID 76CC057D) to properly
- identify ssh servers in the mayfirst.org domain") See:
- http://tools.ietf.org/html/rfc4880#section-5.2.3.21 and grep for
- "tsign" in gpg(1).
-
-Fix the order of questions when user does a tsign in gpg or gpg2.
-
-When using ssh-proxycommand, if only host keys found are expired or
- revoked, then output loud warning with prompt, or fail hard.
-
-File bug against enigmail about lack of ability to create subkeys.
-
-Test and document what happens when any filesystem that the
- monkeysphere-server relies on and modifies (/tmp, /etc, and /var?)
- fills up.
-
-Optimize keyserver access, particularly on monkeysphere-server
- update-users -- is there a way to query the keyserver all in a
- chunk?
-
-Think about packaging monkeysphere for other (non-apt-based) operating
- systems. RPM-based linux systems, FreeBSD ports, and Mac OS X seem
- like the most likely candidates.
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
-<title>Announcing the Monkeysphere</title>
-</head>
-
-<!-- This is a draft of a wider announcement for the Monkeysphere.
- dkg will probably post the final version in his blog at
- https://www.debian-administration.org/users/dkg/weblog
-
- Edits are welcome! -->
-
-<body>
-<h1>Monkeysphere: an OpenPGP-based PKI for SSH</h1>
-
-<p>Ever thought that there should be an automated way to handle ssh
-keys? Do you know the administrators of your servers, and wish that
-SSH could verify new host keys from them automatically, based on your
-personal connections to the web-of-trust? Do you wish you could
-revoke and/or rotate your old SSH authentication keys without having
-to log into every single machine you have an account on?</p>
-
-<p>Do you administer servers, and wish you could re-key them without
-sowing massive confusion among your users (or worse, encouraging bad
-security habits among them)? Do you wish you could grant access to
-your users by name, instead of by opaque string? Do you wish you
-could rapidly revoke access to a user (or compromised key) across a
-group of machines by disabling authentication for that user?</p>
-
-<p>A group of us have been working on a public key infrastructure for
-SSH. <a href="http://web.monkeysphere.info">Monkeysphere</a> makes use
-of the existing OpenPGP web-of-trust to fetch and cryptographically
-validate (and revoke!) keys. This works in both direction:
-<code>authorized_keys</code> <em>and</em> <code>known_hosts</code> are
-handled. Monkeysphere gives users and admins tools to deal with SSH
-keys by thinking about the people and machines to whom the keys
-belong, instead of requiring humans to do tedious (and error-prone)
-manual key verification.</p>
-
-<p>We have <a href="http://web.monkeysphere.info/download">debian
-packages available</a> which should install against lenny (for i386,
-amd64, powerpc, and arm architectures at the moment), <a
-href="https://lists.riseup.net/www/info/monkeysphere">a mailing
-list</a>, and open ears for good questions, suggestions and
-criticism.</p>
-
-<p>If you have a chance to give it a try (<a
-href="http://web.monkeysphere.info/getting-started-user/">as a
-user</a> or <a
-href="http://web.monkeysphere.info/getting-started-admin/">as an
-admin</a>), it would be great to <a
-href="https://lists.riseup.net/www/info/monkeysphere">get
-feedback</a>.</p>
-
-</body> </html>
+++ /dev/null
-logo.png: logo.svg
- inkscape -e logo.png logo.svg
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://web.resource.org/cc/"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- id="svg2"
- sodipodi:version="0.32"
- inkscape:version="0.43"
- width="200"
- height="200"
- sodipodi:docbase="C:\Documents and Settings\clint\My Documents\Working\Chinese Zodiac"
- sodipodi:docname="monkey.svg"
- version="1.0">
- <metadata
- id="metadata7">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <defs
- id="defs5" />
- <sodipodi:namedview
- inkscape:window-height="540"
- inkscape:window-width="749"
- inkscape:pageshadow="2"
- inkscape:pageopacity="0.0"
- borderopacity="1.0"
- bordercolor="#666666"
- pagecolor="#ffffff"
- id="base"
- inkscape:showpageshadow="false"
- inkscape:zoom="0.71078191"
- inkscape:cx="186.89786"
- inkscape:cy="180.28334"
- inkscape:window-x="66"
- inkscape:window-y="66"
- inkscape:current-layer="svg2" />
- <path
- style="fill:#000000"
- d="M 123.78062,197.77013 C 159.09976,188.37786 185.23571,164.11558 196.09485,130.64001 C 201.32083,114.52987 201.29925,90.989024 196.04443,75.638354 C 184.27168,41.247215 160.13061,18.721762 125.38252,9.7053782 C 118.10971,7.8182612 109.44267,4.8466272 106.12247,3.1017942 C 100.01352,-0.10860683 93.617589,-0.82563983 86.882849,0.94482717 L 83.189129,1.9158772 L 86.882849,4.9388272 C 91.458489,8.6835112 89.426889,9.0066112 83.847679,5.4215272 C 79.903219,2.8869102 79.552029,2.9569602 75.684349,7.0496782 C 73.461519,9.4018782 70.467849,11.326395 69.031799,11.326395 C 67.595729,11.326395 61.265769,13.872295 54.965229,16.983946 C 47.411809,20.714329 43.287759,21.988613 42.858209,20.724829 C 41.956259,18.071229 26.658809,30.845814 26.658809,34.252581 C 26.658809,35.736965 23.768089,40.527332 20.234979,44.897832 C 6.2102795,62.246654 0.26075947,79.936054 0.0082094708,105.03722 C -0.18004053,123.74526 2.8336195,135.23544 12.267789,151.77971 C 24.120559,172.56528 50.120429,191.44391 75.568519,197.74272 C 87.681119,200.74078 112.55646,200.75493 123.78062,197.77013 z M 79.282929,192.6597 C 36.849809,183.25731 5.0762095,145.86533 5.0762095,105.33144 C 5.0762095,86.164734 13.388709,61.634564 24.123259,49.12355 C 28.386729,44.154482 28.480279,44.131382 33.344849,46.845766 C 38.724779,49.847733 39.914959,53.658304 35.472609,53.658304 C 33.010859,53.658304 33.061999,53.975554 35.887659,56.233454 C 39.066199,58.773334 39.064899,58.795564 35.789929,57.857614 C 32.469549,56.906614 32.469549,56.906614 35.789929,59.286484 C 41.847209,63.627934 53.222049,78.519284 53.222049,82.107784 C 53.222049,88.196034 70.152599,91.034974 83.599169,87.201424 C 94.360849,84.133304 95.658249,82.748784 93.382439,76.761174 C 92.466939,74.352654 91.159549,70.916704 90.477049,69.125754 C 89.794589,67.334774 89.411799,64.507204 89.626439,62.842224 C 89.860799,61.024154 89.299569,60.249604 88.221389,60.903114 C 87.233969,61.501584 86.426089,63.323654 86.426089,64.952124 C 86.426089,69.998474 82.097379,72.098224 73.951419,71.003234 C 67.959569,70.197834 66.503649,70.483684 66.503649,72.465654 C 66.503649,73.820624 68.184619,75.591824 70.239119,76.401684 C 72.766969,77.398134 73.101029,77.907534 71.272499,77.977354 C 68.253119,78.092674 64.762299,74.617084 64.213349,70.948904 C 64.015049,69.623934 60.425469,65.178654 56.236479,61.070554 C 47.167399,52.176534 44.049899,45.704583 45.818899,39.443598 C 46.519609,36.963648 46.937129,33.381964 46.746729,31.484331 C 46.507959,29.10468 48.102829,27.056564 51.886559,24.883747 C 60.770649,19.781963 71.484269,16.021345 71.484269,18.004596 C 71.484269,18.976662 69.922999,20.172396 68.014779,20.661779 C 65.227729,21.376546 64.752449,22.387363 65.598419,25.800847 C 66.177649,28.137947 66.944779,31.881797 67.303219,34.120514 C 67.661629,36.359215 68.318279,39.656215 68.762469,41.447182 C 69.206629,43.238166 69.627179,45.619299 69.697029,46.738666 C 69.766899,47.858033 71.634469,48.773866 73.847199,48.773866 C 76.059929,48.773866 80.089979,50.605533 82.802899,52.844254 C 90.034649,58.811864 96.148739,58.160404 105.72227,50.402003 C 111.41022,45.792466 115.31626,43.889416 119.08931,43.889416 C 123.67007,43.889416 124.32219,43.390999 123.72437,40.346715 C 123.34174,38.398248 123.82251,35.865981 124.79272,34.719498 C 125.79327,33.537198 125.95876,31.723281 125.17506,30.528514 C 124.41509,29.369897 123.79046,26.223963 123.78697,23.53753 C 123.78199,19.714096 122.96919,18.540046 120.04516,18.132796 C 117.99066,17.846646 116.30971,16.582812 116.30971,15.324245 C 116.30971,11.920145 124.70971,13.908395 140.38263,21.022129 C 163.16506,31.362864 181.49048,51.228864 189.61263,74.390824 C 195.1624,90.217124 194.96253,116.37997 189.16775,132.62721 C 178.6411,162.14159 154.28093,183.8794 122.61564,192.01503 C 107.54077,195.88818 94.714189,196.07902 79.282929,192.6597 z M 118.80001,190.36823 C 161.16361,180.33591 189.85438,147.61118 189.64067,109.5672 C 189.5222,88.475904 184.279,74.387584 171.08953,59.720804 C 162.44654,50.109803 153.11891,43.760882 141.21273,39.385048 C 136.19061,37.539282 130.72979,35.504548 129.07752,34.863465 C 126.44589,33.842314 126.13714,34.480998 126.58724,40.014715 L 127.10102,46.331649 L 120.07907,46.830666 C 114.90861,47.198116 111.74486,48.616633 108.08015,52.210584 C 103.11715,57.077784 98.069619,70.005554 98.023019,77.969034 C 97.977649,85.721904 94.326769,89.572554 82.275569,94.578174 L 70.654179,99.405244 L 61.272229,96.674644 C 44.355829,91.751154 31.026829,96.284024 20.909789,110.40089 C 16.426359,116.65689 15.868739,118.72946 15.878729,129.10054 C 15.888189,138.95072 16.650329,142.11364 20.779939,149.44158 C 26.169189,159.00464 41.076199,173.42263 52.161449,179.7936 C 65.181629,187.27663 77.844449,190.63711 95.557189,191.3101 C 104.6883,191.65701 115.14757,191.23316 118.80001,190.36823 z M 81.376149,184.86223 C 50.491249,179.45816 23.455039,155.95864 20.562039,132.00337 C 18.491389,114.85744 31.725159,100.1769 49.252029,100.1769 C 61.358429,100.1769 63.237149,102.46234 55.740399,108.06999 C 52.475729,110.512 48.519029,113.83085 46.947779,115.44517 C 45.376509,117.05949 42.490649,118.86179 40.534729,119.45032 C 38.578809,120.03882 36.578829,122.01929 36.090309,123.85132 C 35.471879,126.17052 35.868899,126.93139 37.397359,126.35617 C 39.042459,125.73709 39.418109,127.03091 38.896349,131.51906 C 38.355159,136.17427 39.131549,138.59587 42.382409,142.39253 C 45.458699,145.98523 46.566929,146.54888 46.572979,144.52379 C 46.577529,143.00956 45.834149,141.31781 44.921029,140.76439 C 42.134799,139.07564 43.063299,136.94927 46.826729,136.40019 C 50.807549,135.81937 54.632279,131.02169 52.657999,129.08552 C 51.955829,128.39689 50.715449,128.89004 49.901649,130.18141 C 49.087829,131.47276 47.949079,132.06556 47.371099,131.49874 C 46.793109,130.93192 48.620209,128.80047 51.431329,126.76227 C 54.242449,124.72406 56.542449,121.72887 56.542449,120.10631 C 56.542449,118.24162 57.764109,117.15619 59.862849,117.15619 C 61.689069,117.15619 63.235769,116.24036 63.299949,115.12102 C 63.364119,114.00165 64.058699,114.55114 64.843449,116.34212 C 66.063549,119.12659 66.287179,119.18557 66.386979,116.74914 C 66.451149,115.18206 67.330679,113.89989 68.341479,113.89989 C 69.352299,113.89989 69.734399,115.03694 69.190599,116.42667 C 68.623649,117.87561 68.901969,118.52914 69.843069,117.95874 C 70.745729,117.41166 71.484269,115.90826 71.484269,114.61787 C 71.484269,113.3275 72.231349,112.27174 73.144469,112.27174 C 75.265029,112.27174 75.235919,113.32375 73.001969,117.41729 C 71.408079,120.33804 71.600369,120.59579 74.662169,119.64276 C 77.788179,118.66977 78.125069,119.21429 78.125069,125.23952 C 78.125069,139.25676 70.388579,148.70421 57.338179,150.62343 C 43.165759,152.70769 29.979209,141.73643 29.979209,127.86066 C 29.979209,119.37832 33.503749,114.40967 42.217559,110.60777 C 47.575529,108.27002 48.238199,107.5922 45.253649,107.50232 C 32.617029,107.12164 23.304529,121.32604 26.649059,135.87991 C 28.650189,144.58801 38.693149,153.83571 47.784909,155.34209 C 69.735979,158.97911 87.898219,139.99054 83.166049,118.35122 C 81.748299,111.86805 81.815469,109.78255 83.476169,108.72217 C 88.269599,105.66152 91.895099,108.14182 94.614189,116.34212 C 97.844699,126.08472 106.36427,138.97744 118.03759,151.78888 C 130.14446,165.07616 127.13011,169.36506 109.83565,163.45891 C 102.57235,160.97844 93.066889,161.56969 93.066889,164.50193 C 93.066889,165.32626 95.725819,166.00071 98.975569,166.00071 C 102.49195,166.00071 104.46882,166.65991 103.8582,167.62886 C 103.29385,168.52435 100.28675,169.25701 97.175739,169.25701 C 91.153769,169.25701 79.785279,173.7833 79.785279,176.1809 C 79.785279,177.93596 86.063299,176.14071 90.530939,173.10808 C 92.332089,171.8855 94.946889,170.89766 96.341649,170.91293 C 97.736419,170.92821 95.142139,173.11373 90.576599,175.76963 C 86.011039,178.42551 83.396219,180.58506 84.765869,180.56861 C 86.135539,180.55215 89.123899,179.49161 91.406689,178.21183 C 93.689449,176.93208 96.677839,175.89216 98.047489,175.90088 C 99.417149,175.90963 97.175889,177.68221 93.066889,179.84 C 88.143889,182.42523 86.728389,183.76863 88.916389,183.7791 C 90.742599,183.78783 94.104519,182.7479 96.387289,181.46815 C 98.670069,180.18838 104.37844,179.11533 109.07255,179.08361 C 113.91056,179.05091 120.74204,177.63096 124.84447,175.80536 C 128.82491,174.03408 133.83252,172.56875 135.97249,172.54906 C 138.44834,172.52633 140.17916,171.32906 140.73168,169.25701 C 141.20924,167.46605 142.44671,165.98949 143.48161,165.97578 C 144.51649,165.96208 144.24259,165.24063 142.87293,164.37256 C 140.65933,162.96964 140.65933,162.79084 142.87293,162.76324 C 144.24259,162.74621 143.06241,161.35629 140.25033,159.67458 C 134.74511,156.38233 133.00801,152.99206 128.56996,136.87839 C 125.22302,124.72627 116.60342,114.52734 108.30435,112.89959 C 105.43205,112.3362 103.48752,111.23179 103.98312,110.44535 C 105.18517,108.53797 109.32689,108.62984 111.81424,110.61907 C 112.91707,111.50102 116.11287,114.01945 118.91599,116.21552 C 124.43834,120.54194 127.93652,127.40739 132.01504,141.92361 C 135.09866,152.89883 142.37758,159.52268 151.88256,160.00308 C 155.13706,160.16759 157.80319,160.82794 157.80729,161.47054 C 157.81826,163.19119 141.42618,174.89283 133.74182,178.6499 C 127.99057,181.46185 123.22006,182.72918 105.5184,186.1477 C 99.319519,187.34481 93.921919,187.05741 81.376149,184.86223 z M 134.10811,167.5643 C 134.59512,165.73779 135.36457,164.60719 135.81796,165.05184 C 136.71613,165.93266 135.12966,170.88515 133.94936,170.88515 C 133.54962,170.88515 133.62106,169.39076 134.10811,167.5643 z M 165.33958,158.92576 C 165.97373,153.26034 169.66896,148.31063 173.07643,148.56236 C 176.91783,148.84613 176.9176,148.84729 171.5114,156.34394 C 166.23988,163.65383 164.74011,164.28123 165.33958,158.92576 z M 103.0281,130.89937 C 103.0281,130.50449 103.7752,130.18141 104.6883,130.18141 C 105.6014,130.18141 106.3485,130.95731 106.3485,131.90564 C 106.3485,132.85397 105.6014,133.17707 104.6883,132.62362 C 103.7752,132.07021 103.0281,131.29427 103.0281,130.89937 z M 154.58961,100.06782 C 151.59393,92.700994 144.96764,84.897154 139.24303,81.993984 C 134.49112,79.584154 133.66637,79.613424 127.72652,82.402734 C 124.20756,84.055224 121.31986,85.774834 121.30936,86.224124 C 121.29889,86.673404 124.54797,88.735824 128.52956,90.807254 C 137.59313,95.522654 146.78318,104.65004 150.98254,113.10714 C 152.75531,116.67737 153.92959,119.87186 153.59206,120.20609 C 153.25454,120.54029 149.44896,117.76702 145.13523,114.0432 C 140.82151,110.31942 132.73299,105.13885 127.16077,102.5308 C 119.97857,99.169244 116.95541,96.825524 116.77519,94.479404 C 116.63541,92.659154 117.22329,90.744244 118.08164,90.223994 C 118.94001,89.703744 119.18544,87.492924 118.62706,85.311134 C 118.06867,83.129284 118.04899,80.226934 118.58329,78.861424 C 119.38236,76.819254 120.13421,76.733554 122.81997,78.378474 C 125.53514,80.041374 126.66017,79.867934 129.49846,77.348924 C 131.37576,75.682774 132.91172,72.601474 132.91172,70.501534 C 132.91172,68.401654 133.71819,66.683524 134.70382,66.683524 C 135.85601,66.683524 136.08317,68.573004 135.33999,71.975024 C 134.70421,74.885334 134.76112,76.725084 135.46644,76.063354 C 136.17176,75.401654 137.35678,72.104654 138.09976,68.736674 C 139.28606,63.359374 139.35709,63.605224 138.68274,70.753884 C 138.14876,76.414424 138.40943,78.150584 139.53833,76.452424 C 140.43128,75.109184 141.19604,71.445854 141.23779,68.311674 C 141.30079,63.581854 141.60631,63.106174 143.03501,65.513404 C 144.24146,67.546174 144.17873,70.130004 142.82519,74.152004 C 140.98624,79.616534 141.16559,80.148974 146.58359,85.309254 C 154.75253,93.089704 158.39734,101.58469 158.85056,113.89989 L 159.24003,124.48287 L 157.90646,114.71395 C 157.17303,109.34107 155.68043,102.7503 154.58961,100.06782 z M 111.40521,99.107094 C 112.42442,97.239454 113.66366,96.108844 114.15902,96.594654 C 115.52746,97.936674 113.33547,102.50284 111.32279,102.50284 C 110.09497,102.50284 110.12024,101.4617 111.40521,99.107094 z M 174.67961,70.094054 C 166.22248,57.294484 155.47173,49.593166 137.23964,43.273966 C 131.26124,41.201865 136.03302,40.315999 142.34664,42.325899 C 151.44281,45.221582 164.68136,54.192204 170.41248,61.343684 C 175.90481,68.197204 181.05756,75.876924 181.05756,77.209204 C 181.05756,79.200424 179.68403,77.668104 174.67961,70.094054 z M 86.141749,52.591884 C 84.471899,51.109864 83.105669,47.794733 83.105669,45.224916 C 83.105669,41.739149 82.051599,40.159499 78.955169,39.004965 C 74.632979,37.393381 74.274849,36.497348 74.725269,28.421964 C 75.018719,23.16123 80.031279,17.838996 84.692499,17.838996 C 86.276039,17.838996 88.924239,19.304729 90.577419,21.096179 L 93.583119,24.353347 L 95.909449,21.096179 C 98.550519,17.398329 105.98322,16.752812 109.98009,19.874179 C 113.38211,22.53103 114.97277,33.114248 112.44671,36.285265 C 111.37546,37.629998 109.00482,38.988832 107.1786,39.304865 C 104.73077,39.728465 103.98519,40.948599 104.34145,43.947866 C 105.39222,52.794264 93.000969,58.679564 86.141749,52.591884 z M 106.28815,31.749614 C 108.75279,28.83723 107.19042,25.979763 103.1334,25.979763 C 99.474569,25.979763 95.690219,30.069064 97.172449,32.421031 C 98.727369,34.888398 103.95792,34.503131 106.28815,31.749614 z M 90.425419,32.732231 C 90.906619,31.968664 90.333489,30.047214 89.151749,28.462314 C 86.716239,25.195847 79.785279,26.32308 79.785279,29.985681 C 79.785279,33.461881 88.541219,35.722065 90.425419,32.732231 z M 95.562249,27.59988 C 97.539549,24.462297 103.64145,22.997113 107.1786,24.810563 C 110.1487,26.33328 110.25862,26.227097 108.22047,23.804096 C 105.18654,20.197279 100.882,20.380446 97.293589,24.26903 C 94.392499,27.412797 94.321239,27.41113 89.742219,24.09108 C 86.116319,21.462079 84.454999,21.118113 82.037369,22.49598 C 79.320219,24.044546 79.529569,24.258463 83.805049,24.30208 C 86.472489,24.329313 89.946999,25.498347 91.526189,26.89988 C 93.565689,28.70998 94.734869,28.91273 95.562249,27.59988 z M 39.940429,34.216581 C 39.940429,33.373964 40.687509,32.231748 41.600649,31.678281 C 42.513749,31.124847 43.260849,31.814264 43.260849,33.210348 C 43.260849,34.606414 42.513749,35.748648 41.600649,35.748648 C 40.687509,35.748648 39.940429,35.059215 39.940429,34.216581 z M 68.821019,24.792563 C 70.508649,23.13753 71.901099,25.62923 70.516449,27.82643 C 69.470469,29.486197 69.079419,29.48748 68.517079,27.832997 C 68.132579,26.701763 68.269369,25.333563 68.821019,24.792563 z M 117.96991,24.351613 C 117.96991,23.456113 118.71701,22.723446 119.63011,22.723446 C 120.54322,22.723446 121.29032,23.456113 121.29032,24.351613 C 121.29032,25.24708 120.54322,25.979763 119.63011,25.979763 C 118.71701,25.979763 117.96991,25.24708 117.96991,24.351613 z M 94.727089,2.9934602 C 94.727089,2.0979772 95.474169,1.8181102 96.387289,2.3715602 C 97.300399,2.9249942 98.047489,4.1104942 98.047489,5.0059612 C 98.047489,5.9014442 97.300399,6.1813112 96.387289,5.6278772 C 95.474169,5.0744272 94.727089,3.8889442 94.727089,2.9934602 z M 89.534719,3.5926612 C 87.469639,1.0103272 87.528349,0.95274417 90.161539,2.9779442 C 91.759489,4.2069772 93.066889,5.4891442 93.066889,5.8272442 C 93.066889,7.1672612 91.703539,6.3047612 89.534719,3.5926612 z "
- id="path1308" />
-</svg>
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- width="343"
- height="85"
- id="svg2"
- sodipodi:version="0.32"
- inkscape:version="0.46"
- version="1.0"
- sodipodi:docname="logo.svg"
- inkscape:output_extension="org.inkscape.output.svg.inkscape">
- <defs
- id="defs4">
- <inkscape:perspective
- sodipodi:type="inkscape:persp3d"
- inkscape:vp_x="0 : 495 : 1"
- inkscape:vp_y="0 : 1000 : 0"
- inkscape:vp_z="765 : 495 : 1"
- inkscape:persp3d-origin="382.5 : 330 : 1"
- id="perspective11" />
- <inkscape:perspective
- id="perspective2456"
- inkscape:persp3d-origin="100 : 66.666667 : 1"
- inkscape:vp_z="200 : 100 : 1"
- inkscape:vp_y="0 : 1000 : 0"
- inkscape:vp_x="0 : 100 : 1"
- sodipodi:type="inkscape:persp3d" />
- <inkscape:perspective
- id="perspective2514"
- inkscape:persp3d-origin="372.04724 : 350.78739 : 1"
- inkscape:vp_z="744.09448 : 526.18109 : 1"
- inkscape:vp_y="0 : 1000 : 0"
- inkscape:vp_x="0 : 526.18109 : 1"
- sodipodi:type="inkscape:persp3d" />
- </defs>
- <sodipodi:namedview
- inkscape:document-units="in"
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1.0"
- inkscape:pageopacity="0.0"
- inkscape:pageshadow="2"
- inkscape:zoom="2.6997085"
- inkscape:cx="171.5"
- inkscape:cy="42.5"
- inkscape:current-layer="layer1"
- id="namedview6"
- showgrid="false"
- inkscape:window-width="1022"
- inkscape:window-height="745"
- inkscape:window-x="0"
- inkscape:window-y="-17" />
- <metadata
- id="metadata8">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <g
- inkscape:label="Layer 1"
- inkscape:groupmode="layer"
- id="layer1"
- transform="translate(-50.000004,-73.33332)">
- <g
- id="g2387"
- transform="matrix(0.5365886,0,0,0.5365886,17.937823,35.82463)">
- <path
- transform="matrix(0.8326217,0,0,0.8326217,17.150517,28.939396)"
- d="M 110.0912,92.488266 A 28.865374,28.865374 0 1 1 52.360449,92.488266 A 28.865374,28.865374 0 1 1 110.0912,92.488266 z"
- sodipodi:ry="28.865374"
- sodipodi:rx="28.865374"
- sodipodi:cy="92.488266"
- sodipodi:cx="81.225822"
- id="path2468"
- style="fill:#f69143;fill-opacity:1;stroke:none;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:0.83185838"
- sodipodi:type="arc" />
- <path
- style="fill:#000000"
- d="M 173.78063,271.10345 C 209.09977,261.71118 235.23572,237.4489 246.09486,203.97333 C 251.32084,187.86319 251.29926,164.32234 246.04444,148.97167 C 234.27169,114.58053 210.13062,92.055083 175.38253,83.038703 C 168.10972,81.151583 159.44268,78.179943 156.12248,76.435113 C 150.01353,73.224713 143.6176,72.507683 136.88286,74.278143 L 133.18914,75.249193 L 136.88286,78.272143 C 141.4585,82.016833 139.4269,82.339933 133.84769,78.754843 C 129.90323,76.220233 129.55204,76.290283 125.68436,80.383003 C 123.46153,82.735203 120.46786,84.659713 119.03181,84.659713 C 117.59574,84.659713 111.26578,87.205613 104.96524,90.317263 C 97.411823,94.047653 93.287773,95.321933 92.858223,94.058153 C 91.956273,91.404553 76.658823,104.17913 76.658823,107.5859 C 76.658823,109.07028 73.768103,113.86065 70.234993,118.23115 C 56.210293,135.57997 50.260773,153.26937 50.008223,178.37054 C 49.819973,197.07858 52.833633,208.56876 62.267803,225.11303 C 74.120573,245.8986 100.12044,264.77723 125.56853,271.07604 C 137.68113,274.0741 162.55647,274.08825 173.78063,271.10345 z M 129.28294,265.99302 C 86.849823,256.59063 55.076223,219.19865 55.076223,178.66476 C 55.076223,159.49805 63.388723,134.96788 74.123273,122.45687 C 78.386743,117.4878 78.480293,117.4647 83.344863,120.17908 C 88.724793,123.18105 89.914973,126.99162 85.472623,126.99162 C 83.010873,126.99162 83.062013,127.30887 85.887673,129.56677 C 89.066213,132.10665 89.064913,132.12888 85.789943,131.19093 C 82.469563,130.23993 82.469563,130.23993 85.789943,132.6198 C 91.847223,136.96125 103.22206,151.8526 103.22206,155.4411 C 103.22206,161.52935 120.15261,164.36829 133.59918,160.53474 C 144.36086,157.46662 145.65826,156.0821 143.38245,150.09449 C 142.46695,147.68597 141.15956,144.25002 140.47706,142.45907 C 139.7946,140.66809 139.41181,137.84052 139.62645,136.17554 C 139.86081,134.35747 139.29958,133.58292 138.2214,134.23643 C 137.23398,134.8349 136.4261,136.65697 136.4261,138.28544 C 136.4261,143.33179 132.09739,145.43154 123.95143,144.33655 C 117.95958,143.53115 116.50366,143.817 116.50366,145.79897 C 116.50366,147.15394 118.18463,148.92514 120.23913,149.735 C 122.76698,150.73145 123.10104,151.24085 121.27251,151.31067 C 118.25313,151.42599 114.76231,147.9504 114.21336,144.28222 C 114.01506,142.95725 110.42548,138.51197 106.23649,134.40387 C 97.167413,125.50985 94.049913,119.0379 95.818913,112.77692 C 96.519623,110.29697 96.937143,106.71528 96.746743,104.81765 C 96.507973,102.438 98.102843,100.38988 101.88657,98.217063 C 110.77066,93.115283 121.48428,89.354663 121.48428,91.337913 C 121.48428,92.309983 119.92301,93.505713 118.01479,93.995103 C 115.22774,94.709863 114.75246,95.720683 115.59843,99.134163 C 116.17766,101.47126 116.94479,105.21511 117.30323,107.45383 C 117.66164,109.69253 118.31829,112.98953 118.76248,114.7805 C 119.20664,116.57148 119.62719,118.95262 119.69704,120.07198 C 119.76691,121.19135 121.63448,122.10718 123.84721,122.10718 C 126.05994,122.10718 130.08999,123.93885 132.80291,126.17757 C 140.03466,132.14518 146.14875,131.49372 155.72228,123.73532 C 161.41023,119.12578 165.31627,117.22273 169.08932,117.22273 C 173.67008,117.22273 174.3222,116.72432 173.72438,113.68003 C 173.34175,111.73157 173.82252,109.1993 174.79273,108.05282 C 175.79328,106.87052 175.95877,105.0566 175.17507,103.86183 C 174.4151,102.70321 173.79047,99.557283 173.78698,96.870853 C 173.782,93.047413 172.9692,91.873363 170.04517,91.466113 C 167.99067,91.179963 166.30972,89.916133 166.30972,88.657563 C 166.30972,85.253463 174.70972,87.241713 190.38264,94.355453 C 213.16507,104.69618 231.49049,124.56218 239.61264,147.72414 C 245.16241,163.55044 244.96254,189.71329 239.16776,205.96053 C 228.64111,235.47491 204.28094,257.21272 172.61565,265.34835 C 157.54078,269.2215 144.7142,269.41234 129.28294,265.99302 z M 168.80002,263.70155 C 211.16362,253.66923 239.85439,220.9445 239.64068,182.90052 C 239.52221,161.80922 234.27901,147.7209 221.08954,133.05412 C 212.44655,123.44312 203.11892,117.0942 191.21274,112.71837 C 186.19062,110.8726 180.7298,108.83787 179.07753,108.19678 C 176.4459,107.17563 176.13715,107.81432 176.58725,113.34803 L 177.10103,119.66497 L 170.07908,120.16398 C 164.90862,120.53143 161.74487,121.94995 158.08016,125.5439 C 153.11716,130.4111 148.06963,143.33887 148.02303,151.30235 C 147.97766,159.05522 144.32678,162.90587 132.27558,167.91149 L 120.65419,172.73856 L 111.27224,170.00796 C 94.355843,165.08447 81.026843,169.61734 70.909803,183.73421 C 66.426373,189.99021 65.868753,192.06278 65.878743,202.43386 C 65.888203,212.28404 66.650343,215.44696 70.779953,222.7749 C 76.169203,232.33796 91.076213,246.75595 102.16146,253.12692 C 115.18164,260.60995 127.84446,263.97043 145.5572,264.64342 C 154.68831,264.99033 165.14758,264.56648 168.80002,263.70155 z M 131.37616,258.19555 C 100.49126,252.79148 73.455053,229.29196 70.562053,205.33669 C 68.491403,188.19076 81.725173,173.51022 99.252043,173.51022 C 111.35844,173.51022 113.23716,175.79566 105.74041,181.40331 C 102.47574,183.84532 98.519043,187.16417 96.947793,188.77849 C 95.376523,190.39281 92.490663,192.19511 90.534743,192.78364 C 88.578823,193.37214 86.578843,195.35261 86.090323,197.18464 C 85.471893,199.50384 85.868913,200.26471 87.397373,199.68949 C 89.042473,199.07041 89.418123,200.36423 88.896363,204.85238 C 88.355173,209.50759 89.131563,211.92919 92.382423,215.72585 C 95.458713,219.31855 96.566943,219.8822 96.572993,217.85711 C 96.577543,216.34288 95.834163,214.65113 94.921043,214.09771 C 92.134813,212.40896 93.063313,210.28259 96.826743,209.73351 C 100.80756,209.15269 104.63229,204.35501 102.65801,202.41884 C 101.95584,201.73021 100.71546,202.22336 99.901663,203.51473 C 99.087843,204.80608 97.949093,205.39888 97.371113,204.83206 C 96.793123,204.26524 98.620223,202.13379 101.43134,200.09559 C 104.24246,198.05738 106.54246,195.06219 106.54246,193.43963 C 106.54246,191.57494 107.76412,190.48951 109.86286,190.48951 C 111.68908,190.48951 113.23578,189.57368 113.29996,188.45434 C 113.36413,187.33497 114.05871,187.88446 114.84346,189.67544 C 116.06356,192.45991 116.28719,192.51889 116.38699,190.08246 C 116.45116,188.51538 117.33069,187.23321 118.34149,187.23321 C 119.35231,187.23321 119.73441,188.37026 119.19061,189.75999 C 118.62366,191.20893 118.90198,191.86246 119.84308,191.29206 C 120.74574,190.74498 121.48428,189.24158 121.48428,187.95119 C 121.48428,186.66082 122.23136,185.60506 123.14448,185.60506 C 125.26504,185.60506 125.23593,186.65707 123.00198,190.75061 C 121.40809,193.67136 121.60038,193.92911 124.66218,192.97608 C 127.78819,192.00309 128.12508,192.54761 128.12508,198.57284 C 128.12508,212.59008 120.38859,222.03753 107.33819,223.95675 C 93.165773,226.04101 79.979223,215.06975 79.979223,201.19398 C 79.979223,192.71164 83.503763,187.74299 92.217573,183.94109 C 97.575543,181.60334 98.238213,180.92552 95.253663,180.83564 C 82.617043,180.45496 73.304543,194.65936 76.649073,209.21323 C 78.650203,217.92133 88.693163,227.16903 97.784923,228.67541 C 119.73599,232.31243 137.89823,213.32386 133.16606,191.68454 C 131.74831,185.20137 131.81548,183.11587 133.47618,182.05549 C 138.26961,178.99484 141.89511,181.47514 144.6142,189.67544 C 147.84471,199.41804 156.36428,212.31076 168.0376,225.1222 C 180.14447,238.40948 177.13012,242.69838 159.83566,236.79223 C 152.57236,234.31176 143.0669,234.90301 143.0669,237.83525 C 143.0669,238.65958 145.72583,239.33403 148.97558,239.33403 C 152.49196,239.33403 154.46883,239.99323 153.85821,240.96218 C 153.29386,241.85767 150.28676,242.59033 147.17575,242.59033 C 141.15378,242.59033 129.78529,247.11662 129.78529,249.51422 C 129.78529,251.26928 136.06331,249.47403 140.53095,246.4414 C 142.3321,245.21882 144.9469,244.23098 146.34166,244.24625 C 147.73643,244.26153 145.14215,246.44705 140.57661,249.10295 C 136.01105,251.75883 133.39623,253.91838 134.76588,253.90193 C 136.13555,253.88547 139.12391,252.82493 141.4067,251.54515 C 143.68946,250.2654 146.67785,249.22548 148.0475,249.2342 C 149.41716,249.24295 147.1759,251.01553 143.0669,253.17332 C 138.1439,255.75855 136.7284,257.10195 138.9164,257.11242 C 140.74261,257.12115 144.10453,256.08122 146.3873,254.80147 C 148.67008,253.5217 154.37845,252.44865 159.07256,252.41693 C 163.91057,252.38423 170.74205,250.96428 174.84448,249.13868 C 178.82492,247.3674 183.83253,245.90207 185.9725,245.88238 C 188.44835,245.85965 190.17917,244.66238 190.73169,242.59033 C 191.20925,240.79937 192.44672,239.32281 193.48162,239.3091 C 194.5165,239.2954 194.2426,238.57395 192.87294,237.70588 C 190.65934,236.30296 190.65934,236.12416 192.87294,236.09656 C 194.2426,236.07953 193.06242,234.68961 190.25034,233.0079 C 184.74512,229.71565 183.00802,226.32538 178.56997,210.21171 C 175.22303,198.05959 166.60343,187.86066 158.30436,186.23291 C 155.43206,185.66952 153.48753,184.56511 153.98313,183.77867 C 155.18518,181.87129 159.3269,181.96316 161.81425,183.95239 C 162.91708,184.83434 166.11288,187.35277 168.916,189.54884 C 174.43835,193.87526 177.93653,200.74071 182.01505,215.25693 C 185.09867,226.23215 192.37759,232.856 201.88257,233.3364 C 205.13707,233.50091 207.8032,234.16126 207.8073,234.80386 C 207.81827,236.52451 191.42619,248.22615 183.74183,251.98322 C 177.99058,254.79517 173.22007,256.0625 155.51841,259.48102 C 149.31953,260.67813 143.92193,260.39073 131.37616,258.19555 z M 184.10812,240.89762 C 184.59513,239.07111 185.36458,237.94051 185.81797,238.38516 C 186.71614,239.26598 185.12967,244.21847 183.94937,244.21847 C 183.54963,244.21847 183.62107,242.72408 184.10812,240.89762 z M 215.33959,232.25908 C 215.97374,226.59366 219.66897,221.64395 223.07644,221.89568 C 226.91784,222.17945 226.91761,222.18061 221.51141,229.67726 C 216.23989,236.98715 214.74012,237.61455 215.33959,232.25908 z M 153.02811,204.23269 C 153.02811,203.83781 153.77521,203.51473 154.68831,203.51473 C 155.60141,203.51473 156.34851,204.29063 156.34851,205.23896 C 156.34851,206.18729 155.60141,206.51039 154.68831,205.95694 C 153.77521,205.40353 153.02811,204.62759 153.02811,204.23269 z M 204.58962,173.40114 C 201.59394,166.03431 194.96765,158.23047 189.24304,155.3273 C 184.49113,152.91747 183.66638,152.94674 177.72653,155.73605 C 174.20757,157.38854 171.31987,159.10815 171.30937,159.55744 C 171.2989,160.00672 174.54798,162.06914 178.52957,164.14057 C 187.59314,168.85597 196.78319,177.98336 200.98255,186.44046 C 202.75532,190.01069 203.9296,193.20518 203.59207,193.53941 C 203.25455,193.87361 199.44897,191.10034 195.13524,187.37652 C 190.82152,183.65274 182.733,178.47217 177.16078,175.86412 C 169.97858,172.50256 166.95542,170.15884 166.7752,167.81272 C 166.63542,165.99247 167.2233,164.07756 168.08165,163.55731 C 168.94002,163.03706 169.18545,160.82624 168.62707,158.64445 C 168.06868,156.4626 168.049,153.56025 168.5833,152.19474 C 169.38237,150.15257 170.13422,150.06687 172.81998,151.71179 C 175.53515,153.37469 176.66018,153.20125 179.49847,150.68224 C 181.37577,149.01609 182.91173,145.93479 182.91173,143.83485 C 182.91173,141.73497 183.7182,140.01684 184.70383,140.01684 C 185.85602,140.01684 186.08318,141.90632 185.34,145.30834 C 184.70422,148.21865 184.76113,150.0584 185.46645,149.39667 C 186.17177,148.73497 187.35679,145.43797 188.09977,142.06999 C 189.28607,136.69269 189.3571,136.93854 188.68275,144.0872 C 188.14877,149.74774 188.40944,151.4839 189.53834,149.78574 C 190.43129,148.4425 191.19605,144.77917 191.2378,141.64499 C 191.3008,136.91517 191.60632,136.43949 193.03502,138.84672 C 194.24147,140.87949 194.17874,143.46332 192.8252,147.48532 C 190.98625,152.94985 191.1656,153.48229 196.5836,158.64257 C 204.75254,166.42302 208.39735,174.91801 208.85057,187.23321 L 209.24004,197.81619 L 207.90647,188.04727 C 207.17304,182.67439 205.68044,176.08362 204.58962,173.40114 z M 161.40522,172.44041 C 162.42443,170.57277 163.66367,169.44216 164.15903,169.92797 C 165.52747,171.26999 163.33548,175.83616 161.3228,175.83616 C 160.09498,175.83616 160.12025,174.79502 161.40522,172.44041 z M 224.67962,143.42737 C 216.22249,130.6278 205.47174,122.92648 187.23965,116.60728 C 181.26125,114.53518 186.03303,113.64932 192.34665,115.65922 C 201.44282,118.5549 214.68137,127.52552 220.41249,134.677 C 225.90482,141.53052 231.05757,149.21024 231.05757,150.54252 C 231.05757,152.53374 229.68404,151.00142 224.67962,143.42737 z M 136.14176,125.9252 C 134.47191,124.44318 133.10568,121.12805 133.10568,118.55823 C 133.10568,115.07247 132.05161,113.49282 128.95518,112.33828 C 124.63299,110.7267 124.27486,109.83067 124.72528,101.75528 C 125.01873,96.494553 130.03129,91.172313 134.69251,91.172313 C 136.27605,91.172313 138.92425,92.638053 140.57743,94.429503 L 143.58313,97.686663 L 145.90946,94.429503 C 148.55053,90.731653 155.98323,90.086133 159.9801,93.207503 C 163.38212,95.864353 164.97278,106.44757 162.44672,109.61858 C 161.37547,110.96332 159.00483,112.32215 157.17861,112.63818 C 154.73078,113.06178 153.9852,114.28192 154.34146,117.28118 C 155.39223,126.12758 143.00098,132.01288 136.14176,125.9252 z M 156.28816,105.08293 C 158.7528,102.17055 157.19043,99.313083 153.13341,99.313083 C 149.47458,99.313083 145.69023,103.40238 147.17246,105.75435 C 148.72738,108.22172 153.95793,107.83645 156.28816,105.08293 z M 140.42543,106.06555 C 140.90663,105.30198 140.3335,103.38053 139.15176,101.79563 C 136.71625,98.529163 129.78529,99.656403 129.78529,103.319 C 129.78529,106.7952 138.54123,109.05538 140.42543,106.06555 z M 145.56226,100.9332 C 147.53956,97.795613 153.64146,96.330433 157.17861,98.143883 C 160.14871,99.666603 160.25863,99.560413 158.22048,97.137413 C 155.18655,93.530603 150.88201,93.713763 147.2936,97.602353 C 144.39251,100.74611 144.32125,100.74445 139.74223,97.424403 C 136.11633,94.795403 134.45501,94.451433 132.03738,95.829303 C 129.32023,97.377863 129.52958,97.591783 133.80506,97.635403 C 136.4725,97.662633 139.94701,98.831663 141.5262,100.2332 C 143.5657,102.0433 144.73488,102.24605 145.56226,100.9332 z M 89.940443,107.5499 C 89.940443,106.70728 90.687523,105.56507 91.600663,105.0116 C 92.513763,104.45816 93.260863,105.14758 93.260863,106.54367 C 93.260863,107.93973 92.513763,109.08197 91.600663,109.08197 C 90.687523,109.08197 89.940443,108.39253 89.940443,107.5499 z M 118.82103,98.125883 C 120.50866,96.470853 121.90111,98.962553 120.51646,101.15975 C 119.47048,102.81951 119.07943,102.8208 118.51709,101.16631 C 118.13259,100.03508 118.26938,98.666883 118.82103,98.125883 z M 167.96992,97.684933 C 167.96992,96.789433 168.71702,96.056763 169.63012,96.056763 C 170.54323,96.056763 171.29033,96.789433 171.29033,97.684933 C 171.29033,98.580403 170.54323,99.313083 169.63012,99.313083 C 168.71702,99.313083 167.96992,98.580403 167.96992,97.684933 z M 144.7271,76.326783 C 144.7271,75.431293 145.47418,75.151433 146.3873,75.704883 C 147.30041,76.258313 148.0475,77.443813 148.0475,78.339283 C 148.0475,79.234763 147.30041,79.514633 146.3873,78.961193 C 145.47418,78.407743 144.7271,77.222263 144.7271,76.326783 z M 139.53473,76.925983 C 137.46965,74.343643 137.52836,74.286063 140.16155,76.311263 C 141.7595,77.540293 143.0669,78.822463 143.0669,79.160563 C 143.0669,80.500583 141.70355,79.638083 139.53473,76.925983 z"
- id="path1308" />
- <text
- sodipodi:linespacing="125%"
- id="text2460"
- y="177.11876"
- x="267.17868"
- style="font-size:65.59667206px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#f69143;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
- xml:space="preserve"><tspan
- y="177.11876"
- x="267.17868"
- id="tspan2462"
- sodipodi:role="line">monkey</tspan></text>
- <text
- sodipodi:linespacing="125%"
- id="text2464"
- y="177.11876"
- x="495.13577"
- style="font-size:65.59667206px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#914c37;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
- xml:space="preserve"><tspan
- y="177.11876"
- x="495.13577"
- id="tspan2466"
- sodipodi:role="line">sphere</tspan></text>
- </g>
- </g>
-</svg>
+++ /dev/null
-The Monkeysphere uses the OpenPGP web of trust to provide a
-distributed Public Key Infrastructure (PKI) for users and
-administrators of ssh. This talk is about why the Monkeysphere is
-useful, how it works, and how you can use it to ease your workload and
-automatically fully authenticate people and servers.
-
-The Secure Shell protocol has offered public-key-based mutual
-authentication since its inception, but popular implementations offer
-no formalized public key infrastructure. This means there is no
-straightforward, computable method to signal re-keying events, key
-revocations, or even basic key-to-identity binding (e.g. "host
-foo.example.org has key X"). As a result, dealing with host keys is
-usually a manual process with the possibility of tedium, room for
-error, difficulty of maintenance, or users and administrators simply
-ignoring or skipping baseline cryptographic precautions.
-
-The OpenPGP specification offers a robust public key infrastructure
-that has traditionally only been used for e-mail and for encrypted
-storage. By its nature, the OpenPGP Web of Trust (WoT) is a
-distributed system, with no intrinsic chokepoints or global
-authorities. And the global key distribution network provides
-commonly-held, public infrastructure for rapid distribution of key
-changes, revocations, and identity binding.
-
-The Monkeysphere mixes the two to provide new functionality for ssh
-(key revocation, key expiry, re-keying, fewer unintelligible prompts,
-semantic authorization, etc) while taking advantage of existing but
-often-unused functionality in OpenPGP. Additionally, the Monkeysphere
-implementation does not require any patches to OpenSSH on the client
-or server, but takes advantage of existing hooks, which makes it easy
-to adopt.
-
-Specifically, the Monkeysphere allows users to automatically validate
-ssh host keys through the Web of Trust, and it allows servers to
-identify authorized users through the Web of Trust. Users decide
-which certifications in the Web of Trust they put stock in (so they
-are not spoofed by spurious certifications of host keys). Server
-administrators decide whose certifications the server should put stock
-in (so that the server is not spoofed by spurious certifications of
-user keys).
-
-This presentation will go over how the Monkeysphere works; how you can
-use it to increase the security of servers you maintain; how you can
-use it to increase the security of accounts you connect to with ssh;
-and we'll discuss future possibilities lurking in the ideas of the
-Monkeysphere.
-
-Monkeysphere is currently available in the main Debian repository and
-as a port in FreeBSD. A Slackbuild is available for Slackware, and
-Monkeysphere itself should work on any POSIX-ish system with the
-appropriate dependencies available.
-
-The Monkeysphere project began to coalesce in early 2008, and remains
-an ongoing collaboration of many people, including:
-
- * Micah Anderson
- * Mike Castleman
- * Daniel Kahn Gillmor
- * Ross Glover
- * Matthew James Goins
- * Greg Lyle
- * Jamie McClelland
- * Jameson Graef Rollins
-
-The project's main web site is http://web.monkeysphere.info/
+++ /dev/null
-Daniel Kahn Gillmor (dkg) is a freelance Technology Advisor with a
-particular interest in cryptography, user interface design, and
-distributed systems as means to pursue the goals of user autonomy and
-resistance to centralized control. He contributes discussion and
-patches on several crypto-related lists, and is an active participant
-in what remains of the IETF OpenPGP Working Group. He co-administers
-one of the OpenPGP keyservers, and was dubiously involved in
-publicizing the ongoing transition to a post-SHA1 Web of Trust.
-
-dkg works with schools, NGOs, activist groups, and some corporations
-to help them understand their tech needs and risks, possible
-solutions, and how to use and understand the tools they choose. He
-works with several technology-focused organizations, including May
-First/People Link (http://mayfirst.org/) and Riseup
-(http://riseup.net).
-
-He is also a contributor to The Organic Internet
-(http://mayfirst.org/organicinternet), which includes his essay about
-structural flaws in the X.509 certificate model.
-
-dkg began working with free software in 2002, began work with the
-other Monkeysphere developers in 2008, and became a Debian Developer
-in 2009. People seem to laugh when they see his business card.
+++ /dev/null
-I've given several workshops and skillshares about the ideas behind
-OpenPGP and how to use gpg and its various frontends to
-small-to-medium groups (5 to 25 people).
-
-I led an effective skillshare on the nature of X.509-based
-certifications and how they are used in SSL and TLS back in 2003 or
-2004.
-
-I co-led a surprisingly large (~>50 people? packed room!) discussion
-about free software and why it should matter to users as well as
-developers a the Grassroots Media Conference a few years ago with
-Alfredo Lopez and Laura Quilter. This was a very active discussion,
-and topics ranged from motivation and policy to moderately technical
-concerns.
-
-I presented a poster with a colleague on a novel acoustic correlation
-method at ICASSP (the IEEE's International Conference on Acoustics,
-Speech, and Signal Processing) 2001 (though i've recently let my IEEE
-membership lapse).
-
-I've introduced numerous people to the monkeysphere via IRC
-discussions, and have a strong handle on both:
-
- * the necessary details to keep a technical audience engaged
-
- * the bigger-picture goals to keep a non-technical audience engaged
+++ /dev/null
-
-
-
-The presentation is in three parts:
-
-Background
-----------
-
- * Why authentication using asymmetric crypto (as opposed to shared
- secrets) is important on today's network.
-
- * Overview of how ssh uses asymmetric crypto authentication (user ->
- host, host -> user)
-
- * Overview of relevant bits of OpenPGP (key -> User ID bindings,
- certifications, usage flags, key -> subkey bindings)
-
- * Overview of keyservers (the idea of gossip, One Big Network,
- propagation, issues around redundancy, logging, private access)
-
-
-How
----
-
- * How does the monkeysphere do it? (very brief under-the-hood)
-
- * How does a server administrator publish a host's ssh key to the Web
- of Trust? How do they maintain it?
-
- * How does a user incorporate WoT-based host-key checking into their
- regular ssh usage?
-
- * How does a user publish their own ssh identity to the WoT for hosts
- to find it? How do they maintain it?
-
- * How does a server administrator tell a server to admit certain
- people (as identified by the WoT) to certain accounts? How do they
- tell the server which certifications are trustworthy?
-
-Possible Futures
-----------------
-
- * Use the Monkeysphere with ssh implementations other than OpenSSH
- (dropbear, lsh, putty, etc)
-
- * Expansion of the Monkeysphere's out-of-band PKI mechanism for
- authentication in protocols other than SSH (TLS, HTTPS) without
- protocol modification.
-
- * Use of OpenPGP certificates directly in SSH. OpenPGP is referenced
- in RFC 4253 already: optional, rarely implemented, and deliberately
- ambiguous about how to calculate key->identity bindings.
-
- * Use of OpenPGP certificates for authentication directly in
- protocols. RFC 5081 provides a mechanism for OpenPGP certificates
- in TLS, but is similarly ambiguous about certificate verification.
-
- * Better end-user control over verification: Who or what are you
- really connecting to? How do you know? How can this information
- be effectively and intuitively displayed to a typical user?
-
- * What would you like to see?
+++ /dev/null
-no non-standard technical requirements should be necessary.
+++ /dev/null
-Using the Monkeysphere: effective, distributed key management for SSH using the Web of Trust
+++ /dev/null
-do we have something like this?
+++ /dev/null
-Monkeysphere provides a robust, decentralized, out-of-band Public Key
-Infrastructure (PKI) based on OpenPGP's Web of Trust. It is intended
-to support any protocol which needs public-key authentication or
-binding between public keys and real-world entities. Current
-implementations include mutual authentication (both server and client)
-for SSH and authentication of servers for HTTPS. The technique is
-resistant to X.509's inherent single-issuer policy bias, allows use of
-a single key for a host offering multiple services, and handles
-initial contact, re-keying, and revocation better than OpenSSH's
-traditional key continuity management (KCM) scheme. It also requires
-no changes to on-the-wire protocols, and is transparently
-interoperable with existing tools, so the migration path to the new
-PKI is smooth (and encouraged). Discussion will include the merits
-and drawbacks of the Monkeysphere, as well as its relationship to
-in-band measures (such as the Server Name Indication (SNI) TLS
-extension and the subjectAltName (sAN) extended attribute for X.509v3
-certificates) which provide some pieces of similar functionality.
+++ /dev/null
-outline for 1 hr seminar talk to CS/security academics
-
- - key-based authentication is here to stay. (e.g. https, ssh).
- - host vs. user
-
- - raises key management/distribution issues
-
- - what PKIs are available? X.509, OpenPGP, SPKI
-
- - social vulnerabilities - single-signer vs. multi-signer
-
- - protocol vulnerabilities - single cert vs. multi-cert (server
- vs. client again)
-
- - utility for group-internal work, phased approach to public
-
-
-
-Stream-based communications over the public network have an
-authentication problem. Most data streams are not authenticated in
-either direction, and most of those that are authenticated in at least
-one direction use authentication regimes which suffer from a range of
-known structural problems.
-
-Public-key-based authentication offers security advantages over
-shared-secret approaches, but it introduces additional questions of
-key distribution, binding, and revocation. Two common solutions to
-these problems on today's network are X.509 certificates (used by TLS
-connections like HTTPS) and so-called "key continuity management"
-(KCM) (used by popular SSH implementations and the "security
-exceptions" interface for some web browsers). Both of these schemes
-present security concerns of their own: KCM has trouble with initial
-contact, key revocation, and re-keying; and X.509's single-issuer
-certificate format has a systemic bias that selects for unaccountable
-third-party authorities. New work ("the Monkeysphere") extends the
-OpenPGP Web of Trust into authenticating stream-based communications
-(instead of its traditional message-based environment of e-mails and
-files) by means of a protocol-independent overlay. As a simple,
-alternative PKI, the Monkeysphere resolves these failings, and also
-provides features currently only available as protocol extensions
-(such as SNI).
-
-
+++ /dev/null
-******************************************************************************
-* *
-* george system log *
-* *
-******************************************************************************
-* Please add new entries in reverse chronological order whenever you make *
-* changes to this system (first command at top, last at bottom) *
-******************************************************************************
-2010-03-09 - micah
- * setup /srv/micah.monkeysphere.info
- * replaced /etc/mathopd.conf virtual for daniel with one for me
- * removed /srv/daniel.monkeysphere.info - not used
-
-2010-03-08 - mjgoins
- * Adding self to webmaster's authorized_user_ids
- * updating ikiwiki to use the version from lenny backports
- * changing the ikiwki markup to be appropriate for version 3.2xxx
-
-2010-02-23 - dkg
- * add lenny-backports repo.
- * remove monkeysphere repo.
- * aptitude update && aptitude full-upgrade (including monkeysphere
- 0.28-1~bpo50+1, and backported gpg)
-
-2010-01-12 - dkg
- * aptitude update && aptitude full-upgrade (including monkeysphere
- 0.27-1)
-
-2009-10-26 - dkg
- * upgrade nginx in response to DSA-1920-1
-
-2009-09-14 - dkg
- * aptitude update && aptitude full-upgrade (bunch of lenny
- updates, plus ikiwiki security upgrade)
-
-2009-04-21 - jrollins
- * apt-get update && dist-upgrade (a bunch of stuff (monkeysphere,
- screen, gnupg, dash, onak, git-core...)
- * extended host key by 3 months
-
-2009-04-21 - micah
- * aptitude update && aptitude full-upgrade (git-core DSA)
-
-2009-04-12 - dkg
- * aptitude update && aptitude full-upgrade
- * (checked and found that monkeysphere version 0.24-1 is already
- installed; don't know how that happened, coulda been me, just
- sloppy about not noting it in the changelog)
- * extended host key by 4 months
-
-2009-02-22 - jrollins
- * fixed /etc/crontab line for update-users (was trying to run
- monkeysphere-server instead of monkeysphere-authentication).
-
-2009-02-21 - dkg
- * upgraded to the latest versions of packages for lenny.
- * upgraded george to monkeysphere 0.23.1. the transition upgrade
- failed due to the way that gpg exports self-signatures secret
- keys; it only exports the first self-sig for each user id, even if
- that one is expired. Then any subsequent import fails, even if
- the target import keyring knows about some valid self-signatures.
- * i man-handled the upgrade into place so that george doesn't just
- fail on us, but this is a pretty major bug in the transition process.
-
-2009-01-31 - jrollins
- * applied diff represented in commit
- f75a5747a8b99e04c02c475791c476f1fbd2b674 to change log level for
- unacceptable untranslatable keys.
-
-2009-01-30 - micah
- * Replaced nullmailer with postfix, nullmailer doesn't handle aliases
- and insisted either on constantly respooling mail when there was no
- where to go.
-
-2009-01-24 - micah
- * Configured /etc/aliases to have root go to mjgoins, micah, dkg, jrollins
- * Configured /etc/nullmailer/remotes to have mail.riseup.net so remote delivery will work
- * Removed the hundreds of queued cron emails that had resulted in 30gig of mail.err logs
- * Rotated the giant logs out
-
-2009-01-11 - dkg
- * extended the expiration date for george's key three months into
- the future.
- * aptitude update && aptitude full-upgrade (brings monkeysphere to
- 0.22-1)
-
-2008-10-29 - dkg
- * aptitude update && aptitude full-upgrade
- * brought monkeysphere up to 0.19-1
- * removed tasksel
-
-2008-10-25 - dkg
- * aptitude update && aptitude full-upgrade
- * brought monkeysphere up to 0.16-1
- * repointed keyserver usage to pool.sks-keyservers.net
-
-2008-09-04 - dkg
- * added two mime-type declarations in /etc/mathopd.conf so .debs
- and .tar.gz files come out reasonably; restarted mathopd for the
- re-read.
- * built monkeyshell (from src/monkeyshell) and installed as
- /usr/local/bin/monkeyshell, added to /etc/shells.
- * created new account "monkey" which has monkeyshell as the shell
- for non-privileged test access. To let someone test this out,
- make sure they're well-connected to george's web of trust, and
- then add their User ID to
- ~monkey/.monkeysphere/authorized_user_ids
- * more mime types for mathopd: image/png image/x-icon
-
-2008-09-03 - micah
- * migrated /home/*/.config/monkeysphere/authorized_user_ids to new
- agreed location: /home/*/.monkeysphere/authorized_user_ids and created
- a symlink in the original location for transition purposes. Also,
- did /root's as well. I used this hackish mechanism:
- $ for user in `find . -wholename './*/.config/monkeysphere/authorized_user_ids' \
- | cut -d/ -f2`; do mkdir -v ${user}/.monkeysphere; chown ${user}:${user} \
- ${user}/.monkeysphere; mv -v ${user}/.config/monkeysphere/authorized_user_ids \
- ${user}/.monkeysphere; ln -s /home/${user}/.monkeysphere/authorized_user_ids \
- ${user}/.config/monkeysphere/authorized_user_ids; done
-
- - dkg
- * added the monkeysphere archive repository signing key
- * aptitude update && aptitude full-upgrade (brings in monkeysphere 0.13-1)
- * cleaned up /etc/skel to reflect correct location of the
- monkeysphere config directory.
- * micah moved all the existing config stuff over, and left
- symlinks so people aren't disoriented.
-
-2008-09-01 - dkg
- * set up http://dkg.monkeysphere.info so that i could play around
- with ikiwiki updates
- * moved apt repository over to http://archive.monkeysphere.info/
- * aptitude update && aptitude dist-upgrade
- * canonicalizing hostname for normal web access to
- http://web.monkeysphere.info
-
-2008-08-26 - dkg
- * aptitude update && aptitude full-upgrade
- * added account 'daniel' for Dan Scott, and set him up with a way
- to publish to http://daniel.monkeysphere.info
-
-2008-08-20 - dkg
- * aptitude update && aptitude dist-upgrade: this includes
- monkeysphere 0.11-1 and OpenSSH 5.1p1-2
-
-2008-08-18 - dkg
- * moved monkeysphere apt repo entry to
- /etc/apt/sources.list.d/monkeysphere.list
- * aptitude update && aptitude full-upgrade (including monkeysphere
- 0.9-1)
- * switched george's monkeysphere-server preferred keyserver to
- monkeysphere.info for the moment. Both pgp.mit.edu and
- subkeys.pgp.net are sluggish right now :/
-
-2008-08-16 - jrollins
- * removed stale branches from jrollins from the master repo
- * aptitude update && aptitude full-upgrade
- * restarted services to clear up dependencies on old libraries
-
-2008-08-13 - dkg
- * aptitude update && aptitude full-upgrade
- * restarted services to clear up dependencies on old libraries
-
-2008-08-07 - dkg
- * aptitude update && aptitude dist-upgrade
- * removed debian's experimental from the sources.list
- * removed experimental stanza from /etc/apt/preferences (now the
- monkeysphere packages should upgrade automatically)
- * upgraded to monkeysphere 0.7-1
- * installed runit
- * set up a public git daemon service to serve git repos from
- george, using runit. (root-served repos are served from
- /srv/git, but ~USER/public_git is supported as well, if anyone
- wants to use that for publication).
-
-2008-08-03 - dkg
- * aptitude update && aptitude dist-upgrade
- * installed iproute
- * added my User ID to ~webmaster/.config/monkeysphere/authorized_user_ids
-
-2008-08-02 - jrollins
- * aptitude update && aptitude dist-upgrade
- * restarted cron, nullmailer, sshd
- * aptitude install git-core ikiwiki
- * adduser webmaster
- * su - webmaster
- * created a bare repo at ~webmaster/monkeysphere.git. I then
- pushed into this repo from my working directory on servo to verify
- that it was accepting.
- * cloned above repo at ~webmaster/monkeysphere
- * created ~webmaster/ikiwiki.setup
- * ikiwiki --setup ikiwiki.setup
- * linked post-receive to new post-commit hook in monkeysphere.git
- * changed default keyserver to be pgp.mit.edu (subkeys.pgp.net
- blows)
- * updated /etc/skel with ssh and monkeysphere stuff
- * made authorzied_user_ids file for webmaster and ran
- "monkeysphere-server u webmaster".
-
-2008-06-23 - dkg
- * added monkeysphere apt repository to /etc/apt/sources.list
- * added dkg's key to apt's list of trusted keys.
- * ran aptitude dist-upgrade
- * upgraded to monkeysphere 0.2-1
- * moved authorized_user_ids files into users' home directories.
- * installed lockfile-progs
-
-2008-06-22 - dkg
- * installed screen (mjgoins and i were collaborating)
-
-2008-06-21 - micah
- * Restored /etc/init.d/ssh to original package state and changed
- /etc/default/ssh to have 'unset SSHD_OOM_ADJUST' instead.
-
-2008-06-20 - micah
- * Commented out the 'export SSHD_OOM_ADJUST=-17' from the
- /etc/init.d/ssh initscript, and the 'SSHD_OOM_ADJUST=-17' from
- /etc/default/ssh in order to make this error go away:
- "error writing /proc/self/oom_adj: Operation not permitted"
- (c.f. Debian #487325)
-
-2008-06-20 - dkg
- * touched /etc/environment to get rid of some spurious auth.log
- entries.
- * turned up sshd's LogLevel from INFO to DEBUG
-
-2008-06-19 - dkg
- * installed rsync (for maintaining a public apt repo)
-
- * configured mathopd to listen on port 80, serving /srv/www as /
- and /srv/apt as /debian. We've got nothing in /srv/www at the
- moment, though.
-
- * installed lsof and psmisc as sysadmin utilities. sorry for the
- bloat!
-
- * installed strace to try to figure out why onak is segfaulting.
-
-2008-06-19 - dkg
- * removed etch sources, switched "testing" to "lenny", added
- lenny/updates, removed all contrib and non-free.
-
- * removed testing pin in /etc/apt/preferences
- * ran the upgrade
-
- * reset emacs22 to emacs22-nox (avoiding dependencies)
-
- * removed sysklog and klogd because of errors restarting klogd.
- Installed syslog-ng in their stead, which still gives errors
- related to /proc/kmsg unreadability, but the install completes :/
-
- * added experimental
- * juggled pinning: experimental: 1, unstable: 2
- * added mathopd onak, tweaked /etc/mathopd.conf and /etc/onak.conf
-
- * installed monkeysphere v0.1-1, changed host key, published
- them via the local keyserver (see host-key-publication)
-
- * added local unprivileged user accounts for everyone listed in
- /usr/share/doc/monkeysphere/copyright
-
- * configured authorized_user_ids for every user account based on
- my best guess at their OpenPGP User ID (see
- user-id-configuration).
-
- * set up a cronjob (in /etc/crontab) to run "monkeysphere-server
- update-users" at 26 minutes past the hour.
-
-2008-06-18 - jrollins
- * installed less, emacs;
- * aptitude update && aptitude dist-upgrade
-
-2008-06-18 - micah
- * debootstrap'd debian etch install
- * installed /etc/apt/sources.list with local proxy sources for etch,
- testing, unstable, backports and volatile
- * configured /etc/apt/preferences and apt.conf.d/local-conf to
- pin etch, but make testing, sid and backports available
- * added backports.org apt-key
- * installed openssh-server and openssh-client packages
- * added dkg, jrollins, mjgoins ssh public_keys to /root/.ssh/authorized_keys
+++ /dev/null
-2008-06-19 02:34:57-0400
-------------------------
-
-Adding george's host key to the monkeysphere was more complicated than
-it needed to be.
-
-As the server admin, i did (accepting the defaults where possible):
-
- monkeysphere-server gen-key
- KEYID=$(GNUPGHOME=/etc/monkeysphere/gnupg gpg --with-colons --list-key =ssh://$(hostname --fqdn) | grep ^pub: | cut -f5 -d:)
- (umask 077 && GNUPGHOME=/etc/monkeysphere/gnupg gpg --export-secret-key $KEYID | openpgp2ssh $KEYID >/etc/monkeysphere/ssh_host_rsa_key)
- # modify /etc/ssh/sshd_config to remove old host keys lines, and
- # add new line: HostKey /etc/monkeysphere/ssh_host_rsa_key
- /etc/init.d/ssh restart
-
- KEYSERVER=george.riseup.net monkeysphere-server publish-key
- # (needed to publish by hand here because of reasonable sanity checks)
- monkeysphere-server show-fingerprint
-
- # then from a remote host:
- gpg --keyserver george.riseup.net --search =ssh://george.riseup.net
- gpg --fingerprint --sign-key =ssh://george.riseup.net
- KEYID=$(gpg --with-colons --list-key =ssh://george.riseup.net | grep ^pub: | cut -f5 -d:)
- gpg --keyserver george.riseup.net --send "$KEYID"
- gpg --keyserver george.riseup.net --send "$MYGPGID"
-
-
-How could this have been streamlined?
+++ /dev/null
-Wed Jun 25 02:03:39 EDT 2008 matt goins <mjgoins@openflows.com>
-
-On Saturday (2008-6-22) dkg and I set up sks as a replacement for onak. onak
-had proven to be unstable, mostly in that it tended to corrupt its own database
-beyond repair.
-
-The sks instructions want the admin to download many huge dumps of keys from
-the world's keyservers (on the order of 5 GiB?), so we imported a dump
-containing only my key. We learned that sks won't start with an empty database,
-unlike onak.
-
-2008-06-25: Locally exported george's key to its keyserver. Tried a remote
-send-keys of squash's key and it appears to work.
-
-
-TODO:
-
- * Get some more keys in there.
-
- * Read up on syncing with other keyservers.
-
-
-
-
+++ /dev/null
-Policy for maintaining george.riseup.net
-----------------------------------------
-
-Riseup graciously provided the MonkeySphere project with a vserver for
-testing and public documentation. This is known as george.riseup.net,
-for those who are curious about the MonkeySphere.
-
-george will be maintained as a debian lenny machine, with minimal
-packages from experimental as needed for installing and running what
-we build elsewhere.
-
-george will host 3 public-facing services: an ssh daemon on port 22,
-an http service on port 80, and an OpenPGP keyserver (the HKP
-protocol) on port 11371.
-
-Administration of george is a shared responsibility across the core
-members of the MonkeySphere development team. Administrators will log
-changes in their git repositories, in doc/george/changelog (a peer of
-this policy file).
-
-monkeysphere packages installed on george will use unique, tagged
-version numbers so we know what we're running.
-
-We will try to keep the installation as minimal as possible while
-still allowing for comfortable day-to-day administration.
-
-We will use aptitude for package management where possible.
-
-Outstanding questions:
-
-Who should have superuser access?
-
-Who should get regular user accounts?
+++ /dev/null
-2008-06-19 03:00:58-0400
-------------------------
-
-setting up authorized_user_id configuration on george was also more
-cumbersome than it needs to be. Here's what i (dkg) did:
-
-monkeysphere-server trust-keys 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
-
-monkeysphere-server update-user-userids dkg 'Daniel Kahn Gillmor <dkg@fifthhorseman.net>'
-monkeysphere-server update-user-userids jrollins 'Jameson Rollins <jrollins@fifthhorseman.net>'
-monkeysphere-server update-user-userids micah 'Micah Anderson <micah@riseup.net>'
-monkeysphere-server update-user-userids mjgoins 'Matthew Goins <mjgoins@openflows.com>'
-monkeysphere-server update-user-userids ross 'Ross Glover <ross@ross.mayfirst.org>'
-monkeysphere-server update-user-userids jamie 'Jamie McClelland <jamie@mayfirst.org>'
-monkeysphere-server update-user-userids mlcastle 'mike castleman <m@mlcastle.net>'
-monkeysphere-server update-user-userids enw 'Elliot Winard <enw@caveteen.com>'
-monkeysphere-server update-user-userids greg 'Greg Lyle <greg@stealthisemail.com>'
-
-
-then i added a scheduled:
-
- monkeysphere-server update-users
-
-to run hourly via /etc/crontab
-
-and made sure that root's keys were working with a temporary symlink
-(see TODO about that business)
-
-and then modified /etc/ssh/sshd_config with:
-
- AuthorizedKeysFile /var/cache/monkeysphere/authorized_keys/%u
-
-
-Some outstanding questions:
-
- * Should we ship a scheduled monkeysphere-server update-users cron
- job automatically?
-
- * why was i not prompted to confirm the trust-keys line, which seems
- like the most delicate/sensitive line of all of them?
+++ /dev/null
-use IkiWiki::Setup::Standard {
- wikiname => "Monkeysphere",
- adminemail => 'webmaster@monkeysphere.info',
-
- srcdir => "/path/to/cloned/monkeysphere/repo/website",
- destdir => "/path/to/web/dir",
-
- url => "http://monkeysphere.info",
-
- rcs => "git",
-
- wrappers => [
- {
- wrapper => "/path/to/post-receive/hook",
- wrappermode => "0755",
- }
- ],
-
- rss => 1,
- atom => 1,
- verbose => 0,
- syslog => 0,
-
- add_plugins => [qw{goodstuff favicon toc sidebar}],
-
-
- tagbase => "tags",
-
-}
+++ /dev/null
-******************************************************************************
-* *
-* zimmermann system log *
-* *
-******************************************************************************
-* Please add new entries in reverse chronological order whenever you make *
-* changes to this system (first command at top, last at bottom) *
-******************************************************************************
-
-2010-03-10 - micah
- * Updated /etc/monkeysphere/*.conf to use zimmermann
- for the keyserver
-
-2010-03-09 - dkg
- * transferred the https://z.m.o key from /root/.gnupg into the
- monkeysphere-host keyring with:
-
- gpg --export-secret-keys | GNUPGHOME=/var/lib/monkeysphere/host gpg --import
-
- * used undocumented "monkeysphere-host update-pgp-pub-file" to
- refresh the output of m-h s.
-
-2010-02-19 - dkg
- * upgraded to monkeysphere 0.28-1~bpo50+1 (includes gnupg from
- backports.org)
-
-2010-02-?? - dkg
- * manually created an OpenPGP certificate for zimmermann's https
- RSA key, stored in /root/.gnupg; published it to the keyserver
- network, certified it myself.
-
-2008-11-29 - dkg
- * zimmermann now uses an X.509 certificate signed by the MF/PL CA
- for its HTTPS connection.
-
-2008-11-19 - dkg
- * added 10 SKS peers as a result of feedback from sks-devel.
- * set localtime to America/New_York via dpkg-reconfigure tzdata
- * aptitude update && aptitude full-upgrade
- * set up /var/lib/sks/www/index.html based on
- doc/zimmermann/index.html from this repo.
- * made nginx proxy plain ol' HTTP on port 80 also so that SKS does
- not need to try to listen on a privileged port.
- * turned on initial_stat and stat_hour: 3 in /etc/sks/sksconf
-
-2008-11-19 - mlc
- * aptitude install nginx
- * get rid of /etc/nginx/sites-enabled/default
- * create /etc/nginx/sites-available/https-proxy and make a symlink
- to it in the sites-enabled directory
- * invoke-rc.d nginx start
-
-2008-11-17 - micah
- * verified the SHA256 values for the key material
- * /usr/lib/sks/sks_build.sh (chose option #2: normalbuild)
- * chown -R debian-sks:debian-sks /var/lib/sks
- * edit /etc/default/sks to enable the initscript
- * /etc/init.d/sks start
- * rm -rf /var/lib/sks/dump
-
-2008-11-15 - micah
- * aptitude update && aptitude full-upgrade
- * aptitude install sks
- * cd /var/lib/sks/dump ; wget -q -r -np -nd -A bz2,SHA256,asc \
- http://nynex.net/keydump/ -e robots=off
- * install monkeysphere 0.21-2 package
- * apt-get install bzip2 ; bunzip2 /var/lib/sks/dump/*.bz2
-
-2008-11-15 - jamie
- * aptitude install esmtp-run mailx
- * edited /etc/esmtp-run, configured to relay to bulk.mayfirst.org
+++ /dev/null
-server {
- listen 443;
- server_name zimmermann.mayfirst.org;
- ssl on;
- ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
- ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
- ssl_ciphers HIGH:MEDIUM:!ADH;
-
- access_log off;
-
- location / {
- proxy_pass http://localhost:11371/;
- }
-}
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
- <head>
- <title>SKS Search Page</title>
- <meta http-equiv="content-type" content="text/html; charset="utf-8">
- <meta name="author" content="Yaron M. Minsky/Jack Cummings/Daniel Kahn Gillmor">
- </head>
- <body text="#000000" bgcolor="#ffffff" link="#000099" vlink="#990099" alink="#000099">
- <h1><a href="http://www.nongnu.org/sks/">SKS OpenPGP Keyserver</a> <br> @zimmermann.mayfirst.org</h1>
- <p> SKS is a OpenPGP keyserver whose goal is to provide easy to deploy, decentralized, and highly reliable synchronization. That means that a key submitted to one SKS server will quickly be distributed to all key servers, and even wildly out-of-date servers, or servers that experience spotty connectivity, can fully synchronize with rest of the system. </p>
- <p>You can find out more about SKS, along with links to graphs of the network status <a href="http://www.nongnu.org/sks/">here</a>.</p>
- <table cellpadding="2" cellspacing="2" border="1" width="600" bgcolor="#ddddff">
- <tr>
- <td valign="top">
- <h3>Extract a key</h3>
- <p>You can extract a key by typing in some words that appear in the userid
- of the key you're looking for, or by typing in the keyid in hex format ("0x...")</p>
- <p>
- <form action="/pks/lookup" method="get">
- Search String: <input name="search" size="40"> <br>
- Show PGP "fingerprints" for keys
- <input type="checkbox" name="fingerprint"> <br>
- Show SKS full-key hashes
- <input type="checkbox" name="hash"> <br>
- Search for keys: <br>
- <input type="radio" name="op" value="index" CHECKED> get index of matching keys <br>
- <input type="radio" name="op" value="vindex"> get verbose index of matching keys <br>
- <input type="radio" name="op" value="get"> retrieve ascii-armored keys <br>
- <input type="radio" name="op" value="hget"> retrieve keys by full-key hash
- <br>
- <input type="reset" value="Reset">
- <input type="submit">
- </form>
- <br>
- </td>
- </tr>
- <tr>
- <td valign="top">
- <h3>Submit a key</h3>
- You can submit a key by simply pasting in the ASCII-armored version
- of your key and clicking on submit.
- <form action="/pks/add" method="post">
- <textarea name="keytext" rows="20" cols="66"></textarea> <br>
- <input type="reset" value="Reset">
- <input type="submit" value="Submit this key to the keyserver!">
- </form>
- </td>
- </tr>
- <tr>
- <td>
- <h3>
- Access
- </h3>
- To use this server directly via HKP add this to your .PGP keyserver list:<br>
-
-<pre>x-hkp://zimmermann.mayfirst.org
-http://zimmermann.mayfirst.org:11371</pre>
-
- You can also select a random server by adding this to your keyserver list:<br>
-
-<pre>x-hkp://pool.sks-keyservers.net
-http://pool.sks-keyservers.net:11371</pre>
-
- </td>
- </tr>
- </tbody>
- </table>
-
-<hr>
- [<a href="/pks/lookup?op=stats">Server Status</a>] If you have any questions
- about or problems with this server, please <a href="https://support.mayfirst.org/newticket?summary=zimmermann.mayfirst.org%20trouble">open a ticket</a>.
- </body>
-</html>
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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]]
+++ /dev/null
-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
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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).
+++ /dev/null
-[[!meta title="Completed Bugs"]]
-
-Recently fixed [[bugs]].
-
-[[!inline pages="./* and link(./done) and !*/Discussion" sort=mtime show=10]]
+++ /dev/null
-[[!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
+++ /dev/null
-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.
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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.
+++ /dev/null
-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?
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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)
+++ /dev/null
-[[!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.
+++ /dev/null
-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
+++ /dev/null
-[[!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
+++ /dev/null
-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.
+++ /dev/null
-[[!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
+++ /dev/null
-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.
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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:~#
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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
+++ /dev/null
-[[!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
+++ /dev/null
-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)
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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
+++ /dev/null
-[[!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).
+++ /dev/null
-[[!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)
+++ /dev/null
-[[!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>
+++ /dev/null
-[[!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/)
-
+++ /dev/null
-[[!meta title="Features"]]
-
-# Features #
-
+++ /dev/null
-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.
+++ /dev/null
-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/
+++ /dev/null
-[[!meta title="The Monkeysphere Project"]]
-[[!meta license="Unless otherwise noted, all content on this web site is licensed under the GPL version 3 or later"]]
-[[!meta copyright="All content on this web site is copyright by the author of that content. [Look in the revision control system](community) for details about who authored a particular piece of content."]]
-
-# The Monkeysphere Project #
-
-The Monkeysphere project's goal is to extend OpenPGP's web of trust to
-new areas of the Internet to help us securely identify each other
-while we work online.
-
-Specifically, monkeysphere currently offers a framework to leverage
-the OpenPGP web of trust for OpenSSH authentication.
-
-In other words, it allows you to use secure shell as you normally do,
-but to identify yourself and the servers you administer or connect to
-with your OpenPGP keys. OpenPGP keys are tracked via GnuPG, and
-monkeysphere manages the `known_hosts` and `authorized_keys` files
-used by OpenSSH for authentication, checking them for cryptographic
-validity.
-
-## Overview ##
-
-Everyone who has used secure shell is familiar with the prompt given
-the first time you log in to a new server, asking if you want to trust
-the server's key by verifying the key fingerprint. Unfortunately,
-unless you have access to the server's key fingerprint through a
-secure out-of-band channel, there is no way to verify that the
-fingerprint you are presented with is in fact that of the server
-you're really trying to connect to.
-
-Many users also take advantage of OpenSSH's ability to use RSA or DSA
-keys for authenticating to a server (known as
-"`PubkeyAuthentication`"), rather than relying on a password exchange.
-But again, the public part of the key needs to be transmitted to the
-server through a secure out-of-band channel (usually via a separate
-password-based SSH connection or a (hopefully signed) e-mail to the
-system administrator) in order for this type of authentication to
-work.
-
-[OpenSSH](http://openssh.com/) currently provides a functional way to
-manage the RSA and DSA keys required for these interactions through
-the `known_hosts` and `authorized_keys` files. However, it lacks any
-type of [Public Key Infrastructure
-(PKI)](http://en.wikipedia.org/wiki/Public_Key_Infrastructure) that
-can verify that the keys being used really are the one required or
-expected.
-
-The basic idea of the Monkeysphere is to create a framework that uses
-[GnuPG](http://www.gnupg.org/)'s keyring manipulation capabilities and
-public keyserver communication to manage the keys that OpenSSH uses
-for connection authentication.
-
-The Monkeysphere therefore provides an effective PKI for OpenSSH,
-including the possibility for key transitions, transitive
-identifications, revocations, and expirations. It also actively
-invites broader participation in the
-[OpenPGP](http://en.wikipedia.org/wiki/Openpgp) [web of
-trust](http://en.wikipedia.org/wiki/Web_of_trust).
-
-Under the Monkeysphere, both parties to an OpenSSH connection (client
-and server) explicitly designate who they trust to certify the
-identity of the other party. These trust designations are explicitly
-indicated with traditional GPG keyring trust models. Monkeysphere
-then manages the keys in the `known_hosts` and `authorized_keys` files
-directly, in such a way that is completely transparent to `ssh`. No
-modification is made to the SSH protocol on the wire (it continues to
-use raw RSA public keys), and no modification is needed to the OpenSSH
-software.
-
-To emphasize: ***no modifications to SSH are required to use the
-Monkeysphere***. OpenSSH can be used as is; completely unpatched and
-"out of the box".
-
-## License ##
-
-All Monkeysphere software is copyright, 2007-2010, by [the
-authors](community), and released under [GPL, version 3 or
-later](http://www.gnu.org/licenses/gpl-3.0.html).
-
-----
-
-This wiki is powered by [ikiwiki](http://ikiwiki.info).
+++ /dev/null
-/* 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;
-}
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!meta title="News"]]
-
-# News #
-
-Here are the latest announcements about the Monkeysphere.
-
-[[!inline pages="./news/* and !*/Discussion" rootpage="news" show="30"]]
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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
-
+++ /dev/null
-[[!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!
-
+++ /dev/null
-[[!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).
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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).
+++ /dev/null
-# 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.
-
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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>
-
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!meta title="Monkeysphere 0.21-1 released!"]]
-
-Monkeysphere 0.21-1 has been released.
-
-Notes from the changelog:
-
-<pre>
-</pre>
-
-[[Download]] it now!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-# 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!
+++ /dev/null
-# 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!
+++ /dev/null
-[[!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!
+++ /dev/null
-[[!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!
+++ /dev/null
-# 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).
-
+++ /dev/null
-[[!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).
+++ /dev/null
-<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>
-
+++ /dev/null
-# 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.
+++ /dev/null
-[[!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).
+++ /dev/null
-[[!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 ###
+++ /dev/null
-[[!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.
+++ /dev/null
-[[!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).
-
+++ /dev/null
-[[!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"
+++ /dev/null
-[[!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)
+++ /dev/null
-[[!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
projects / monkeysphere.git / commitdiff
