Bug#828608: xmltooling: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Wed, Nov 09, 2016 at 09:26:00PM +0000, Cantor, Scott wrote:
> On 11/9/16, 3:55 PM, "Pkg-shibboleth-devel on behalf of Kurt Roeckx" <pkg-shibboleth-devel-bounces+cantor.2=osu.edu at lists.alioth.debian.org on behalf of kurt at roeckx.be> wrote:
> 
> > Can I just say this is really ugly code? It's called "internal",
> > you really have no business of touching this. And that just for
> > some debug log.
> 
> The debugging information is a minor portion of the functionality. I have every business touching it, this is how Shibboleth enforces requirements on a TLS certificate. The SSL_CTX callback is the only way to do this evaluation with the necessary inputs before it's already sent data off to an attacker. All (or certainly the vast majority) of those APIs are public. The non-public APIs used out of necessity are libcrypto bits related to public key manipulation and are elsewhere.

Please note that I'm only talking about this piece of code:
            CURLcode infocode = curl_easy_getinfo(ctx->m_handle, CURLINFO_TLS_SSL_PTR, &tlsinfo);
            if (infocode == CURLE_OK && tlsinfo && tlsinfo->backend == CURLSSLBACKEND_OPENSSL && tlsinfo->internals) {
                SSL* ssl = reinterpret_cast<SSL*>(tlsinfo->internals);
                const SSL_CIPHER* cipher = SSL_get_current_cipher(ssl);
                log.debug("SSL version: %s, cipher: %s", SSL_get_version(ssl), cipher ? SSL_CIPHER_get_name(cipher) : "unknown");

This is curl_header_hook(). It's not related to any of the that has to do with SSL,
and just uses it to print some debug info.

> > Since libcurl seems to be exposing this functionality, I think you
> > need to use the same version of openssl than libcurl is using.
> > libcurl really shouldn't have been exposing this.
> 
> There is no other interface in any client library that provides even a pretense of serious control over TLS trust handling. It's been part of libcurl for 15 years, or longer.
> 
> I know they prefer people not to use it, but they haven't provided any alternative, so it is what it is.

Yes, so we need something in Debian where both xmltooling and libcurl
are using the same openssl version.

Have you looked at what needs to be done for supporting openssl 1.1.0?
Would it be useful to that I send a patch for it?


Kurt