[[!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