I'd like to know whether it would be possible to add the -openssl-linked
./configure option for building Qt.

https://doc.qt.io/qt-4.8/ssl.html

I have a rather complicated problem concerning mumble (#804363) which
concerns Mumble breaking during OpenSSL transitions that have library
renames.  With the patch I'm currently using to mitigated the bug, due to Qt
using dlopen() to load libssl/libcrypto during these transitions two copies
of libssl/libcrypto with ABI differences between them both get loaded and we
believe both get initialized, so figuring out what will happen is
nontrivial.  The Debian OpenSSL maintainer says that this shold work but
that OpenSSL upstream is not likely to guarantee that it will.  Mumble
upstream wants to implement a patch which would cause Mumble to quit with an
error if it finds two copies of libssl/libcrypto loaded to ban this
possibility.  (https://github.com/mumble-voip/mumble/pull/2124)

Mumble has broken in a similar way before, and at the time it was thought
that linking Qt with libssl/libcrytpo would have licensing issues:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623596#94

We've tried to find other possible mitigation methods and during this the
release team said they aren't sure that having Qt linked with OpenSSL would
cause further licensing issues:

https://lists.debian.org/debian-release/2016/03/msg00409.html

Mumble upstream and the OpenSSL maintainer think that if Qt used the
-openssl-linked option it may handle the problem in (#804363) better:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804487#102


So... I'm writing this bug to get input from the Qt maintainers as to
whether using the -openssl-linked ./configure option when building Qt is
possible (and whether it would help).

Thanks much.
  -- Chris

First of all sorry for the formatting, I'm on the phone right now.

Second: thanks for digging this issue that much! I have now a quite clear
(although I might need to re read something) idea of the issue.

Let's start with the configure option: the problem it's not a technical
one. If we forget about possible licensing problems then using the
necessary switch is just one upload away.

Now I can't decide whether it's safe or not to use this option
license-wide. As I understand this the RT is not the authoritative source
for this, but the FTP team.

Even if I'm wrong wrt team's  responsabilities, I'm still uncertain wrt the
licensing issue. As far as I understand nothing has changed license-wide,
so Modestas' reply is still valid.

Sadly I can't also think of a way of marking qt to be rebuilt with some
libssl upload without linking to it...

I'm afraid the only suitable fix would be to fix ssl's licensing terms.

On Monday 21 March 2016 21:47:50 Lisandro Damián Nicanor Pérez Meyer wrote:
[snip]

Actually there is a **very** **hackish** way to let qt4/qtbase be rebuilt with
the necessary libssl versions. It would be possible to code a very simple app
that links against it with the proper licensing terms and ship it in it's own
binary package. This app would be built from qt4/qtbase's src. Yes, that means
a useless binary package in the archive...

Actually the binary built can be installed in a private path alongside
qtnetwork (in it's package) and might even be a private lib without
headers. That should be enough to keep stuff in sync.

By the way, how is mumble's porting to qt5 going?

Lisandro Damián Nicanor Pérez Meyer:

The mail seems to contain both HTML and TEXT, so no worries AFAIC.

I've been working on this problem since early November.  ;-)  It's been both
a frustrating and fascinating bug to work on, and I've learned a bit in the
process.  Thankfully I've also had a good bit of help -- there's no way I
would have figured this out on my own.

Yes another DD I commonly work with told me that [debian-legal] is just a
discussion list and that the FTP masters have final say concerning both
legal and licensing issues [concerning package uploads].  That seems like a
lot of responsibility.

This is another interesting twist -- Kurt reported OpenSSL upstream is
looking to change the license (to the Apache2 license, sounds like) but
hasn't happened yet:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804487#112

and if you see the message that follows it says that there are still likely
some GPLv2 licensing incompatibilities to consider.



Lisandro Damián Nicanor Pérez Meyer:

Ooof.  A sort of "fake" package for metadata purposes.  Yeah I see it; thank
you for mentioning the idea.  If it comes to that naturally I'd want to
mention the bug reports in either a README file in the "fake" package and/or
the description in the debian/control file to make it clear why the package
exists.

This would shorten the length of time of the transition and so would either
shorten the time of Mumble breakage or the time where Mumble would double
load libssl/libcrypto versions, and leaves the dilemma of which of these to do.


Lisandro Damián Nicanor Pérez Meyer:

I'm not sure I fully understand this, but it vaguely sounds good.

That part is already ready.  Mumble 1.3.x (which doesn't yet have a release)
already builds with Qt5 fine and I've got the Debian packaging ready for
when there's a release to ship.  Mumble 1.3.x can be built with Qt4 or Qt5,
Mumble 1.4.x will be Qt5 only.

On Tuesday 22 March 2016 03:48:48 Chris Knadle wrote:
[snip]

Well, we should keep an eye on that for sure.

Actually as far as I understand it this will make src:qt4-x11 and src:qtbase
to be involved in the next libssl transition, thus the breakage should be just
a normal one.
alongside libqt4-network/libqt5network5. This will make dh_shlibdeps add the
current version of libssl as a dependency of the package so we can warrant two
things: the src package will get rebuilt with any libssl transition and an
appropriate version of libssl will be a hard dependency of each qtnetwork
package.

We just need to use the proper licensing for that dummy app :)

That being said I'm not having much time on my hands to code and integrate the
app, although I would definitely do it if I happen to have it.

Excellent! Let's hope that happens in time for Stretch.

Lisandro Damián Nicanor Pérez Meyer:
[...]

If you have an idea of what you'd like the result to look like, that would
at least give me an idea I might be able to work with.  [I might be able to
make time to try to build something if I know what it needs to be.]

It should.  There's a somewhat pressing need for Mumble 1.3.x because Qt5 is
needed in order to support Perfect Forward Secrecy.  AFAIK the earliest
Stretch freeze is November 5th and there have been a number of 1.3.x
snapshots, so it seems like a release is close.

On Friday 25 March 2016 06:04:55 Chris Knadle wrote:
[snip]

It can either be an app or a private lib (without public headers) that uses
libssl's functions. It can be as simple as a main with one or two calls to
libssl's functions.

It should be safe to be run in case it's an app and even if we put it on a
path not in $PATH.

-- 
Greeting,

I have access to very vital information that can be used to
move huge amounts of money.

If it was possible for me to do it alone I would not
have bothered contacting you. Ultimately I need you to play an
important role in the completion of this business transaction.

Regards,
Mr Alexander Bulyanda