From c0fed884906cc1a55f447449d323e96397952ee9 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Thu, 21 Aug 2008 01:57:00 -0400 Subject: updating documentation (incl. debian/changelog) to reflect new subkey-to-ssh-agent subcommand. --- website/bugs/install-seckey2sshagent-in-usr-bin.mdwn | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to '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 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 -- cgit v1.2.3