One of my wild dreams is to create an LSB package for Wine. One of the many roadblocks is OpenSSL. OpenSSL is not standardized, has a very fragile interface, and the openssl devs say they have no time to fix the problem. This leaves an opening for alternative crypto implementations. The way to tell whether an alternative crypto implementation is series is whether they have a good OpenSSL compatibility wrapper. So far I know of two: nss (the ssl used by Firefox) has one, http://fedoraproject.org/wiki/Nss_compat_ossl and gnu tls has one. nss is part of the LSB, but gnu tls is not.
Potentially one could link against nss and its wrapper instead of openssl when building an LSB package of wine.
A few issues to consider: a) wrappers might need to be statically linked to avoid clashes with shared libraries built with the real openssl: http://www.linux-archive.org/fedora-development/148626-libgnutls-openssl-rea... b) gnu tls is gpl... Does wine currently link against any GPL (as opposed to LGPL) libraries?
OK, back to the real world. - Dan
Hi Dan,
One of my wild dreams is to create an LSB package for Wine. One of the many roadblocks is OpenSSL.
The only part of Wine that currently depends on OpenSSL is wininet. That could change if someone decides to copy that part of wininet to winhttp, but it shouldn't spread beyond that. We need to implement schannel at some point, as several apps depend on it, and I doubt Alexandre will accept an implementation that depends on OpenSSL. As long as we're talking about wild dreams, assuming someone ever implements schannel, wininet should be written on top of that, and the problem goes away. --Juan
On Wed, Aug 27, 2008 at 3:02 PM, Juan Lang juan.lang@gmail.com wrote:
We need to implement schannel at some point, as several apps depend on it, and I doubt Alexandre will accept an implementation that depends on OpenSSL.
Out of curiosity, why not? (I tried looking for past discussions, didn't find them.) - Dan
Out of curiosity, why not? (I tried looking for past discussions, didn't find them.)
Perhaps I'm mistaken, so forgive me if I'm speaking out of turn. (The only discussions have been brief, and some were on IRC, so it's not surprising you can't turn them up.)
Basically, the OpenSSL code was put in some time ago. Since some of the distros are moving toward removing it, it doesn't seem like the best place to invest new energy. So leaving the existing code as-is is fine, but adding new code that depends on OpenSSL probably isn't. --Juan
2008/8/28 Juan Lang juan.lang@gmail.com:
Hi Dan,
One of my wild dreams is to create an LSB package for Wine. One of the many roadblocks is OpenSSL.
The only part of Wine that currently depends on OpenSSL is wininet. That could change if someone decides to copy that part of wininet to winhttp, but it shouldn't spread beyond that. We need to implement schannel at some point, as several apps depend on it, and I doubt Alexandre will accept an implementation that depends on OpenSSL. As long as we're talking about wild dreams, assuming someone ever implements schannel, wininet should be written on top of that, and the problem goes away. --Juan
For what it's worth, I've actually got part of a schannel implementation on top of gnutls. (Most of gnutls is LGPL, but eg. the OpenSSL compatibility is GPL)
On Wed, Aug 27, 2008 at 3:28 PM, Henri Verbeet hverbeet@gmail.com wrote:
For what it's worth, I've actually got part of a schannel implementation on top of gnutls. (Most of gnutls is LGPL, but eg. the OpenSSL compatibility is GPL)
Bring it on! (Did you end up using the wrapper? It would be convenient if you didn't.) - Dan
On Wed, Aug 27, 2008 at 6:28 PM, Henri Verbeet hverbeet@gmail.com wrote:
For what it's worth, I've actually got part of a schannel implementation on top of gnutls. (Most of gnutls is LGPL, but eg. the OpenSSL compatibility is GPL)
If you mean OpenSSL is GPL compatible this is wrong. It has a BSD style advertising clause. If you search the wine-devel archives I have brought this issue up before as a GPL/LGPL incompatibility. Technically its still LGPL compatible as you can link LGPL with anything but it invalidates the GPL compatibility section if you build your winelib applications with OpenSSL enabled wininet. This is a minor issue for the ReactOS guys and as such is one we would like to see fixed rather than having to fork so +1 on moving to NSS or GNU TLS.
(Most of gnutls is LGPL, but eg. the OpenSSL compatibility is GPL)
If you mean OpenSSL is GPL compatible this is wrong.
No, I believe he means the portion of gnutls that is OpenSSL compatible is GPL. See http://www.gnu.org/software/gnutls/manual/html_node/Compatibility-with-the-O... --Juan
2008/8/28 Juan Lang juan.lang@gmail.com:
(Most of gnutls is LGPL, but eg. the OpenSSL compatibility is GPL)
If you mean OpenSSL is GPL compatible this is wrong.
No, I believe he means the portion of gnutls that is OpenSSL compatible is GPL. See http://www.gnu.org/software/gnutls/manual/html_node/Compatibility-with-the-O... --Juan
Yes, what I meant to say was that as long as you stick to the core gnutls library, gnutls is LGPL.
On Wednesday 27 August 2008 23:51:02 Dan Kegel wrote:
b) gnu tls is gpl... Does wine currently link against any GPL (as opposed to LGPL) libraries?
We can't link against GPL libraries without making libwine useless. If we could, I'd have Wine link against a good bunch of Samba libraries already.
Cheers, Kai
Hi Dan,
Some clarification...
On Wednesday 27 August 2008 23:51:02 Dan Kegel wrote:
A few issues to consider [...] b) gnu tls is gpl... Does wine currently link against any GPL (as opposed to LGPL) libraries?
I believe the situation is slightly more complex. From memory, the core part of GNU TLS is LGPL (as are the underlying GNU libraries that TLS depends on) but the OpenSSL compatibility layer is GPL.
So, if one uses TLS as a drop-in replacement for OpenSSL, the resulting code is GPLed, but if wine links against the TLS's API then I believe LGPL (instead of GPL) applies.
HTH,
Paul.
-
Dan Kegel -
Henri Verbeet -
Juan Lang -
Kai Blin -
Paul Millar -
Steven Edwards