diff options
| author | Matthew James Goins <mjgoins@openflows.com> | 2010-03-20 15:07:30 -0400 |
|---|---|---|
| committer | Matthew James Goins <mjgoins@openflows.com> | 2010-03-20 15:07:30 -0400 |
| commit | 2f9fe93b98ed32b662212899db6ba2174c1138d3 (patch) | |
| tree | 099a0b3224b666bfc1289462f1a6d01a24763102 /website/bugs | |
| parent | 072e05ac7a9872edc3a3e18e103bbba2706254bf (diff) | |
Removed docs and website. They will now reside (for my repo) at git://lair.fifthhorseman.net/~mjgoins/monkeysphere.info/
Diffstat (limited to 'website/bugs')
33 files changed, 0 insertions, 1593 deletions
diff --git a/website/bugs/add-identity-certifier-behaves-oddly-without-pty.mdwn b/website/bugs/add-identity-certifier-behaves-oddly-without-pty.mdwn deleted file mode 100644 index 1962fe5..0000000 --- a/website/bugs/add-identity-certifier-behaves-oddly-without-pty.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -When executing `monkeysphere-server add-identity-certifier` across a -link without a pseudo-terminal, it behaves oddly (prompts are created -that are only halfway-readable, gpg gives error messages about lacking -access to a `/dev/tty`, etc. - -You can try this directly if you have remote ssh access to the -superuser on a monkeysphere-enabled host, assuming that `$GPGID` is -set to the full fingerprint of a key you want to add as a trusted -identity certifier: - - ssh root@example.org monkeysphere-server add-identity-certifier $GPGID - -Compare this behavior with: - - ssh -t root@example.org monkeysphere-server add-identity-certifier $GPGID diff --git a/website/bugs/add-man-pages-to-website.mdwn b/website/bugs/add-man-pages-to-website.mdwn deleted file mode 100644 index 0aaee21..0000000 --- a/website/bugs/add-man-pages-to-website.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -[[!meta title="Add man pages to web site"]] - -We should publish the various monkeysphere man pages in browsable form -somewhere under http://web.monkeysphere.info/. Ideally, this would be -updated automatically from the sources for the official man pages -themselves. - -This strikes me as an ikiwiki subproject (implementing a man2html wiki -compilation language perhaps?). - -Interestingly, [ikiwiki's own man page](http://ikiwiki.info/usage/) -appears to be written in markdown and then converted to nroff. diff --git a/website/bugs/allow-publishing-to-public-keyservers.mdwn b/website/bugs/allow-publishing-to-public-keyservers.mdwn deleted file mode 100644 index 5d4ce4c..0000000 --- a/website/bugs/allow-publishing-to-public-keyservers.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -[[!meta title="monkeysphere-server publish-key does not work"]] - -Currently, if you try to run `monkeysphere-server publish-key`, you -can get the following output: - - Really publish key to subkeys.pgp.net? (y/N) y - NOT PUBLISHED (to avoid permanent publication errors during monkeysphere development). - The following command should publish the key: - monkeysphere-server gpg-authentication-cmd '--keyserver subkeys.pgp.net --send-keys foo.example.org' - -I think we've demonstrated that this system works enough to warrant -using the public keyserver infrastructure. - -I suggest that we should actually enable this feature explicitly. -(leaving in the prompt is fine, though it would be nice to be able to -`--force` it or something). - ---- - -[[bugs/done]] 2008-08-15 in 6fb350a883fa4d8b1bc9b5e01cc3b01c96354d08 diff --git a/website/bugs/authorized_keys-options.mdwn b/website/bugs/authorized_keys-options.mdwn deleted file mode 100644 index 69e62fa..0000000 --- a/website/bugs/authorized_keys-options.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta title="Monkeysphere support for options in authorized_keys"]] - -OpenSSH [allows users to control the capabilities granted to remote -key-based -logins](http://www.hackinglinuxexposed.com/articles/20030109.html) by -supplying options that should limit the use of the key. - -For example, specifying `no-pty` means that `sshd` should not allocate -a pseudo-terminal for sessions created based on an authentication with -that key. - -It is unclear if it is possible to do this sort of limiting in -`~/.monkeysphere/authorized_user_ids`, and if it is possible, how -you'd actually do it. - - --dkg diff --git a/website/bugs/authorized_keys_not_cleared.mdwn b/website/bugs/authorized_keys_not_cleared.mdwn deleted file mode 100644 index 0c4dbb6..0000000 --- a/website/bugs/authorized_keys_not_cleared.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta title="users with missing or empty authorized keys and User IDs should have MS-generated keys cleared" ]] - -I had a user who had a bunch of entries in -`~/.monkeysphere/authorized_user_ids`, and a bunch of raw keys in -`~/.ssh/authorized_keys`. My system's `monkeysphere-server` handled -this situation appropriately, and populated -`/var/lib/monkeysphere/authorized_keys/user` with the full set. - -Then i wanted to wipe out all key entries for that user. So i did: - - mkdir ~user/backup - mv ~user/.ssh ~user/.monkeysphere ~user/backup - monkeysphere-server update-users user - -I expected this to either remove -`/var/lib/monkeysphere/authorized_keys/user`, or truncate it to 0 -bytes. However, it just remained untouched, and the old keys -persisted. - -This seems like a potential security problem. - ---- - -[[bugs/done]] on 2008-10-26 in c8ab71b24b566967fdb39818d071f6548dc056c8 diff --git a/website/bugs/cssh-connection-timeout.mdwn b/website/bugs/cssh-connection-timeout.mdwn deleted file mode 100644 index 343d5af..0000000 --- a/website/bugs/cssh-connection-timeout.mdwn +++ /dev/null @@ -1,93 +0,0 @@ -[[!meta title="Monkeysphere interferes with clusterssh"]] - -clusterssh is a package that allows you to control multiple ssh xterm -sessions at the same time. - -When the monkeysphere-ssh-proxycommand is enabled and I launch 5 or more -cssh sessions, intermittently one or two out of every five will fail -with: Connection timed out during banner exchange. - -I tried to debug by running: - - MONKEYSPHERE_LOG_LEVEL=debug cssh -D -d <server1> <server2> etc. - -However, while it produced some private data, it didn't give me any -insight into what was going wrong. Also, it didn't output any -Monkeysphere debugging info. - -I had no luck with google and the error message being output. - -This isn't a huge priority (it's not hard to disable the -monkeysphere-ssh-proxycommand before running cssh), however, it would be -nice to figure out why it's not working. - ---- - -What do you mean by "produced some private data" when you set the log -level to DEBUG? Monkeysphere does not output any "private" data in -the sense of private keys or passwords or anything like that. Maybe -you mean the cssh debug mode outputs private data? or do you just -mean "info that you don't want to post here"? It might be useful to -see some output, so maybe you could just block out the nasty bits? -But I'm not sure it will help. - -The problem may be due to the locking of the known\_hosts file while -the proxycommand is running. At the moment, the -monkeysphere-ssh-proxycommand can only be run serially, since each -invocation will lock the known\_hosts file while it updates it. I -think this is required, since we obviously can't have two invocations -modifying the file at the same time. However, it's probably possible -to decrease the amount of time it takes to update the file. It's not -done very efficiently at the moment. The file is locked basically at -the very begining, and is locked while all gpg interactions are done, -which are slow. I think it should be possible to take the gpg -interactions out of the loop. - -I just tried cssh and it doesn't seem to work very well with my ssh -setup at all. For instance, the simultaneous ssh connections cause -simultaneous calls to the agent to get my permission to use the key, -which don't interact very well with each other. This of course is not -a monkeysphere problem but a general problem with trying to make -simultaneous ssh connections with an agent that want key use -confirmation. - --- jrollins - ---- - -I can get cssh to work fine with a confirmation-required agent if i -turn off the monkeysphere proxycommand: - - cssh -l username -o '-oProxyCommand=none' $(cat hostlist.txt) - -with the proxycommand, i definitely get the "Connection timed out -during banner exchange" message. - -However, i'm also able to get the cssh connection to work if i assert -that a longer connection timeout is acceptable: - - cssh -l username -o '-oConnectTimeout=30' $(cat hostlist.txt) - -Perhaps this is an acceptable workaround? - --- dkg - ---- - -Sorry for not being more clear. Monkeysphere debug does not reveal personal -information - but cluster cssh -d -D exposes the hosts in my ssh config file. - -dkg's approach seems to work. His suggestion, as written, didn't work for me. -But that's because I ran cssh -u > $HOME/.csshrc, which generates a default -cssh config file (that specifies ConnectTimeout=10). That file seems to -override the command linke (perhaps a cssh bug?). I changed the ConnectTimeout -to 30 in my ~/.csshrc file and now everything works. - -I think jrollins' assessment is probably right - the extra delay due to locking -causes the timeout. I think tweaking ConnectTimeout parameter via the .csshrc -file or via the command line is a reasonable fix for this bug, so I'm closing -as [[bugs/done]]. - --- Sir Jam Jam - -I just [posted the cssh bug in debian](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498968). diff --git a/website/bugs/done.mdwn b/website/bugs/done.mdwn deleted file mode 100644 index e29587c..0000000 --- a/website/bugs/done.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -[[!meta title="Completed Bugs"]] - -Recently fixed [[bugs]]. - -[[!inline pages="./* and link(./done) and !*/Discussion" sort=mtime show=10]] diff --git a/website/bugs/genericize-filesystem-locations-for-testsuite.mdwn b/website/bugs/genericize-filesystem-locations-for-testsuite.mdwn deleted file mode 100644 index 6cc3773..0000000 --- a/website/bugs/genericize-filesystem-locations-for-testsuite.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -[[!meta title="genericize all filesystem locations to enable test suite:" ]] - -I'm in the process of writing a testsuite for the monkeysphere so that -we can verify that it actually performs all the basic expected duties -properly. - -It occurs to me that lines like these: - - ETC="/etc/monkeysphere" - VARLIB="/var/lib/monkeysphere" - -Actually make it very difficult to generically test the tool without -it being installed system-wide. - -Is there any reason that we should not allow these directories to be -overridden with environment variables in the same way that -`/usr/share/monkeysphere/share` is handled? - - SHARE=${MONKEYSPHERE_SHARE:-"/usr/share/monkeysphere"} - -I guess i'm proposing something like: - - SYSCONFIGDIR=${MONKEYSPHERE_SYSCONFIGDIR:-"/etc/monkeysphere"} - SYSDATADIR=${MONKEYSPHERE_SYSDATADIR:-"/var/lib/monkeysphere"} - -Thoughts? - ---dkg - ---- - -[[bugs/done]] on 2008-10-11 diff --git a/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn b/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn deleted file mode 100644 index d10a164..0000000 --- a/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -In monkeysphere-server, the gpg\_authentication function, and -consequently the gpg\_authentication\_cmd, currently requires that all -arguments be put in a single quoted argument, eg: - - gpg_authentication "--list-key --with-colons --with-fingerprint 0x${keyID}!" - -This is obviously a little lame, but it seems to be necessary to do -the necessary argument passing from the function, to the su function -called as the monkeysphere user that controls the gpg authentication -keyring. - -I'm not sure how to fix it. I think the problem is mostly in how -arguments are passed to su. - --- Big Jimmy. diff --git a/website/bugs/handle-passphrase-locked-secret-keys.mdwn b/website/bugs/handle-passphrase-locked-secret-keys.mdwn deleted file mode 100644 index 5143db6..0000000 --- a/website/bugs/handle-passphrase-locked-secret-keys.mdwn +++ /dev/null @@ -1,117 +0,0 @@ -[[!meta title="MonkeySphere can't deal with passphrase-locked primary keys"]] - -At the moment, the only tool we have to export passphrase-locked -secret keys from the GPG keyring is `gpg` itself (and `gpg2`, which -has roughly the same behavior). - -As a result, we have the `seckey2sshagent` hack, which is unfriendly -and awkward to use. - -Ideally, `openpgp2ssh` would be able to convert passphrase-locked -secret keys into clean subkeys. However, i've tried to do this via -GnuTLS, and that library is not ready for this. - -OpenCDK, which is the component of GnuTLS which reads OpenPGP-style -keys, cannot cope with encrypted secret key material. I have had -[some -success](http://lists.gnu.org/archive/html/gnutls-devel/2008-06/msg00092.html) -in getting GnuTLS's OpenCDK to accept the existence of encrypted -secret key packets, [i learned that OpenCDK as included in GnuTLS is -incapable of dealing with the encrypted packets -themselves](http://lists.gnu.org/archive/html/gnutls-devel/2008-07/msg00012.html). - - -Some possible resolutions: - ---------- - -If we can assume that the passphrase-encrypted key we want to use is -actually a subkey, and if we could fix GnuTLS to ignore the use of the -"gnu-dummy S2K" produced by `gpg --export-secret-subkeys` for the -primary key, then something like the following script should actually -work for reasonable values of `$KEYID`: - - TMPDIR=$(mktemp -d) - umask 077 - mkfifo "$TMPDIR/passphrase" - kname="MonkeySphere Key $KEYID" - mkfifo "$TMPDIR/$kname" - ssh-askpass "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" & - gpg --passphrase-fd 3 3<"$TMPDIR/passphrase" \ - --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes \ - --export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname" & - (cd "$TMPDIR" && ssh-add -c "$kname") - rm -rf "$TMPDIR" - -Good news! [I've crafted a patch for GnuTLS to enable it to read -exported subkeys using this GNU -extension](http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html), -so if we can get it incorporated into upstream (and/or into debian), -we have a possible solution, as long as the authentication key is a -subkey, and not a primary key. - -As of version 0.11-1, `monkeysphere subkey-to-ssh-agent` implements -this particular strategy (and fails cleanly if the version of GnuTLS -present doesn't support the GNU dummy S2K extension). - ---------- - -Ben Laurie and Rachel Willmer's -[OpenPGPSDK](http://openpgp.nominet.org.uk) is a candidate: this is a -C-based library that intends to implement RFC 4880 functionality. - -We could potentially re-write `openpgp2ssh` using this library, and it -*should* be able to handle everything we need from the OpenPGP side -(though it might need to be re-linked to OpenSSL to handle PEM-encoded -exports. - -Concerns: - -* OpenPGPSDK is not in debian yet, and doesn't currently (2008-08-13) - build with gcc 4.2 or 4.3. - -* OpenPGPSDK uses the apache license and appears to link to OpenSSL, - which has a GPL-incompatible license. I think this would mean that - `openpgp2ssh` could not remain GPL (though the rest of the - monkeysphere could). - ---------- - -We could try to use perl. The last time i checked, the pure-perl -OpenPGP implementations all depended on Math::PARI, which [is not in -debian](http://bugs.debian.org/440527). The most likely candidate is -[Crypt::OpenPGP](http://search.cpan.org/~btrott/Crypt-OpenPGP), -despite [some -bugginess](http://cpanratings.perl.org/dist/Crypt-OpenPGP). - -Concerns: - -* the aforementioned buggy reviews - -* there's a lot of dependency chasing to get anything like this - available in debian. - ---------- - -Other alternatives? - --------- - -Can this bug be closed? dkg [reported in a comment for a related -bug](/bugs/install-seckey2sshagent-in-usr-bin/): - - Version 0.11-1 now has the monkeysphere subkey-to-ssh-agent - subcommand, which works cleanly in the presence of a - functionally-patched GnuTLS. - --------- - -Even with the patched GnuTLS, monkeysphere currently can't currently -deal with passphrase-locked primary keys. I've changed the title of -this bug, but i'd like to keep it open until we are able to deal with -that. The other comments here seem still quite relevant to that -need. - -I've changed the title of this bug to reflect the narrowed scope. - - --dkg diff --git a/website/bugs/headless-servers-take-too-long-to-generate-host-key.mdwn b/website/bugs/headless-servers-take-too-long-to-generate-host-key.mdwn deleted file mode 100644 index c7912de..0000000 --- a/website/bugs/headless-servers-take-too-long-to-generate-host-key.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -[[!meta title="Running `monkeysphere gen-key` on a headless server takes way too long"]] - -When i try to generate a key on a headless machine (no kbd, no mouse, -no Human Input Device (HID) at all), `monkeysphere gen-key` hangs for -a *very* long time (over an hour so far!) during the generation -process, particularly at this point: - - ms: generating server key... - - Not enough random bytes available. Please do some other work to give - the OS a chance to collect more entropy! (Need 197 more bytes) - -And sure enough, there really is very little entropy in these systems -at the time requested: - - 0 chomsky:~# cat /proc/sys/kernel/random/entropy_avail - 32 - 0 chomsky:~# - -It's not clear to me how to increase the entropy available to the -kernel without an HID. - -I've seen this happen on two machines now in the last week, and was -able to resolve it on the first one by plugging in a keyboard and -"massaging" it. This won't work for a machine that's out of physical -range, and has no keyboard to be plugged in anyway. - -One thing that might help is to suggest that the system administrator -install a package like `bsdgames` and play console-based games as a -non-privileged user, since that seems to feed the entropy count -somewhat. diff --git a/website/bugs/hostkeyalias-confuses-monkeysphere.mdwn b/website/bugs/hostkeyalias-confuses-monkeysphere.mdwn deleted file mode 100644 index 4f7df66..0000000 --- a/website/bugs/hostkeyalias-confuses-monkeysphere.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -Consider the following snippet in `~/.ssh/config`: - - Host foo - HostKeyAlias bar - -for a host which is *not* participating in the monkeysphere. - -For such a host, when using `monkeysphere-ssh-proxy-command`, the -public keyservers will be queried on each attempted ssh connection -(even after a successful connection). - -This appears to be because: - -* `ssh` itself will write a line to `~/.ssh/known_hosts`, but it will - be labeled with `bar` because of the `HostKeyAlias`. - -* `monkeysphere` won't be able to find any mention of it in the - keyring (it's not in the monkeysphere) - -* `monkeysphere-ssh-proxycommand` won't be able to find it in the - `known_hosts` file because it looks for `foo`, which is never - matched. - -excessive keyserver querying is bad behavior, because it causes delays -for the users, and puts excessive load on the public keyserver -infrastructure. - -How can we resolve this? diff --git a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn deleted file mode 100644 index 04322a4..0000000 --- a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn +++ /dev/null @@ -1,59 +0,0 @@ -[[!meta title="Install seckey2sshagent in /usr/bin/"]] - -I know it's a hack - but installing seckey2sshagent in /usr/bin/ would make it -much easier for people to use. - ---- - -I'm not sure I really want to include this hack with the debs. It's -really not useful for any kind of regular use. I would rather focus -on getting openpgp2ssh to support passprotected keys. - -As another possibility, I was planning on modifying the script so that -it could export to a passprotected file. I think this would be a lot -more useful. Let me get that working, then let's revist the issue of -including it in the packaging. - --- Big Jimmy - ---- - -Ok - sounds good to me. I'm thinking in terms of getting other people to try -out the Monkeysphere - maybe the README should just say: we're only half -done. You can verify the identity of servers, but we haven't completed the -part about verifying you to a server. Then it could say: if you're really -interested, you can run this hacky script but we make no guarantees. - --- Sir Jam Jam - ---- - -I just realized that i think i can test for the presence of [GNU-dummy -support in -GnuTLS](http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html), -which means that we can cleanly test whether the proposed [handling of -passphrase-locked secret -keys](bugs/handle-passphrase-locked-secret-keys/) is functional. With -that in mind, I'd like to propose that we could resolve this bug -simply by adding a new subcommand: `monkeysphere subkey-to-ssh-agent`, -which would fail in the absence of a functionally-patched GnuTLS. - -Would this proposal be sufficient to resolve this bug? - ---dkg - ---- - -Version 0.11-1 now has the `monkeysphere subkey-to-ssh-agent` -subcommand, which works cleanly in the presence of a -functionally-patched GnuTLS. - ---dkg - ---- - -I'm marking this bug as [[bugs/done]] - I no longer think we should install -seckey2sshagent in bin now that we have a clean way of accomplishing that task. -Nice work dkg! - ---sjj diff --git a/website/bugs/list-id-certifiers-should-run-non-priv.mdwn b/website/bugs/list-id-certifiers-should-run-non-priv.mdwn deleted file mode 100644 index 32116c0..0000000 --- a/website/bugs/list-id-certifiers-should-run-non-priv.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[!meta title="list-identity-certfiers should run as the non-privileged user"]] - -Right now, `monkeysphere-server list-identity-certifiers` runs as the -superuser, and just lists the keys in the host's keyring. This might -not be the actual list of valid id certifiers, for a number of reasons: - -* the keys themselves might have been revoked by the owner - -* the id-certifiers might have been added with a different trust - level, or a regexp/domain limitation. - -It would make more sense to derive the list of trusted certifiers -directly from the keyrings as seen by the non-privileged -`monkeysphere` user, since this user's keyrings are what are going to -judge the validity of various user IDs. - ---- - -[[bugs/done]] 2008-08-16 in a29b35e69d0fab5f2de42ed5edd9512a6552e75a diff --git a/website/bugs/make-tarball-is-not-idempotent.mdwn b/website/bugs/make-tarball-is-not-idempotent.mdwn deleted file mode 100644 index 8e207e4..0000000 --- a/website/bugs/make-tarball-is-not-idempotent.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -[[!meta title="make tarball is not idempotent" ]] - -The current monkeysphere Makefile has a "tarball" target, which -produces the "upstream tarball". Unfortunately, it is not idempotent. -That is, if you run it twice in a row (without changing any other -source), the second .orig.tar.gz file is bytewise different from the -first. - -We should fix this so that the tarball generated is the same at least -as long as no local file has been touched. - ---dkg diff --git a/website/bugs/missing-known_hosts-causes-error.mdwn b/website/bugs/missing-known_hosts-causes-error.mdwn deleted file mode 100644 index 5be0a44..0000000 --- a/website/bugs/missing-known_hosts-causes-error.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -[[!meta title="Missing `~/.ssh/known_hosts` file causes errors from monkeysphere-ssh-proxycommand"]] - -As a user, if you don't have a `~/.ssh/known_hosts` file, -`monkeysphere-ssh-proxycommand` produces some bogus output, like: - - cat: /home/foo/.ssh/known_hosts: No such file or directory - -this should be fixable with a simple test. - ------- - -Fixed in 70674cae8b3d69d0e750125387b26c0d5857c5ba. - -[[bugs/done]] 2008-08-12 diff --git a/website/bugs/monkeysphere-gen-key-should-guess-KeyID.mdwn b/website/bugs/monkeysphere-gen-key-should-guess-KeyID.mdwn deleted file mode 100644 index 0cab051..0000000 --- a/website/bugs/monkeysphere-gen-key-should-guess-KeyID.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -[[!meta title="`monkeysphere gen-key` should guess at KeyID if none provided"]] - -Currently, if you have a single private key in your GnuPG keyring, and -you call: - - monkeysphere gen-key - -(with no additional arguments), it will report an error. - -It would be more user-friendly if we could guess which key to use. I -suggest: - -* If the user only has no GPG secret keys at all, it should fail, and - suggest that the user create a key first, then re-run `monkeysphere - gen-key`. (`monkeysphere` could actually invoke `gpg --gen-key` for - the user directly, if the user wants that) - -* If the user only has one GPG secret key, it should use that key. - -* If the user has more than one GPG secret key, `monkeysphere` should - fail, and report the different key IDs that they user might want to - select (reporting which keys already have authorization subkeys or - the authorization capability on the primary key would be useful too) - -[[bugs/done]] completed 2008-08-08 09:40:33-0400 (to be released in 0.8-1) diff --git a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn b/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn deleted file mode 100644 index 1e33439..0000000 --- a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn +++ /dev/null @@ -1,144 +0,0 @@ -[[!meta title="monkeysphere --gen-subkey seems to fail if no gpg-agent is running"]] - -Consider the following transcript of a user who starts with no OpenPGP -key in the first place: - - 0 wt215@squeak:~$ monkeysphere gen-subkey - You have no secret key available. You should create an OpenPGP - key before joining the monkeysphere. You can do this with: - gpg --gen-key - 255 wt215@squeak:~$ gpg --gen-key - gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc. - This is free software: you are free to change and redistribute it. - There is NO WARRANTY, to the extent permitted by law. - - Please select what kind of key you want: - (1) DSA and Elgamal (default) - (2) DSA (sign only) - (5) RSA (sign only) - Your selection? 5 - RSA keys may be between 1024 and 4096 bits long. - What keysize do you want? (2048) 1024 - Requested keysize is 1024 bits - Please specify how long the key should be valid. - 0 = key does not expire - <n> = key expires in n days - <n>w = key expires in n weeks - <n>m = key expires in n months - <n>y = key expires in n years - Key is valid for? (0) 1 - Key expires at Sat 09 Aug 2008 09:41:34 AM EDT - Is this correct? (y/N) y - - You need a user ID to identify your key; the software constructs the user ID - from the Real Name, Comment and Email Address in this form: - "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" - - Real name: Foo T. Bar - Email address: monkey@example.org - Comment: DO NOT USE! - You selected this USER-ID: - "Foo T. Bar (DO NOT USE!) <monkey@example.org>" - - Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o - You need a Passphrase to protect your secret key. - - We need to generate a lot of random bytes. It is a good idea to perform - some other action (type on the keyboard, move the mouse, utilize the - disks) during the prime generation; this gives the random number - generator a better chance to gain enough entropy. - +++++ - gpg: key A09F70B7 marked as ultimately trusted - public and secret key created and signed. - - gpg: checking the trustdb - gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model - gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u - gpg: next trustdb check due at 2008-08-09 - pub 1024R/A09F70B7 2008-08-08 [expires: 2008-08-09] - Key fingerprint = C3D3 1063 7CA1 5809 9EB9 7A63 F4E4 8D01 A09F 70B7 - uid Foo T. Bar (DO NOT USE!) <monkey@example.org> - - Note that this key cannot be used for encryption. You may want to use - the command "--edit-key" to generate a subkey for this purpose. - 0 wt215@squeak:~$ monkeysphere gen-subkey - Please specify how long the key should be valid. - 0 = key does not expire - <n> = key expires in n days - <n>w = key expires in n weeks - <n>m = key expires in n months - <n>y = key expires in n years - Key is valid for? (0) 2 - ms: generating subkey... - gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc. - This is free software: you are free to change and redistribute it. - There is NO WARRANTY, to the extent permitted by law. - - Secret key is available. - - pub 1024R/A09F70B7 created: 2008-08-08 expires: 2008-08-09 usage: SC - trust: ultimate validity: ultimate - [ultimate] (1). Foo T. Bar (DO NOT USE!) <monkey@example.org> - - Key is protected. - - You need a passphrase to unlock the secret key for - user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>" - 1024-bit RSA key, ID A09F70B7, created 2008-08-08 - - gpg: Invalid passphrase; please try again ... - - You need a passphrase to unlock the secret key for - user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>" - 1024-bit RSA key, ID A09F70B7, created 2008-08-08 - - gpg: Invalid passphrase; please try again ... - - You need a passphrase to unlock the secret key for - user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>" - 1024-bit RSA key, ID A09F70B7, created 2008-08-08 - - gpg: Key generation failed: bad passphrase - - - Invalid command (try "help") - - ms: done. - 0 wt215@squeak:~$ - -This user does not have `use-agent` configured in `~/.gnupg/gpg.conf`. - -This problem can be resolved by the user doing: - - echo use-agent >> ~/.gnupg/gpg.conf - gpg-agent --daemon monkeysphere --gen-subkey - -Then they will be prompted for their passphrase during key creation. - -If we're OK with relying on `gpg-agent`, we should make make that an -explicit dependency, and ensure that an agent is running (or start one -up specifically for the process). - -If we're not OK with relying on the agent, `--gen-subkey` needs -fixing. - ---- - -I think requiring the agent and using it for getting the passphrase is -fine. That should make this bug fairly easy to fix, so I'll get on -it. - --- BJ (jgr) - ---- - -Alternately, we could use `--passwd-fd` and `ssh-agent`, along the -lines i proposed [for handling passphrase-locked secret -keys](/bugs/handle-passphrase-locked-secret-keys). - ---- - -[[bugs/done]] as of 2008-08-15 16:48:26-0400 (to be released in 0.8-1) - -I opted to go with the `ssh-askpass` route, and fall back to echoing -stuff to a fifo directly if `ssh-askpass` is not available. diff --git a/website/bugs/monkeysphere-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn b/website/bugs/monkeysphere-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn deleted file mode 100644 index 3c7e804..0000000 --- a/website/bugs/monkeysphere-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -If you have a revoked authentication subkey in your keyring, -monkeysphere gen-subkey thinks that I have an authentication subkey -already, which I do, but it probably shouldn't care about it, since it -is revoked: - - 21:30@pond> monkeysphere gen-subkey F67E2A5D1CF2D62A - An authentication subkey already exists for key 'F67E2A5D1CF2D62A'. - Are you sure you would like to generate another one? (y/N) - -However: this key was revoked on 2008-04-28 by DSA key 1CF2D62A Micah Anderson <micah@riseup.net> - sub 1024R/866F47D3 created: 2008-02-25 revoked: 2008-04-28 usage: A - -I can continue to create a new authorization subkey, so its not a -blocker or anything (I suppose I could also delete the revoked key -from my keyring as well, although thats less than ideal). - -It seems like the secret keyring doesn't mention that it has been -revoked, so probably monkeysphere needs to be looking at gpg's -computed validity from the public keyring instead of the secret -keyring to be able to get the "r" flag from field 2, in addition to -the "e" flag from field 12. - ---- - -So the problem is that there is no field 2 for secret keys. From -/usr/share/doc/gnupg/DETAILS.gz: - - 2. Field: A letter describing the calculated trust. This is a single - letter, but be prepared that additional information may follow - in some future versions. (not used for secret keys) - -Why would secret keys not have this field? They have validity too, -right? This doesn't make any sense. I verify that indeed there is no -output in field 2 for secret keys. I would say this is a bug in gpg, -but it's clearly done on purpose. Any ideas? - --- jrollins diff --git a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn b/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn deleted file mode 100644 index 421587a..0000000 --- a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!meta title="Monkeysphere should consult keyserver setting in gpg.conf"]] - -Currently, monkeysphere-ssh-proxycommand checks the following places to -determine which keyserver to use (in order of priority): - - * environment variable (MONKEYSPHERE_KEYSERVER) - * KEYSERVER variable in ~/.monkeysphere/monkeysphere.conf - * default value of subkeys.pgp.net - -It would be useful if monkeysphere also consulted ~/.gnupg/gpg.conf, using the -following order instead: - - * environment variable (MONKEYSPHERE_KEYSERVER) - * KEYSERVER variable in ~/.monkeysphere/monkeysphere.conf - * keyserver variable in ~/.gnupg/gpg.conf - * default value of subkeys.pgp.net - --- Sir Jam Jam - ---- - -[[bugs/done]] 2008-08-15 in ab5cfab5be64cfb5e01c2b660587da43b3097cad diff --git a/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn b/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn deleted file mode 100644 index b814d35..0000000 --- a/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn +++ /dev/null @@ -1,251 +0,0 @@ -I don't mind the monkeysphere-ssh-proxycommand output on regular connections. - -For me it looks something like this with a server not participating in the -monkey sphere: - - ms: processing host: chavez.mayfirst.org - ms: - key not found. - -And like this for a server participating: - - ms: processing host: george.riseup.net - ms: primary key found: 7353A74E3B757F8C - ms: * acceptable key found. - ms: known_hosts file updated. - -However, I have some batch scripts that run ssh that also provide -output, so the monkeysphere output clutters things up. - -I would really like to either have a -q/--quiet option, or, preferable for me -at least, would be for silent output to be the default and have a -v/--verbose -option to get the output. Or - maybe these should be environmental variables? -In any event - someway to suppress informational output would be a useful -improvement. - ------- - -I'd be fine with silent mode as a default, with a more verbose mode -accessible to the user who desires it. - -I'd prefer an environment variable (e.g. `MONKEYSPHERE_VERBOSE` or -`MONKEYSPHERE_DEBUG`) over a command-line (e.g. `--verbose`) option, -personally. It's more in keeping with the model we've used in general -so far. - ---dkg - ------- - -I just completed this feature. I published it to a separate branch -(called quiet-mode). I haven't committed it to my master branch for a -couple reasons: - - * I made some significant changes and wanted to ask Big Jimmy to take - a look since it's mostly his stuff I mucked about with. - - * Sometime between starting my hacking and mid-way through, my - ~.ssh/known_hosts file got truncted to nothing. I recovered from a - backup. I couldn't figure out what caused that to happen and couldn't - replicate it. I was debugging my bash and what I was debugging - involved bash redirection, so it's reasonable to think that something - I did caused the problem. However, before committing we incorporate - this, I would appreciate another set of eyes on my code to make sure - I'm not doing something dangerous or just dumb :). - -Here's an overview of what I did: - -There were two function defined in common that handle sending messages -to the user: log and loge. They both echo the argument passed to -standard error. The first one also echo's "ms: " (as a preface to the -message). loge was only called in two places and I think is left over -cruft (let me know if I'm wrong please!). - -I've added drop in replacement functions: notice, info, and -debug. I've replaced all instances of log and loge with info. - -If you use notice, your message will always be sent to standard error. -If you use info, it will be sent to standard error if the env variable -`MONKEYSPHERE_OUTPUT_QUIET` is set to off (it is off by default). If -you use debug, it will be sent to standard error only if -`MONKEYSPHERE_OUTPUT_DEBUG` is set to on (it's off by default). - -Lastly, in monkeysphere-ssh-proxycommand, I've set -`MONKEYSPHERE_QUIET_MODE` to on by default. - -So the result is: when using monkeysphere-ssh-proxycommand, you will -not get any output unless you set `MONEKYSPHERE_OUTPUT_QUIET` to off -or `MONKEYSPHERE_OUTPUT_DEBUG` to on. All other commands should work -exactly like they did in the past. - -And... we can go through the code and change calls to the info -function to either notice (if we want them to be sent regardless of -the `QUIET` variable) or debug (if we want it only sent if `DEBUG` is -set). - -I'm open to suggestions, problems, etc :). - --- SJJ - ------- - -Hey, your Royal Highness. I do think it's good that I look over these -changes, because there are definitely some stuff (ie. key processing) -that requires that things go to stderr and definitely not to stdout. -I can see that if that were changed, it's possible that things could -go wrong (ie. cause a `known_hosts` file to get truncated maybe). - -I have to say that I'm still not sure I totally see why it's necessary -to implement such nuanced output switches. All of the stuff you were -worried about when you reported this bug, and all the stuff that -starts with "ms:", goes to stderr. If you didn't want to see it, can -you not just redirect stderr to /dev/null? - -For what it's worth, I'm not sure *I* can ever imagine *not* wanting -to see that stuff, since it effectively reports on whether the host -you're connecting to is acceptable or not. I feel like I would always -want to see that. I guess that's neither here nor there, though, -cause if a user thinks it would be a good switch to have, and it's not -too difficult to implement (as this is), then it's worth implementing. - -I think before we really start trying to tackle this, though, we -should outline what is the behavior we ultimately want. What output -do we want to go to stdout, and do we want to be able to turn that off -or on? What output do we want to go to stderr, and do we want to be -able to turn that off or on? At the moment, most output is really -just info for the user, which is why I was sending it all to stderr. -Should all output then just go to stderr, with a switch to either turn -it off or on? - -I should point out that we're sort of hitting a bit of a bash -limitation here. Some monkeysphere internal functions pass info on to -other stuff via stdout, but also need to report stuff to the user as -well, which means this stuff can only be passed to the user via -stderr. - -In any event, I just want to outline a straightforward policy about -output so we can know how to best handle it. - --- Big Jimmy. - ------ - -I think it's important to be able to suppress "normal operation, -everything is fine" messages *without* directing stderr to -`/dev/null`. This is the normal state of UNIX-style tools, especially -tools like SSH which are used as piece of a larger toolchain. If -every tool in a toolchain emitted some output during successful -operation, many scripts would be hopeless seas of noise, as it's not -unusual for even a simple backup script to make use of a half-dozen -separate tools. - -What you really want is to see some output from when a tool knows -something is wrong. With the proxycommand, the job of complaining -will often be left up to `ssh` itself, after `~/.ssh/known_hosts` has -been appropriately modified. But sometimes, the proxycommand itself -will fail, and if you've already directed stderr to `/dev/null` you -won't get any reasonable information about the failure at the time it -happens. - -As for the interface to adjust the verbosity, HRH SJJ's current -proposal with a large number of environment variables seems confusing -and overly-complex to me. - -i think we should follow OpenSSH's lead (since all monkeysphere users -are likely to be somewhat familiar with it) and use a single variable -that is set to a level. For example, see `LogLevel` in -`ssh_config(5)`. It should probably default to `INFO`, same as -`/usr/bin/ssh`. If there was a way to extract this value from the -user's SSH configuration/invocation itself and adopt it in the -ProxyCommand, that would be even better, but i don't think that's a -possibility with OpenSSH 5.1p1 at this point. - -Also, i agree with HRH SJJ that the distinction in the monkeysphere -source between `log` and `loge` is unclear, and one of them should be -dropped (or they should be better-documented in `/src/common`). - - --dkg - ----- - -Thanks Big Jimmy and dkg all for the good feedback. - -I think you're right Big Jimmy about the sterr/stout. I may have -accidentally output to stout instead of sterr. In any event - I think -all of the logging should go to sterr to avoid that. - -Here's a proposed fix based on both of your responses - it tries to make -my changes a bit simpler and more consistent with ssh behavior: - - * Use on environmental variable: `MONKEYSPHERE_LOG_LEVEL` that can be set - to `ERROR` or `INFO`, with the default being `INFO`. - `monkeysphere-ssh-proxycommand`, however, will set the - `MONKEYSPHERE_LOG_LEVEL` to `ERROR` unless the user overrides that setting. - - * Use two functions for reporting messages to the user via sterr that - will replace the existing log/loge functions: info (for outputting - "normal operation, everything's fine" messages) and error (for - outputting messages that indicate a problem that we think a user should - know about). Reporting a message to the user with the info function - will only be sent if the `MONKEYSPHERE_LOG_LEVEL` setting is `INFO`. - Reporting a message to the user with the error function will always be - output regardless of the `MONKEYSPHERE_LOG_LEVEL` value. - - * Go through the code and, for each use of the current log/loge - function, determine if they should be replaced with info or error - depending on how critical we think the message is. - -How does that sound? - - --Sir Jam Jam - ------ - -Sir Jam Jam's proposal sounds good to me, but why make it two separate -functions? Given the number of log levels used by OpenSSH, i'd prefer -to make a single function that takes two arguments: the first argument -is the level of the log, and the second argument is the data to be -logged itself. So you'd say: - - log error "This is really terrible and broken!" - log info "The fuzzy bunny just smiled at you and nodded." - -Is that a reasonable amendment? It seems like it will make it easier -to add more levels if we find we need them, and it makes it easy to -find every single log message in the source code at the same time. - - --dkg - ------ - -I just implemented the proposal (incorporating dkg's suggestion about -only having one function). It's committed in my quiet-mode branch (still -not merged with master - pending review). - -Thanks for all the feedback! - --- SJJ - ----- - -Ok, this plans makes sense. I'll merge SJJ's patches as soon as I get -the chance. - --- BJ - ----- - -I implemented a variant of SJJ's proposed changes in -bb2427c28bf40179c4881b22c23f23f9bea78f55 (0.12 pre). I tried to make -it so that we could more easily expand the number of levels if need -be. I made a first pass at specifying which output is what priority, -but folks should please speak up if they think the priority of any -particular output should be changed. - -I'll leave the bug open for a bit until it get more tested and 0.12 -gets pushed out. - --- BJ - ---- - -I think this is [[/bugs/done]] as of version 0.12-1. diff --git a/website/bugs/multiple-hostnames.mdwn b/website/bugs/multiple-hostnames.mdwn deleted file mode 100644 index 9189ba8..0000000 --- a/website/bugs/multiple-hostnames.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[!meta title="Support multiple host names for monkeysphere-enabled servers"]] - -Some monkeysphere-enabled hosts answer to multiple host names, but the -current `monkeysphere-server` only generates a single User ID -corresponding to a single hostname. - -We should make it easier for machines with multiple names to create -multiple User IDs at `gen-key` time. - -We should also make it easy to add new hostnames (and remove outdated -ones). - -For example: `george.riseup.net` is now also known as -`monkeysphere.info`. It'd be nice to have a convenient way to add -that hostname to the key without mucking around with gpg directly. - ---- - -So how do we imagine the behavior here? I assume that basically it -would just add/remove user ID's to/from the host key locally. I guess -we will continue to rely on the "publish-key" subcommand to actually -publish all changes to the keys. - --- BJ (jgr) - ---- - -I think [when we reorganize the `monkeysphere-server` -shortcuts](reorganize-monkeysphere-server-shortcuts) it'll make it -clearer what the right interface should be. - -As for what should actually happen, i think that the server should -actively revoke old User IDs, rather than removing them. It should -probably prompt the administrator to re-publish the host key as well, -to ensure that the new User IDs are published. - - --dkg - -[[bugs/done]] on 2008-08-15 15:00:02-0400 in 84b775ff0b36ec4b86e6708844ad2d678eced403 diff --git a/website/bugs/posix_compliance.mdwn b/website/bugs/posix_compliance.mdwn deleted file mode 100644 index d418e98..0000000 --- a/website/bugs/posix_compliance.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -It would be nice to make all of the Monkeysphere scripts POSIX -compliant, for portability and light-weightedness. Better POSIX -compliance would probably at least be better for compatibility with -o{ther,lder} versions of bash. Unfortunately there are quite a few -bashism at the moment, so this may not be trivial. For instance: - - servo:~/cmrg/monkeysphere/git 0$ checkbashisms -f src/monkeysphere-server 2>&1 | wc -l - 50 - servo:~/cmrg/monkeysphere/git 0$ - -It looks like the biggest complication for this would be the -occasional use of bash arrays. diff --git a/website/bugs/postinst-clobbers-gpg.conf-settings.mdwn b/website/bugs/postinst-clobbers-gpg.conf-settings.mdwn deleted file mode 100644 index f7f2137..0000000 --- a/website/bugs/postinst-clobbers-gpg.conf-settings.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -[[!meta title="debian packaging postinst script clobbers gpg.conf settings in /var/lib/monkeysphere" ]] - -Do we want to allow the system administrator to make adjustments to -the `gpg.conf` config files found in `/var/lib/monkeysphere`? At the -moment, there are two such files: - - * `/var/lib/monkeysphere/gnupg-authentication/gpg.conf` - * `/var/lib/monkeysphere/gnupg-host/gpg.conf` - -In the debian postinst scripts (`debian/monkeysphere.postinst`), the -contents of those files are overwritten on every upgrade/reinstall, -effectively clobbering any changes made by the local admin. - -Maybe we *do* want to do this clobbering, though. Stuff in `/var` is -generally not expected to be modified by hand. I see two possible -resolutions to this: - - * when we clobber those files, include a comment along the lines of: - # do not make changes to this file! It is overwritten on each upgrade! - - * Avoid clobbering the files, and treat them as config files. - -the latter approach suggests that they should be more properly stored -in `/etc/`, though. This would give us all the conf-file tracking -apparatus, which is nice. If we do want to do that, I guess we'd -symlink to them from the monkeysphere-specific `$GNUPGHOME`s in -`/var/lib/monkeysphere`, since `gpg` does not seem to allow for -overriding the location of the `gpg.conf` independent of `$GNUPGHOME`. - ---- - -All the gpg.conf files now reside in /etc/monkeysphere, and are linked -in into the GNUPGHOMEs in /var/lib/monkeysphere. - -[[bugs/done]] on 2008-10-11 diff --git a/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn b/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn deleted file mode 100644 index 02e23e5..0000000 --- a/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn +++ /dev/null @@ -1,121 +0,0 @@ -[[!meta title="Problems with root-owned gpg keyrings"]] - -`/var/lib/monkeysphere/gnupg-host/` is root-owned, and the public -keyring in that directory is controlled by the superuser. - -We currently expect the `monkeysphere` user to read from (but not -write to) that keyring. But using a keyring in a directory that you -don't control appears to trigger [a subtle bug in -gpg](http://bugs.debian.org/361539) that has been unresolved for quite -a long time. - -With some of the new error checking i'm doing in -`monkeysphere-server`, typical operations that involve both keyrings -as the non-privileged user can fail with an error message like: - - gpg: failed to rebuild keyring cache: file open error - -Running the relevant operation a second time as the same user usually -lets things go through without a failure, but this seems like it would -be hiding a bug, rather than getting it fixed correctly. - -Are there other ways we can deal with this problem? - ---dkg - -Here is an example when using monkeysphere-server -add-identity-certifier on a host with a newly-installed monkeysphere -installaton. Note that running the same command a second time works -as expected: - - 0 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 - gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net - gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported - gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied - gpg: failed to rebuild keyring cache: file open error - gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model - gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u - gpg: next trustdb check due at 2009-03-30 - gpg: Total number processed: 1 - gpg: imported: 1 (RSA: 1) - Could not receive a key with this ID from the 'pool.sks-keyservers.net' keyserver. - 255 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 - gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net - gpg: key D21739E9: "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" not changed - gpg: Total number processed: 1 - gpg: unchanged: 1 - - key found: - pub 4096R/D21739E9 2007-06-02 [expires: 2012-05-31] - Key fingerprint = 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 - uid [ unknown] Daniel Kahn Gillmor <dkg@fifthhorseman.net> - uid [ unknown] Daniel Kahn Gillmor <dkg@openflows.com> - uid [ unknown] Daniel Kahn Gillmor <dkg@astro.columbia.edu> - uid [ unknown] Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net> - uid [ unknown] [jpeg image of size 3515] - sub 2048R/4BFA08E4 2008-06-19 [expires: 2009-06-19] - sub 4096R/21484CFF 2007-06-02 [expires: 2012-05-31] - - Are you sure you want to add the above key as a - certifier of users on this system? (y/N) y - gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported - gpg: Total number processed: 1 - gpg: imported: 1 (RSA: 1) - gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model - gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u - gpg: next trustdb check due at 2009-03-30 - gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc. - This is free software: you are free to change and redistribute it. - There is NO WARRANTY, to the extent permitted by law. - - - pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC - trust: unknown validity: unknown - [ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net> - [ unknown] (2) Daniel Kahn Gillmor <dkg@openflows.com> - [ unknown] (3) Daniel Kahn Gillmor <dkg@astro.columbia.edu> - [ unknown] (4) Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net> - [ unknown] (5) [jpeg image of size 3515] - - - pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC - trust: unknown validity: unknown - Primary key fingerprint: 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 - - Daniel Kahn Gillmor <dkg@fifthhorseman.net> - Daniel Kahn Gillmor <dkg@openflows.com> - Daniel Kahn Gillmor <dkg@astro.columbia.edu> - Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net> - [jpeg image of size 3515] - - This key is due to expire on 2012-05-31. - Please decide how far you trust this user to correctly verify other users' keys - (by looking at passports, checking fingerprints from different sources, etc.) - - 1 = I trust marginally - 2 = I trust fully - - - Please enter the depth of this trust signature. - A depth greater than 1 allows the key you are signing to make - trust signatures on your behalf. - - - Please enter a domain to restrict this signature, or enter for none. - - - Are you sure that you want to sign this key with your - key "ssh://pip.fifthhorseman.net" (9B83C17D) - - The signature will be marked as non-exportable. - - - gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied - gpg: failed to rebuild keyring cache: file open error - gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model - gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u - gpg: depth: 1 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 1f, 0u - gpg: next trustdb check due at 2009-03-30 - - Identity certifier added. - 0 pip:~# diff --git a/website/bugs/reorganize-monkeysphere-server-shortcuts.mdwn b/website/bugs/reorganize-monkeysphere-server-shortcuts.mdwn deleted file mode 100644 index c29a6f1..0000000 --- a/website/bugs/reorganize-monkeysphere-server-shortcuts.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!meta title="Reorganize monkeysphere-server shortcuts"]] - -Currently, `monkeysphere-server` supports three subcommands to adjust -the "identity certifiers": - -* `add-identity-certifier` (`a`) -* `remove-identity-certifier` (`r`) -* `list-identity-certifier` (`l`) - -Since [we also want to be able to add/remove multiple -hostnames](multiple-hostnames), i think we should change the shortcuts -from `a`, `r`, and `l` to `c+`, `c-`, and `c`. - -This would let us create new subcommands like: - -* `add-host-name` (`n+`) -* `revoke-host-name` (`n-`) -* `list-host-names` (`n`) - ---- - -[[bugs/done]] 2008-08-14 in 0181b6fc50824941e4f7ac3f535a216b8189568e diff --git a/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn b/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn deleted file mode 100644 index 33224db..0000000 --- a/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn +++ /dev/null @@ -1,94 +0,0 @@ -[[!meta title="revoke-hostname function revokes wrong hostname user ID"]] - -It appears that the monkeysphere-server revoke-hostname function will -occasionaly revoke the wrong hostname. I say occasionally, but it -seems to be doing it pretty consistently for me at the moment: - - servo:~ 0$ sudo monkeysphere-server n- servo.finestructure.net - The following host key user ID will be revoked: - ssh://servo.finestructure.net - Are you sure you would like to revoke this user ID? (y/N) y - gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc. - This is free software: you are free to change and redistribute it. - There is NO WARRANTY, to the extent permitted by law. - - Secret key is available. - - pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA - trust: ultimate validity: ultimate - [ultimate] (1) ssh://localhost.localdomain - [ultimate] (2). ssh://servo.finestructure.net - [ revoked] (3) ssh://jamie.rollins - [ revoked] (4) asdfsdflkjsdf - [ revoked] (5) ssh://asdfsdlf.safsdf - [ revoked] (6) ssh://bar.baz - [ revoked] (7) ssh://foo.bar - [ revoked] (8) ssh:// - - - pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA - trust: ultimate validity: ultimate - [ultimate] (1)* ssh://localhost.localdomain - [ultimate] (2). ssh://servo.finestructure.net - [ revoked] (3) ssh://jamie.rollins - [ revoked] (4) asdfsdflkjsdf - [ revoked] (5) ssh://asdfsdlf.safsdf - [ revoked] (6) ssh://bar.baz - [ revoked] (7) ssh://foo.bar - [ revoked] (8) ssh:// - - Please select the reason for the revocation: - 0 = No reason specified - 4 = User ID is no longer valid - Q = Cancel - (Probably you want to select 4 here) - Enter an optional description; end it with an empty line: - Reason for revocation: User ID is no longer valid - Hostname removed by monkeysphere-server 2008-08-16T17:34:02 - - pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA - trust: ultimate validity: ultimate - [ revoked] (1) ssh://localhost.localdomain - [ultimate] (2). ssh://servo.finestructure.net - [ revoked] (3) ssh://jamie.rollins - [ revoked] (4) asdfsdflkjsdf - [ revoked] (5) ssh://asdfsdlf.safsdf - [ revoked] (6) ssh://bar.baz - [ revoked] (7) ssh://foo.bar - [ revoked] (8) ssh:// - - gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model - gpg: depth: 0 valid: 1 signed: 2 trust: 0-, 0q, 0n, 0m, 0f, 1u - gpg: depth: 1 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 2f, 0u - gpg: next trustdb check due at 2012-01-07 - sec 1024R/9EEAC276 2008-07-10 - Key fingerprint = C094 43E0 6882 8BE2 E9AD 516C 45CF 974D 9EEA C276 - uid ssh://servo.finestructure.net - uid [ revoked] ssh://localhost.localdomain - uid [ revoked] ssh://jamie.rollins - uid [ revoked] asdfsdflkjsdf - uid [ revoked] ssh://asdfsdlf.safsdf - uid [ revoked] ssh://bar.baz - uid [ revoked] ssh://foo.bar - uid [ revoked] ssh:// - - NOTE: User ID revoked, but revokation not published. - Run 'monkeysphere-server publish-key' to publish the revocation. - servo:~ 0$ - -Clearly this is unacceptable. gpg does not let you can't specify a -uid to revoke from the command line. The uid revokation can only be -done through edit-key. We do edit-key scripting in other contexts, -but to revoke a user id you have to specify the uid by "number". We -currently try to guess the number from the ordering of the output of -list-key. However, this output does not appear to coincide with the -ordering in edit-key. I don't have a good solution or fix at the -moment. Suggestions are most welcome. It may just require some trial -and error with edit-key to come up with something workable. - -This underlines the problem that gpg is currently not very well suited -for manipulating gpg keyrings non-interactively. It's possible that I -just haven't figured out how to do it yet, but it's not very clear if -it is possible. It would be nice to have some alternate tools to use. - --- Big Jimmy. diff --git a/website/bugs/setup-subcommand-for-monkeysphere-server.mdwn b/website/bugs/setup-subcommand-for-monkeysphere-server.mdwn deleted file mode 100644 index 99c6149..0000000 --- a/website/bugs/setup-subcommand-for-monkeysphere-server.mdwn +++ /dev/null @@ -1,56 +0,0 @@ -[[!meta title="proposed new monkeysphere-server subcommand: setup" ]] - -What if everything that's done in the package post-installation -scripts (aside from maybe the creation of the monkeysphere user -itself) was done with a single call to something like - - monkeysphere-server setup - -This would make things more obvious to folks installing from source -directly, and put less maintenance load on porters. The end of -`monkeysphere-server setup` could also invoke `monkeysphere-server -diagnostics` to get the admin pointed in the right direction. - -Think of this as a sort of automated "Getting Started" documentation. - -Of course, a hypothetical *full* setup command would do things like -`gen-key`, auto-modify `sshd_config`, etc. We wouldn't want to do -those things automatically without the guiding hand of the local -sysadmin. - -But perhaps we could even smooth that process with: - - monkeysphere-server setup --full - -I'd like to know what other folks think about these possibilities. -Would either of these be useful? Are they confusing? Could they be -clarified? - ---dkg - ---- - -I'm not sure how I feel about this idea. I feel like it should just -be the job of the package to setup the initial server environment. I -don't really feel like the admin should have to worry about it. But -then again, I can sort of see it from the point of view of someone -just installing from source (but who the hell really does that -anymore anyway?). - -I'm also sort of mixed about the setup --full idea as well. At first -I thought that it wasn't a good idea, and that I didn't like the idea -of monkeysphere monkeying around with the config files of other -packages (ie. ssh). However, once I started to think about setting up -monkeysphere on lots of servers, I started to think that it's maybe a -good idea. It might be good to have a single command that would just -end with the server being on the monkeysphere: - - * generate the server key - * modify sshd to point to it - * restart ssh - * publish the key to the keyserver - -So I'm starting to think that this might be a good idea. Also curious -what other think. - --- jrollins diff --git a/website/bugs/setup-test-server-for-public.mdwn b/website/bugs/setup-test-server-for-public.mdwn deleted file mode 100644 index 6df1fbf..0000000 --- a/website/bugs/setup-test-server-for-public.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -[[!meta title="Setup test public server/gpg key"]] - -It would be really useful for people trying out the monkeysphere to be able to -test it with a participating server as soon as they've finished setting things -up. Minimally - just testing the acceptance of the server's identity would be -great. - ---- - -I guess we don't really want to use george for this purpose? Does -someone have a spare virtual machine that we could use for this -purpose? The test machine wouldn't actually have to do any user -authentication, I guess. - --- Big Jimmy. - ---- - -Maybe we should use George? As you point out - it doesn't actually -have to do any user authentication. It seems like a waste to have a -virtual machine that does nothing but deny people's ssh connections. -And - george is already setup and ready to go. --- Sir Jam Jam - ---- - -I like the idea of using George for this. There's nothing wrong with -denying people's ssh connections. Also, we could make public user -account with limited shells that we could add User IDs that we want to -encourage to try out the monkeysphere from that perspective. For -example, if one of the George admins who is listed as an -identity-certifier has already certified Foo T. Bar's key, we could -write a simple note like: - - Dear Foo T. Bar-- - - The user account "foo@george.riseup.net" has been created for - you. You can ssh into it by adding an authentication subkey - to your OpenPGP key and publishing it to the public keyservers - (or to george.riseup.net). The easiest way to do this is with - the monkeysphere. - - You can verify george's ssh host key with the monkeysphere - before you connect to the host. Here's how... - ---dkg - ---- - -So do we agree that george is doing what we want, and we can therefore -close this bug? - --- BJ (jgr) - ---- - -I'm fine with closing this bug, unless we want to set up the limited -shell access/welcome letter like i described above. If we want to do -that, it'd be worth keeping it open until those scripts are written. - -I envision a script you'd invoke like: - - root@george# addmsuser foo 'Foo T. Bar <foo@example.org>' - -Which would create the `foo` account, populate -`~foo/.monkeysphere/authorized_user_ids`, make a note in a log -someplace, and send a welcome letter. - ---dkg - ---- - -That idea really seems like a lot more trouble than it's worth to me, -and I'm not really willing to maintain it myself, but if someone else -wants to handle that, that would be fine with me. - --- jgr - ---- - -i'm not really willing to maintain anything extra either, so i'm -closing this ticket as [[bugs/done]]. - ---dkg diff --git a/website/bugs/ssh-connection-refused-with-proxycommand.mdwn b/website/bugs/ssh-connection-refused-with-proxycommand.mdwn deleted file mode 100644 index afd59f1..0000000 --- a/website/bugs/ssh-connection-refused-with-proxycommand.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -I added the following to my .ssh/config: - - Host * - ProxyCommand monkeysphere-ssh-proxycommand %h %p - -So that the monkeysphere would be used for all my connections. - -However, I can no longer connect to any hosts. Here's example out put: - - 0 jamie@liberace:bugs$ ssh root@chavez.mayfirst.org - ms: processing host: chavez.mayfirst.org - ms: - key not found. - ssh_exchange_identification: Connection closed by remote host - 255 jamie@liberace:bugs$ - -The server auth.log has nothing in it. - ------- - -The problem was that the shebang line was `#!/bin/sh -e` instead of -plain ol' `#!/bin/sh` - -[[bugs/done]] 2008-07-29 11:18:42-0400 (released in 0.6-1) diff --git a/website/bugs/ssh_config_files_not_parsed.mdwn b/website/bugs/ssh_config_files_not_parsed.mdwn deleted file mode 100644 index ca851a8..0000000 --- a/website/bugs/ssh_config_files_not_parsed.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -In `~/.ssh/config`, i have: - - HashKnownHosts No - -But when `monkeysphere-ssh-proxycommand` adds new hosts to -`~/.ssh/known_hosts`, they appear to be added in a hashed form, -instead of in the clear. - -fwiw: i'm using OpenSSH 5.1p1 on a debian lenny system (backported -from sid) - ---- - -I can confirm this too (I'm running openssh-client 1:4.7p1-12) - --- Jamie (Jam Jam) - ---- - -There is absolutely no attempt by any monkeysphere utility to parse -any ssh or sshd config file. This will probably need to be delt with -down the line, but it's not a particular easy task at the moment. - --- Big Jimmy. - ---- - -I've [posted to the `openssh-unix-dev` list to see if there is a -possibility of openssh making our lives easier -here](http://marc.info/?l=openssh-unix-dev&m=121804767122918&w=2), but -i haven't had much of a response yet. - ---dkg - ---- - -For some reason this didn't get mentioned in this bug earlier, but -there is a monkeysphere config variable about hashing known_hosts -lines, which is set to true by default (to be in sync with the Debian -openssh-client package). - -I think this bug is really more about the fact that monkeysphere does -not parse the ssh config files for any directives relavent to what the -monkeysphere is doing. I'm changing the name of this bug to reflect -what the real issue is. - --- Big Jimmy. diff --git a/website/bugs/use_getopts_instead_of_getopt.mdwn b/website/bugs/use_getopts_instead_of_getopt.mdwn deleted file mode 100644 index 2ec68d6..0000000 --- a/website/bugs/use_getopts_instead_of_getopt.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -Since Monkeysphere is using bash, it would be nice to use the shell -build in getopts function, instead of the external getopt program. -This would reduce an external dependency, which would definitely be -better for portability. - ---- - -So it looks like the sh built-in getopts does not include long options -(eg. "--expire"). Is it worth getting rid of the long options for -this? - ---- - -Why not just get rid of getopts altogether and perform a simple -argument-processing loop with bash string tests? We're only invoking -getopt in three places, and each invocation is no more complex than -three arguments -- and most arguments take a separate parameter, which -means that handling tricky arg blobs like -aCxr are not gonna be -supported anyway. diff --git a/website/bugs/useful_information.mdwn b/website/bugs/useful_information.mdwn deleted file mode 100644 index 025d678..0000000 --- a/website/bugs/useful_information.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -I would like to know, at INFO (default) log level, when the -monkeyspehere makes a "real" modification to my known\_hosts file; that -is, when it adds or deletes a key. - -Apparently this is hard because monkeysphere is currently configured to -delete all keys and then add good keys, so a key added for the first -time seems to the monkeysphere very similar to a key re-added ten -seconds after last login. - -Still, from a UI perspective, I want to know what monkeysphere is doing. - ------- - -It looks like jrollins committed a change for reporting at INFO level -when a host key gets added by the monkeysphere: -2459fa3ea277d7b9289945748619eab1e3441e5c - -When i connect to a host whose key is not already present in my -known_hosts file, i get the following to stderr: - - ms: * new key for squeak.fifthhorseman.net added to known_hosts file. - -This doesn't fully close this bug, because we aren't notifying on key -deletion, afaict. - ------- - -So current log level DEBUG will output a message if the known host -file has been modified. If the issue is that you want to know at the -default log level everytime the known\_hots file is modified, then we -should just move this message to INFO instead of debug, and then maybe -remove the message that I added above. I was under the impression -that the issue was more about notification that a *new* key was added -to the known\_hosts file, and therefore the new INFO message above -fixed that problem. Should we do this instead? - -In general, more verbose log levels *do* tell the user what the -monkeysphere is doing. Moving to DEBUG log level will tell you pretty -much everything that happens. I do *not* think that this should be -the default log level, though. - ------- - -I wouldn't want to see an extremely verbose default log level. But i -do think that saying something like "key blah blah blah was stripped -from your known\_hosts file because it was expired" (for example) -would be useful. I think this case would occur infrequently enough -that it is worth reporting in the UI at the regular log level. - - --dkg |