(Thread moved here from curl-users)

I'm adding support for SSH private keys into curl by reusing the --key
option and adding a new --pubkey option. These map directly onto the
CURLOPT_SSH_PRIVATE_KEYFILE and CURLOPT_SSH_PUBLIC_KEYFILE options,
respectively. However, --key now sets both CURLOPT_SSH_PRIVATE_KEYFILE and
CURLOPT_SSLKEY internally, which is a little silly but not really a problem.

However, I now want to support the --pass option similarly. I could create
a new option CURLOPT_SSH_PRIVATE_KEYFILE_PASSWD and have it work similarly,
setting both CURLOPT_SSLKEYPASSWD and CURLOPT_SSH_PRIVATE_KEYFILE_PASSWD, but
what's the point? SSH and SSL are mutually incompatible and I could
just redefine CURLOPT_SSLKEYPASSWD to work on SSH keys too, and even create
an alias CURLOPT_SSH_PRIVATE_KEYFILE_PASSWD which is the same value as
CURLOPT_SSLKEYPASSWD. Which is better?

On a similar note, several of the curl error codes contain essentially
duplicate versions of many codes, one for each protocol type
(e.g. CURLE_TFTP_NOTFOUND, CURLE_FTP_COULDNT_RETR_FILE,
CURLE_REMOTE_FILE_NOT_FOUND and CURLE_FILE_COULDNT_READ_FILE all mean the
same thing--that the file in the URL could not be found). This also is
a bit silly. I'd like to map some of the SCP/SFTP error codes to new
values to break out some of the different error classes for applications,
but I don't really want to create yet another error code that means 'remote
file not found'.

It would be nice to consolidate some of these error codes, keeping source
compatibility by using additional macros, but this would need to wait until
the next library SONAME revision bump to maintain binary compatibility.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved