Junio C Hamano <gitster@xxxxxxxxx> writes:
> I agree that would be a better approach in the longer term. There is no
> point in many projects that use libcURL reinventing the wheel that could
> be in the shared library.
>
> Perhaps we could do both ;-).
>
> That is, (1) give libcURL a way to allow callers ask if the key/cert is
> encrypted, and then (2) on git side we only add code to ask libcURL using
> that interface _only if and when available_; otherwise we do not even try
> to bypass layers but just ask the user to tell us via configuration (or
> command line).
I guess I somewhat misread what you were saying (and I seem to be doing
this more often recently---I should slow down).
For key/cert type, the current cURL interface you used expects the caller
to say "I am giving you the name of the cert file, and the file is of this
type". I think the usability enhancement would be something like "Here is
the cert file; it should be one of the types supported by you (I do not
know nor care what exact type it is, but the end user tells me that you
should be able to use it). Please do whatever necessary with it."
For key/cert passphrase, the current cURL interface we use expects the
caller to give a string value via setopt. I wonder if there already is an
existing interface to give a callback function that is responsible for
doing user interaction and return a string? The best case would be to use
such an interface if available; otherwise, it would be good to add such an
interface to libcURL for us and other people to use.
I imagine the user would look something like this:
static char *ssl_cert_password;
static const char *callback(const char *hint, int trial, void *cb)
{
char buf[256];
if (!trial)
return ssl_cert_password ? ssl_cert_password : "";
if (5 < trial) {
error("Wrong passphrase. Giving up...");
return NULL;
}
sprintf(buf, "Passphrase to unlock %s: ", hint);
ssl_cert_password = getpass(buf);
return ssl_cert_password;
}
where
(1) The calling program (i.e. us) sets the address of the callback
function via curl_easy_setopt() when registering a key/cert file;
(2) When libcURL needs to unlock the key/cert file and sees such a
callback registered, it is called with "hint" (probably the filename
of the key/cert file it is trying to unlock), trial count (initially
zero) and an arbitrary callback data the program passed when it
registered the callback in the step (1). The callback is expected to
return a passphrase string.
(3) The callback can return an empty string to tell the library to try
using an empty passphrase (aka unencrypted keyfile).
(4) If the returned string does not unlock the key/cert file
successfully, libcURL is expected to call the callback with the same
hint/cb but trial count incremented. The callback can return NULL to
signal that the user/program gave up.
That way, we wouldn't even have to make a "trial connection" we earlier
discussed. The first request to make a connection we make into the
library can also serve as the "trial connection".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html