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
Received on 2012-03-16