On Fri, Sep 02, 2005 at 06:51:20PM +0200, Richard Atterer wrote:
>> On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote:
> >> But no one has yet answered my question: *why* are there ABI
> >> differences between the gnutls and openssl builds?
> To the best of my knowledge (I could be wrong), ATM the only ABI difference
> is that when OpenSSL is used,
> curl_easy_setopt(handle, CURLOPT_SSL_CTX_FUNCTION, param)
> is supported. That CURLOPT_SSL_CTX_FUNCTION code cannot be supported if
> GnuTLS is used because GnuTLS does not offer comparable functionality.
> "param" above is a pointer to an OpenSSL SSL_CTX struct. According to the
> curl_easy_setopt manpage:
(Side note. This blows out of the water any argument that libcurl3 hides
OpenSSL usage from the using library, for GPL terms. This makes the user
_directly_ depend on OpenSSL, making it as clear as if the client was
doing dlopen("libssl.so.0.9.7") themselves.)
> This function gets called by libcurl just before the initialization of an
> SSL connection after having processed all other SSL related options to
> give a last chance to an application to modify the behaviour of openssl's
> ssl initialization.
> IMHO this incompatibility is quite minor - very few programs will actually
> register that callback. However, Daniel (curl upstream) believes it
> possible that future versions of the library will provide other SSL-related
> hooks of this sort.
CURLcode curl_easy_setopt(CURL *curl, CURLoption option, ...);
hasn't changed.
Uhh... This isn't an ABI change per se.
Heck, the API hasn't even changed in a compilationally-significant way.
Adding values to this API would require a versioned build-depends and
versioned depends in the client, but old programs would not need either
a recompile, or any changes before being recompiled.
You can just return CURLE_FAILED_INIT if this option is given on a non-openSSL
version of libcurl. (As documented at the end of curl_easy_setopt(3).)
Maybe add it to curl-config --features if it _needs_ to be checked
programatically at compile-time? (Yuck!)
As far as packaging goes, this means you get the following packages:
libcurl3, providing libcurl3-openssl (linked against OpenSSL to avoid breaking
sarge packages that use this functionality)
libcurl3-gnutls (linked against gnuTLS, doesn't support SSL_CTX_FUNCTION)
libcurl3-dev (Do we need a second -dev? Static linking maybe requires it? If
this becomes a testable feature, then a second -dev is definately needed.)
Packages which don't use SSL_CTX_FUNCTION can Depend on either libcurl3 |
libcurl3-gnutls, or if they're GPL'd can depend on libcurl3-gnutls only.
Packages which need SSL_CTX_FUNCTION can depend on libcurl3-openssl
grepping the source of libcurl3's direct rdepends should tell you which
packages in Debian need SSL_CTX_FUNCTION.
GPL'd packages which need SSL_CTX_FUNCTION are out of luck. And have always
been so.
Before etch ships, no package should depend on libcurl3, they should depend on
libcurl3-openssl or libcurl3 | libcurl3-gnutls or libcurl3-gnutls.
After etch ships, upload:
libcurl3, providing libcurl3-gnutls (linked against gnuTLS)
libcurl3-openssl, providing libcurl3 (linked against openSSL)
libcurl3-dev
At this point, packages who don't like having libcurl3-gnutls is their
Depends line can do a versioned depends on libcurl3, which won't match
the libcurl3 virtual dependancy provide by libcurl3-openssl, and will
also prevent them accidentally linking against an openSSL version of
libcurl3. (At least, I _think_ that's how versioned dependancies on
virtual packages work. Possibly they'll _always_ match, in which case a
Conflicts is in order instead.)
Packages which aren't GPL'd and aren't using SSL_CTX_FUNCTION can return to
depending on just libcurl3. (Although they may not want to until etch+2 to
support cleaner partial upgrades?)
That way partial sarge->etch upgrades are safe (anything using libcurl3
gets the one supporting SSL_CTX_FUNCTION if you upgrade libcurl3 first, and
applications upgrade first will pull in the correct libcurl3)
etch++ partial upgrades are also safe, as anything in etch will indicate which
category it falls into (SSL_CTX, GPL or agnostic) by dependancies, so the
correct libcurl3 libraries from etch+1 will get pulled in.
And etch+1 ships with a GPL-safe gnuTLS-linked libcurl3, with an alternative
libcurl3 available if any packages need it.
And in the meantime, no programs break surprisingly. The only time you lose
prorgram's functionality is if you're using non-Debian stuff that needs
SSL_CTX_FUNCTION after the post-etch upload, and you've not got equivs or
something protecting that "stuff" from having libcurl3-openssl replaced with
libcurl3. You might find that programs conflict and you need to make a choice
of some kind, but apt will _tell_ you when that happens, it won't break
silently. And non-SSL_CTC third-party software will never lose
ABI-compatibility.
The _problem_ with this setup is you can't parallel-install a GPL'd
libcurl3-using application and an application that uses SSL_CTX_FUNCTION
(as libcurl3 and libcurl3-gnutls must conflict as they provide shared libs
with the same soname/sover. As you'd expect as they're ABI-compatible,
albeit functionaly different.) The impact of this should be taken into
account, and balanced against the fact that right now, we can't have
a GPL'd libcurl3-using application installed at all. ^_^
There are possibly some optimisations that could be made above with Conflicts.
Maybe both -openssl and -gnutls should provide libcurl3, all users depend on
libcurl3, and GPL packages conflict with libcurl3-openssl and SSL_CTX_FUNCTION
users conflict with libcurl3-gnutls. I'm not sure if this is an improvement...
And of course a libcurl4 which doesn't expose internal SSL implementation
details to the library user would allow us to short-cut a whole load of
this stuff. ^_^
> On Sat, Sep 03, 2005 at 12:47:06AM +1000, Paul TBBle Hampson wrote:
>> If I've understood correctly, it is because curl expects the client program
>> or library to -lgnutls or -lopenssl and therefore provide the SSL symbols
>> to match the symbols which that build of the .so file is expecting.
>>
>> This is the point I move from suggesting things to spectating, 'cause I
>> can't wrap my head above the reason for the above.
> No, you're mixing things up. I believe you're talking about what is
> described towards the end of
> <http://curl.haxx.se/legal/distro-dilemma.html>. Whenever libcurl switches
> to the described mechanism, then _at_that_moment_ it might be necessary to
> increase the .so version.
> That's because programs are then required to link explicitly against one of
> the SSL-enabling "backend libs", called "lib2" on the page above. You don't
> suddenly want your old libcurl3-using programs to fail with run-time link
> errors...
Quite probably. Certainly _something_ confused me. ^_^
I think the backend libs thingy is kinda awful-looking, and rather unneccesary
under the current circumstances, adding ABI differences we don't actually need.
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
Attachment:
pgpj8mqsDc8sn.pgp
Description: PGP signature