From: Daniel Stenberg
On Thu, 15 Mar 2012, Elli? Computing Open Source Program wrote:
I?m working on the interface of our soft,
Can I just mention that calling it 'soft' is very unusual in English. Call
it
software or program.
damned, everybody in France tells a 'soft'... again a false friend...
and providing two paths for a single key in the UI (public and private)
is
somewhat redundant, knowing that the private key format for SSH2 contains
enough information to reconstruct the public key, although I understand
that
for performance reason one might want to provide the public key directly.
libssh2's API had this restriction and AFAIR it still has depending on what
crypto backend it was built to use. It has been the only reason really.
indeed I realize that the libgrypt backend does not support it, I was a bit
quick on that...
OK so here is my proposal: could we consider CURLOPT_SSH_PUBLIC_KEY_FILE
not
set when private key is as being ?normal? and mean ?pass publickey=NULL
to
libssh2_userauth_publickey_fromfile_ex ()? ?
libssh2_userauth_publickey_fromfile_ex will indeed compute the public key
from the private key in that case, which is maybe a bit slower but much
more
practical.
I would expect that to already work like that but as you ask I figure it
doesn't. Yes I think not setting CURLOPT_SSH_PUBLIC_KEY_FILE would make it
be
NULL internally and passed as a NULL to libssh2.
I propose that setting CURLOPT_SSH_PUBLIC_KEYFILE option to a zero-long
string be interpreted as NULL for libssh2.
This value is a total nonsense for a file name(==never used by anybody for
something working) and would be thus a good candidate.
Regards
Armel
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
