Bug#828608: xmltooling: FTBFS with openssl 1.1.0

Cantor, Scott cantor.2 at osu.edu
Wed Nov 9 21:26:00 UTC 2016


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.

> 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.

>Curl should be doing this by default, and actually has a setting for this ...

Implementing SAML properly has requirements that are not met by anything libcurl is capable of doing on its own.
 
> Is there a reason it implements it's own certificate verification
> rather than using curl's? I guess curl didn't do this always.

This probably is not the place to provide a primer on trust management in federation systems.

> It at least looks to me you could just remove all code that is
> related to libssl and let curl do it for you.

That would be incorrect, but Ferenc understands that.

-- Scott




More information about the Pkg-shibboleth-devel mailing list