summaryrefslogtreecommitdiff
path: root/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'website/bugs/install-seckey2sshagent-in-usr-bin.mdwn')
-rw-r--r--website/bugs/install-seckey2sshagent-in-usr-bin.mdwn10
1 files changed, 9 insertions, 1 deletions
diff --git a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
index 0163727..e2c2682 100644
--- a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
+++ b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
@@ -35,9 +35,17 @@ 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 authkey-to-agent`,
+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