updating documentation (incl. debian/changelog) to reflect new subkey-to-ssh-agent...

[monkeysphere.git] / website / bugs / install-seckey2sshagent-in-usr-bin.mdwn

diff --git a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
index 5b19b133b0a6a906eaacb0e6a57c6071af4c457f..e2c26822d86fa980e5af216e20ac49ef9302389a 100644 (file)
--- a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
+++ b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
@@ -25,3 +25,27 @@ 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