summaryrefslogtreecommitdiff
path: root/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn
blob: e2c26822d86fa980e5af216e20ac49ef9302389a (plain)

[[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, which means that we can cleanly test whether the proposed handling of 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