Bug#623596: [Pkg-openssl-devel] Processed: Re: Bug#623596: mumble: Problem with the import certificats
Hello, On antradienis 26 Balandis 2011 20:47:45 Thorvald Natvig wrote: That being said, Qt also supports explicit compile-time linking to libssl and libcrypto, which avoids issues like this one and also ensures that libqt4-network shows up as a reverse dependency for openssl. If nothing else, the runtime libraries for OpenSSL should be added as a recommends: for the libqt4-network package. But in todays crypto-heavy world, I can't really think of a good reason not to just link it. Among other things, Qt's web widgets (and URL classes) will not support https without libssl/libcrypto. OpenSSL license is THE reason. Or pure-GPL apps won't be able to link against libQtNetwork which is unacceptable. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#623596: [Pkg-openssl-devel] Processed: Re: Bug#623596: mumble: Problem with the import certificats
On Wed, May 04, 2011 at 01:15:18PM +0300, Modestas Vainius wrote: Hello, On antradienis 26 Balandis 2011 20:47:45 Thorvald Natvig wrote: That being said, Qt also supports explicit compile-time linking to libssl and libcrypto, which avoids issues like this one and also ensures that libqt4-network shows up as a reverse dependency for openssl. If nothing else, the runtime libraries for OpenSSL should be added as a recommends: for the libqt4-network package. But in todays crypto-heavy world, I can't really think of a good reason not to just link it. Among other things, Qt's web widgets (and URL classes) will not support https without libssl/libcrypto. OpenSSL license is THE reason. Or pure-GPL apps won't be able to link against libQtNetwork which is unacceptable. I think dynamicly loading instead of linking doesn't change this license problem. Kurt -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504162353.ga20...@roeckx.be
Bug#623596: [Pkg-openssl-devel] Processed: Re: Bug#623596: mumble: Problem with the import certificats
Hello, On trečiadienis 04 Gegužė 2011 19:23:53 Kurt Roeckx wrote: On Wed, May 04, 2011 at 01:15:18PM +0300, Modestas Vainius wrote: Hello, On antradienis 26 Balandis 2011 20:47:45 Thorvald Natvig wrote: That being said, Qt also supports explicit compile-time linking to libssl and libcrypto, which avoids issues like this one and also ensures that libqt4-network shows up as a reverse dependency for openssl. If nothing else, the runtime libraries for OpenSSL should be added as a recommends: for the libqt4-network package. But in todays crypto-heavy world, I can't really think of a good reason not to just link it. Among other things, Qt's web widgets (and URL classes) will not support https without libssl/libcrypto. OpenSSL license is THE reason. Or pure-GPL apps won't be able to link against libQtNetwork which is unacceptable. I think dynamicly loading instead of linking doesn't change this license problem. Well, at least openssl is not always loaded, but on demand. GPL app may not ever use SSL and so openssl won't ever be in the same process space. While there are multiple views on this kind of issues, you should agree that explicit linking is worse. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#623596: [Pkg-openssl-devel] Processed: Re: Bug#623596: mumble: Problem with the import certificats
I dug a bit deeper into the what happens during the building and loading of the libssl.so* and libcrypto.so*. When the qt4-x11 source package is buildd libssl-dev is installed as a dependency. It is not a direct dependency of qt4-x11, but due to another dev that is installed. At the time the packages of qt4-x11 were build for wheezy. libssl-dev was still depending to libssl0.9.8 and not libssl1.0.0, as it is at the moment. So for libqt4-network the fall-backs are not used, when lib[ssl|crypto].so.0.9.8 are present on the system. On my system the sequence of picking the libraries are with libssl-dev(1.0.0d-2) installed: first attempt: (using SHLIB_VERSION_NUMBER) - library for ssl : libssl.so.1.0.0 - library for crypto : libcrypto.so.1.0.0 second attempt: (using development files) - library for ssl : libssl.so - library for crypto : libcrypto.so third attempt: (scanning the most common library paths) - library for ssl : /usr/lib/libssl.so.1.0.0 - library for crypto : /usr/lib/libcrypto.so.1.0.0 - library for ssl : /usr/lib/libssl.so.0.9.8 - library for crypto : /usr/lib/libcrypto.so.0.9.8 - library for ssl : /usr/lib/libssl.so - library for crypto : /usr/lib/libcrypto.so Just ripped the loading code from qsslsocket_openssl_symbols.cpp. And added some qWarnings. So the upcoming 4.7.2-4 will solve this problem as it cause libqt4-network to load libssl.so.1.0.0 and libcrypto.so.1.0.0 on the first attempt. But there is a possibility the upgrade will also break other programs. Mark-Willem -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/snt119-w27af85c7b954c40dd6fb13cc...@phx.gbl
