The OpenSSL library we use in wininet/netconnection.c is a very unstable library, with somewhat odd licensing as well. By unstable I'm talking about the interfaces it exports: unfortunately they break backwards compatibility very frequently with the result that a build of Wine compiled on one system may bail out when using SSL on another, as the soname/abi of OpenSSL it's looking for has changed *yet again*.
This also means that some distros deliberately ship older versions and just backport security fixes, as upgrading OpenSSL to newer versions is quite painful. Fedora at least does this.
If anybody is looking for work to do then, addressing this problem may be useful. Probably the best way forward is to talk to the GnuTLS people (http://www.gnu.org/software/gnutls/gnutls.html) and see if you can get written confirmation from them that they have a strong commitment to binary compatibility (at least, more than OpenSSL does). It also seems to be a fairly stable project: the new maintainer is more focussed on portability enhancements and a slow release cycle than making huge changes to the code.
If so, it might be worth porting wininet over to GnuTLS, or alternatively, rather than remove the OpenSSL code just add code to use GnuTLS and then fall back to OpenSSL if it cannot be found (or vice-versa).
One interesting thing about GnuTLS is that it has some OpenSSL compatibility code, but from a look at their website it seems that this is GPLd. Maybe we could get an exemption from them.
The downside is that while OpenSSL is frequently going to not be found as it's the wrong version, GnuTLS is also not widely installed by default so it might not get us much in the short term.
The good news is that Gaim packages are often built against it, so in any modern distro that packages Gaim (which is a very popular chat client) in its repositories, there's a good chance GnuTLS is packaged as well.
thanks -mike
Hi,
--- Mike Hearn m.hearn@signal.qinetiq.com wrote:
The downside is that while OpenSSL is frequently going to not be found as it's the wrong version, GnuTLS is also not widely installed by default so it might not get us much in the short term.
A better solution is to use the Mozilla Network Security Services (NSS). NSS is everywhere mozilla is and is much more mature.
Thanks Steven
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
A better solution is to use the Mozilla Network Security Services (NSS). NSS is everywhere mozilla is and is much more mature.
Yes, that's another approach. Gaim did this though and then implemented support for GnuTLS as well, because having a chat program depend on a web browser was a bit odd and people were prone to go "Ooh look, a new Mozilla is out! rpm -e mozilla, tar xzvf mozilla-1.7.tar.gz" and such, and then their IM client mysteriously no longer connects to MSN.
I think it's better to depend on an actual library, as opposed to a component of another application. Maybe if Mozilla split it out into a separate project with separate releases, packaging etc, it might be better. Maybe they already have ...
Hi,
--- Mike Hearn m.hearn@signal.QinetiQ.com wrote:
I think it's better to depend on an actual library, as opposed to a component of another application. Maybe if Mozilla split it out into a separate project with separate releases, packaging etc, it might be better. Maybe they already have ...
Well yes its a standalong project but most people only have it if they installed mozilla. I think the best way to do it if we were going to go down the NSS route would be to add a few lines of magic to the wine script and detect the mozilla path at runtime. I think we could do a short version of what the flash rpmscript does to detect the path and keep it as a soft dependancy
http://macromedia.rediris.es/rpmsource/setup
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
Well yes its a standalong project but most people only have it if they installed mozilla. I think the best way to do it if we were going to go down the NSS route would be to add a few lines of magic to the wine script and detect the mozilla path at runtime. I think we could do a short version of what the flash rpmscript does to detect the path and keep it as a soft dependancy
LOCATIONS="/usr/lib/mozilla /usr/lib/mozilla-* /usr/lib/firefox-* /usr/lib/netscape /usr/lib/opera /usr/lib/MozillaFirebird /usr/lib/firefox /usr/local/netscape /usr/local/mozilla /usr/local/MozillaFirebird /usr/local/firefox /opt/mozilla /opt/netscape /opt/MozillaFirebird /opt/firefox"
Eek! That's pretty much the definition of "bad hack" if I ever saw one.
It also doesn't get away from the totally non-intuitive relationship between "I upgraded my web browser and now I can't run <insert favourite SSL using app here>".
But, still, I'm not the one who's going to do the work, so take my opinion with a pinch of salt :)
--- Mike Hearn m.hearn@signal.qinetiq.com wrote:
LOCATIONS="/usr/lib/mozilla /usr/lib/mozilla-* /usr/lib/firefox-* /usr/lib/netscape /usr/lib/opera /usr/lib/MozillaFirebird /usr/lib/firefox /usr/local/netscape /usr/local/mozilla /usr/local/MozillaFirebird /usr/local/firefox /opt/mozilla /opt/netscape /opt/MozillaFirebird /opt/firefox"
Eek! That's pretty much the definition of "bad hack" if I ever saw one.
Yeah. I guess it could be reduced to this but its still a hack.
LOCATIONS="/usr/lib/mozilla /usr/lib/mozilla-* /usr/lib/firefox-* /usr/lib/netscape /usr/lib/firefox /usr/local/netscape /usr/local/mozilla /usr/local/firefox /opt/mozilla /opt/netscape /opt/MozillaFirebird /opt/firefox"
It also doesn't get away from the totally non-intuitive relationship between "I upgraded my web browser and now I can't run <insert favourite SSL using app here>".
Well NSS has been stable for a long time and has a nice regression suite from what I have read. I dont see why updating the browser would break it.
But, still, I'm not the one who's going to do the work, so take my opinion with a pinch of salt :)
Maybe we should just import one of them either gnutls or nss and be done with it. I guess thats Alexandres call.
Thanks Steven
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Steven Edwards wrote:
LOCATIONS="/usr/lib/mozilla /usr/lib/mozilla-* /usr/lib/firefox-* /usr/lib/netscape /usr/lib/firefox /usr/local/netscape /usr/local/mozilla /usr/local/firefox /opt/mozilla /opt/netscape /opt/MozillaFirebird /opt/firefox"
In Gentoo is under /usr/lib/MozillaFirefox, but there's still a copy in /usr/lib installed by dev-libs/libnss. So I think it should be
LOCATIONS="/usr/lib /usr/lib/mozilla /usr/lib/mozilla-* /usr/lib/firefox-* /usr/lib/netscape /usr/lib/firefox /usr/local/netscape /usr/lib/MozillaFirefox /usr/local/mozilla /usr/local/firefox /opt/mozilla /opt/netscape /opt/MozillaFirebird /opt/firefox"
I think that for Gentoo it can avoid the use of /usr/lib/MozillaFirebird (the old directory) because it can depend directly on dev-libs/libnss to be clean.
Well NSS has been stable for a long time and has a nice regression suite from what I have read. I dont see why updating the browser would break it.
I don't mean due to bugs in NSS, I'm sure they've done a great job. I mean because the actual library location itself has moved, or can no longer be found by the linker. Given that the official installer lets you install anywhere, it might well be a problem. I know it's broken Gaim for me before .
Mike Hearn wrote:
I think it's better to depend on an actual library, as opposed to a component of another application. Maybe if Mozilla split it out into a separate project with separate releases, packaging etc, it might be better. Maybe they already have ...
I think they have, also if the site doesn't show them. Gentoo has a dev-libs/nss ebuild to build this without the need of Mozilla and download them from ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/ where there are also many binaries.
On Thu, Sep 02, 2004 at 07:25:52AM -0700, Steven Edwards wrote:
Hi,
--- Mike Hearn m.hearn@signal.qinetiq.com wrote:
The downside is that while OpenSSL is frequently going to not be found as it's the wrong version, GnuTLS is also not widely installed by default so it might not get us much in the short term.
People concerned with getting Wine/SSL running with little space/bandwidth/CPU consumption will rather install another library (GnuTLS) than install mozilla just to get SSL support in wine.
A better solution is to use the Mozilla Network Security Services (NSS). NSS is everywhere mozilla is and is much more mature.
I just thought I'd mention that I don't use Mozilla, as it's performance I find is much too slow on my older system (yet IE over Wine or similar runs perfectly acceptable speeds, somehow) and a space/resource hog. I'd rather manually download GnuTLS libraries and use them with wine than install mozilla, which should be substanscially bigger - maybe 50 mb+? (I'm guessing here.)
A similar example? Manually downloading libao2 specially for use with mplayer. Why? For fine-tuned performance with little space cost.
Of course, including support for as many SSL programs/libraries as possible whilst including fallback coding (note: I'd prefer run-time detection, so we don't have to make stupid dependencies for wine under packaging systems such as debian or fedora/rpms... last thing we need is a new dummy package having wine depend on "wine-ssl-provider" being filled by something such as mozilla, firefox, openssl-<version> or GnuTLS...) would be amazing and useful.
Of course, I'm merely complaining here, but that's my two cents.
Thanks Steven
Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
--Michael Chang
I'd rather manually download GnuTLS libraries and use them with wine than install mozilla, which should be substanscially bigger - maybe 50 mb+? (I'm guessing here.)
Oh no, modern Mozilla based browsers such as Firefox are more like 5mb.
Of course, including support for as many SSL programs/libraries as possible whilst including fallback coding (note: I'd prefer run-time detection, so we don't have to make stupid dependencies for wine
Wine tries to do as much runtime detection as possible, as a general rule (thank goodness, far more enlightened than some projects are ...)
thanks -mike
Le lun 06/09/2004 à 04:29, Mike Hearn a écrit :
I'd rather manually download GnuTLS libraries and use them with wine than install mozilla, which should be substanscially bigger - maybe 50 mb+? (I'm guessing here.)
Oh no, modern Mozilla based browsers such as Firefox are more like 5mb.
The Windows download is 5MB, the Linux one is 8MB. Once installed it uses more than that of course (22MB for the Linux on).
Of course, including support for as many SSL programs/libraries as possible whilst including fallback coding (note: I'd prefer run-time detection, so we don't have to make stupid dependencies for wine
Wine tries to do as much runtime detection as possible, as a general rule (thank goodness, far more enlightened than some projects are ...)
Which doesn't mean that the presence of headers upon compilation is not needed, they're always needed. Merely installing Firefox from mozilla.org won't be enough (because you won't have the development headers). Some distributions do package the development headers, but not all of them do. That's something to keep in mind as well.
Vincent
-
Diego 'Flameeyes' Pettenò -
michael＠cherryblossom.homelinux.com -
Mike Hearn -
Steven Edwards -
Vincent Béron