[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenSSL 1.1.0



On Mon, Nov 21, 2016 at 11:30:13AM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, Nov 21, 2016, at 11:06, Jan Niehusmann wrote:
> > On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> > > At the end I noticed that Qt will stay at 1.0 (by glancing into the
> > > changelog of the relevant upload) which means that my package also has
> > > to to stay at 1.0 and the whole excitement resulted in just a changed
> > > build-dep.
> > 
> > I'm not so sure about this any more:
> > 
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
> > Golosunov wrote that according to his understanding of dlsym(3), it
> > should be fine to link a program with OpenSSL 1.1 and Qt at the same
> > time, even though Qt links to OpenSSL 1.0.
> > 
> > Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
> > that?
> 
> The linking is fine, I believe even any eventual globals (if any) will
> be correctly handled in Debian nowadays.  What causes extremely nasty
> issues is layering violations causing openssl data structures to leak
> from something linked to one version of the library, to something else
> linked to another version of the library.
> 
>  If, at any point, internal data structures from openssl are exposed, or
>  OpenSSL contextes are passed between two libraries, or a library and an
>  application, *they must all be from the same openssl*.
> 
> This is not something the linker or dlopen/dlsym can enforce.  And you
> need to manually inspect the code to be sure... usually.

I've always had the impression that there are or used to be
probems using using dlopen()/dlsym(). Maybe related to some things
like RTDL_GLOBAL that causes the symbol lookup to go to the wrong
library. Do you know of any problems related to that?

Note that QT is one of those that uses dlopen()/dlsym() when
calling openssl functions (for license reasons).

> So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> says "use SSL", etc), then it should be fine.

It seems to be doing this in qtbase5-private-dev. Not sure if
there are actually any users of it.


Kurt


Reply to: