Bugs item #1924441, was opened at 2008-03-24 23:59
Message generated for change (Comment added) made by phnixwxz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1924441&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SSL/TLS
Group: portability problem
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Scott Cantor (scantor)
Assigned to: Daniel Stenberg (bagder)
Summary: SSL callback option with NSS-linked libcurl

Initial Comment:
I got a report that Fedora is now linking libcurl to NSS instead of OpenSSL, and I think there's a portability issue for applications using the SSL context callback option, since at least the OpenSSL version of that feature uses an OpenSSL-specific structure.

I think the NSS implementation may just not support the callback option yet, but I'm not sure because the code was failing a bit earlier, when setting the allowable cipher suites.

Regardless, if it had run, it would have crashed, and that's not good either.

I would say that use of the context option might need some kind of way to protect against this, but I'm not sure what to suggest yet.

Perhaps there needs to be an option added to "set" the allowable SSL implementation(s) so that code that's using non-portable options can detect a failure at runtime during curl handle setup and fail out before the code just breaks during a connection.

----------------------------------------------------------------------

Comment By: Xianzhu Wang (phnixwxz)
Date: 2008-06-03 11:31

Message:
Logged In: YES
user_id=2106038
Originator: NO

The Google Gadgets for Linux project
(http://code.google.com/p/google-gadgets-for-linux) depends on the ability
to hook SSL handle creation to add customized certificate domain matching
rules. It works for OpenSSL, but not for GnuTLS and NSS.

I think either of the following solutions is OK:
1. Add CURLOPT_SSL_CTX_FUNCTION for other crypto libraries, and provide a
better way to let the program know which library is being used;
2. Add other callbacks, for example CURLOPT_SSL_CHECK_CERT_FUNCTION.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-03-26 03:29

Message:
Logged In: YES
user_id=1110
Originator: NO

I've now updated the curl_easy_setopt man page to clearly spell it out
that CURLOPT_SSL_CTX_FUNCTION only works if libcurl is built against
OpenSSL.

I also committed a change that now makes curl_easy_setopt() properly
return an error if the option is set in a libcurl that isn't built against
OpenSSL so that applications can in fact notice this.

Regarding my curl_version_info() idea, I was actually suggesting that we
would introduce a new member in the struct with some kind of defined values
or something for the particular SSL libraries libcurl supports so that an
application could check that easily. I didn't mean to imply that this
checking is easy as things are now.

As far as this bug goes, I think we can say it is now officially closed.
I'm indeed willing to discuss these matters further on the mailing list and
how we can make life easier to applications that may end up using libcurls
powered with different SSL libraries.

----------------------------------------------------------------------

Comment By: Scott Cantor (scantor)
Date: 2008-03-25 23:09

Message:
Logged In: YES
user_id=96701
Originator: YES

Thanks, I agree with your response, with a couple of notes:

- I don't *think* the docs on that callback option explicitly say that
it's for OpenSSL only, even though I assumed it probably was. If you don't
currently plan to add support for library-specific callbacks, you may want
to add that to the page.

- The notes on the version info API are a little vague about what to look
for because they seem to assume OpenSSL is in use. I think you're saying I
can just scan the string for OpenSSL, but it would be best to document that
since you're implying I should code my application to depend on it for
reliable behavior.

Otherwise I agree that this can be closed and I'll take any further
comments to the list.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-03-25 05:43

Message:
Logged In: YES
user_id=1110
Originator: NO

Thanks for your report!

The CURLOPT_SSL_CTX_FUNCTION dependency on OpenSSL is well known although
possibly not properly documented. It can of course be seen as a bug, but
one that we've known about since the day we added support for other libs
(April 2005). Only the OpenSSL-powered code in libcurl can call that
callback. We're open for discussions on how to fix this situation in a good
manner, but I think this is better kept on the curl-library mailing list
than in a bug tracker entry.

And instead of "an option added to set the allowable SSL
implementation(s)" I would rather applications could use
curl_version_info() to extract that info and take action based on the
returned data.

Taken everything this into account, this bug entry will be closed marked
"later" unless you or anyone else either points out any serious problem
with this approach or steps up and makes these changes start to happen.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1924441&group_id=976
Received on 2008-06-03