Hi,
I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library.
I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going.
I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate.
I'd appreciate a review of this general plan.
Thanks, Ken
Hi Ken,
I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library.
What's the issue with building GnuTLS? Is it that GnuTLS doesn't support the Mac Keychain? Is it that it's an external dependency? If the latter, we already pull in quite a bit that isn't found on the Mac, so the incremental change isn't large.
I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going.
One minor nit: s/adaptor/adapter/
I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate.
I'd appreciate a review of this general plan.
I do see two problems with the general plan. One isn't specific to your plan: schannel as it is is buggy. We don't know where the bugs are, and they've languished for a long time. Your proposed plan doesn't help. The second is the additional bug triaging complexity.
I'd much prefer to see a decent set of test cases for schannel. I suppose one could argue that that's orthogonal to this plan, but see my second complaint: without test cases, an additional implementation just makes debugging schannel bugs harder.
Thanks, --Juan
On 1/28/11 9:36 AM, Juan Lang wrote:
Hi Ken,
I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library.
What's the issue with building GnuTLS? Is it that GnuTLS doesn't support the Mac Keychain? Is it that it's an external dependency? If the latter, we already pull in quite a bit that isn't found on the Mac, so the incremental change isn't large.
The point is that MacOSX has built-in TLS support out of the box. Why build GNU TLS when using MacOSX when it is not needed???
James McKenzie
On 28 January 2011 17:36, Juan Lang juan.lang@gmail.com wrote:
What's the issue with building GnuTLS? Is it that GnuTLS doesn't support the Mac Keychain? Is it that it's an external dependency? If the latter, we already pull in quite a bit that isn't found on the Mac, so the incremental change isn't large.
Note that I wasn't actually involved in any of this on the CodeWeavers side, but I think for CodeWeavers the consideration would be that we'd prefer to not be in the business of distributing GnuTLS, since it's extra stuff to carry around, and you'd have to keep track of security issues, etc. Although I think it's perfectly reasonable to ask Wine users, regardless of OS, to install GnuTLS if they want Schannel support, I don't think the same thing is necessarily reasonable to ask of CrossOver users.
On the other hand, as a Wine (and Free Software in general) developer I'm not so convinced this would really be beneficial to Wine either.
I do see two problems with the general plan. One isn't specific to your plan: schannel as it is is buggy. We don't know where the bugs are, and they've languished for a long time. Your proposed plan
Sadly some of that is probably my responsibility. The original plan was to implement server support after the client code went in, and then use that for writing tests. It didn't quite turn out that way, mostly due to wined3d taking priority.
On 30 January 2011 20:31, James McKenzie jjmckenzie51@earthlink.net wrote:
The point is that MacOSX has built-in TLS support out of the box. Why build GNU TLS when using MacOSX when it is not needed???
To reduce complexity and maintenance overhead of the Wine schannel code.
Hi Juan,
On Jan 28, 2011, at 10:36 AM, Juan Lang wrote:
I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library.
What's the issue with building GnuTLS? Is it that GnuTLS doesn't support the Mac Keychain? Is it that it's an external dependency?
As Henri said, it's that it's a set of external dependencies (not just one; GnuTLS has its own dependencies) and that they are security-related. To the greatest extent practical, security-related libraries should come from one's distro or OS vendor.
If the latter, we already pull in quite a bit that isn't found on the Mac, so the incremental change isn't large.
Well, I'd prefer to reduce those other external dependencies, too. But that's a fight for another day. ;)
One minor nit: s/adaptor/adapter/
Well, my dictionary shows both as correct, although "adapter" is apparently preferred in American English. Thanks.
I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate.
I'd appreciate a review of this general plan.
I do see two problems with the general plan. One isn't specific to your plan: schannel as it is is buggy. We don't know where the bugs are, and they've languished for a long time. Your proposed plan doesn't help.
Well, it doesn't help make schannel less buggy, but it doesn't aim to. However, it does help Macs without GnuTLS (the default) go from a completely non-functional schannel to a merely buggy schannel.
The second is the additional bug triaging complexity.
I'd much prefer to see a decent set of test cases for schannel. I suppose one could argue that that's orthogonal to this plan, but see my second complaint: without test cases, an additional implementation just makes debugging schannel bugs harder.
Well, if schannel were under active development or were soon to be, then I'd hold off on adding a second implementation. However, that doesn't seem to be the case.
As to making debugging harder, I think the impact is pretty minor. The internal schan_imp_* interface is pretty close to GnuTLS. There's not much of the schannel logic -- the stuff that's potentially buggy -- that ends up behind that interface. It mostly consists of making the GnuTLS call, translating its results to Win32 error codes, and logging errors with gnutls_perror(). Frankly, in several respects, I think that moving some of the GnuTLS-using code into smaller, more narrowly focused functions improved the code quite aside from enabling a second implementation.
Admittedly, as schannel is developed, the internal interface may need to grow. And having a second implementation does increase the inertia for that. But that's different from debugging. And, again, schannel is currently pretty static, so this is a hypothetical concern for an unknown time in the future.
To my mind it seems that, if having a Mac-specific implementation is ever going to be accepted, accepting it now is better than waiting indefinitely until the GnuTLS-based implementation is perfected and then revamping the by-then-even-more-GnuTLS-centric design to accommodate a second implementation.
Thanks for your feedback.
Cheers, Ken
Hi Ken, thanks for the reply.
As Henri said, it's that it's a set of external dependencies (not just one; GnuTLS has its own dependencies) and that they are security-related. To the greatest extent practical, security-related libraries should come from one's distro or OS vendor.
Sure, I can buy that. I'll note that OpenSSL is also available for the Mac, and already loaded by wininet and winhttp. It could be appropriate to move from GnuTLS to OpenSSL for schannel, so we'd only have a single implementation for both Linux and Mac in schannel.
Well, it doesn't help make schannel less buggy, but it doesn't aim to. However, it does help Macs without GnuTLS (the default) go from a completely non-functional schannel to a merely buggy schannel.
I suppose that argument is also why we got the buggy (sorry, Henri) GnuTLS schannel in the first place. But adding GnuTLS to a Mac also achieves the same thing, without adding additional code. I agree it isn't perfect, but I'm not sure the additional code path is worth it, at least until we understand where the bugs are. See below.
Well, if schannel were under active development or were soon to be, then I'd hold off on adding a second implementation. However, that doesn't seem to be the case.
Adding another implementation probably doesn't help. As I see it, we have a lack of expertise in the area, and no one who's willing to maintain the code there. I don't see how this helps with either problem.
As to making debugging harder, I think the impact is pretty minor. The internal schan_imp_* interface is pretty close to GnuTLS. There's not much of the schannel logic -- the stuff that's potentially buggy -- that ends up behind that interface. It mostly consists of making the GnuTLS call, translating its results to Win32 error codes, and logging errors with gnutls_perror(). Frankly, in several respects, I think that moving some of the GnuTLS-using code into smaller, more narrowly focused functions improved the code quite aside from enabling a second implementation.
Well, if the interface to GnuTLS could be improved, I'd be happy to see a patch series that did just that. That would benefit everyone.
Admittedly, as schannel is developed, the internal interface may need to grow. And having a second implementation does increase the inertia for that. But that's different from debugging. And, again, schannel is currently pretty static, so this is a hypothetical concern for an unknown time in the future.
I don't see that it is is hypothetical. There are many secur32/schannel bugs already, and the fact that secur32 isn't changing doesn't help them move forward. Having the code change only complicates things, as I see it.
To my mind it seems that, if having a Mac-specific implementation is ever going to be accepted, accepting it now is better than waiting indefinitely until the GnuTLS-based implementation is perfected and then revamping the by-then-even-more-GnuTLS-centric design to accommodate a second implementation.
That does assume that the GnuTLS implementation is the one that remains. I'm not entirely convinced this will end up being appropriate. It's not clear to me that shimming GnuTLS into SSPI will ever address the strange SecBuffer requirements apps seem to have. It's not that I have clear evidence that this approach is doomed to failure, but my experience looking at schannel-related bugs doesn't give me good feelings about it.
So, what I asked for before, and what I still see as lacking, is a set of schannel tests. I'd love to see some that identified deficiencies in our current implementation. The ideal outcome, for me, isn't that we fix all the open schannel bugs without writing additional tests. Doing so doesn't help anyone else address future problems, or help ensure that moving away from GnuTLS (on the Mac or elsewhere) doesn't introduce new problems.
I'd much rather see a strong enough set of tests that we have some idea of what the problems are. This would help with the expertise and maintenance problems. Expertise, both because whoever writes tests gains some, and because whoever reads them can as well. Maintenance, because tests help prevent regressions, or help prevent a new implementation from being written incorrectly in the first place.
Since Henri was kind enough to accept some responsibility for the schannel implementation being buggy, I'll confess that I've wanted to write a good set of schannel tests for years now. I even began, but never got very far. Sadly, life sometimes interferes.
I hope that helps. --Juan
On Tue, Feb 1, 2011 at 3:08 AM, Juan Lang juan.lang@gmail.com wrote:
Hi Ken, thanks for the reply.
As Henri said, it's that it's a set of external dependencies (not just
one; GnuTLS has its own dependencies) and that they are security-related. To the greatest extent practical, security-related libraries should come from one's distro or OS vendor.
Sure, I can buy that. I'll note that OpenSSL is also available for the Mac, and already loaded by wininet and winhttp. It could be appropriate to move from GnuTLS to OpenSSL for schannel, so we'd only have a single implementation for both Linux and Mac in schannel.
OpenSSL seems like a bad idea. It has poor binary compatibility and problematic FIPS 140 certification, and Fedora is dropping it in favour of NSS: http://fedoraproject.org/wiki/FedoraCryptoConsolidation http://fedoraproject.org/wiki/CryptoConsolidationEval
OpenSSL isn't part of the LSB (while NSS is), so if we ever want to make a Wine LSB package, it might be a good idea to get OpenSSL out of Wine entirely. See also the August 2008 wine-devel thread about this: http://www.winehq.org/pipermail/wine-devel/2008-August/068575.html
Damjan Jovanovic
Hi Damjan,
OpenSSL seems like a bad idea. It has poor binary compatibility and problematic FIPS 140 certification, and Fedora is dropping it in favour of NSS: http://fedoraproject.org/wiki/FedoraCryptoConsolidation http://fedoraproject.org/wiki/CryptoConsolidationEval
Maybe, but OpenSSL is a requirement for wininet and winhttp right now. For Fedora's proposed crypto consolidation, they're also proposing building a compatibility layer for OpenSSL on top of NSS, so it's possible that Wine's uses of OpenSSL could use these, too. But this is essentially hypothetical.
As Henri noted, wininet and winhttp should be layered on top of schannel. This is a requirement to fix a couple of bugs in at least wininet (though I'm less sure about winhttp). It has the added advantage of consolidating an SSL implementation in Wine into one place. Then, if platform-dependent SSL libraries are required, either to support Fedora and other Linux distributions that have divided opinions about SSL implementations, or to use Mac's Secure Transport libraries on that platform, they would only have to be done in one place.
OpenSSL isn't part of the LSB (while NSS is), so if we ever want to make a Wine LSB package, it might be a good idea to get OpenSSL out of Wine entirely. See also the August 2008 wine-devel thread about this: http://www.winehq.org/pipermail/wine-devel/2008-August/068575.html
Since that thread, where I stated that new code based on OpenSSL wasn't likely to get accepted, an OpenSSL dependency was added to winhttp. Apparently I was mistaken.
Thanks, --Juan
Juan Lang juan.lang@gmail.com writes:
Since that thread, where I stated that new code based on OpenSSL wasn't likely to get accepted, an OpenSSL dependency was added to winhttp. Apparently I was mistaken.
It's not really new code, winhttp is just a copy of the wininet code. The plan is still to get rid of OpenSSL.
On 1 February 2011 02:08, Juan Lang juan.lang@gmail.com wrote:
Sure, I can buy that. I'll note that OpenSSL is also available for the Mac, and already loaded by wininet and winhttp. It could be appropriate to move from GnuTLS to OpenSSL for schannel, so we'd only have a single implementation for both Linux and Mac in schannel.
Well, I think that regardless of what schannel ends up using, wininet and winhttp should be implemented on top schannel in the long term, instead of using OpenSSL directly. I don't think GnuTLS is really the problem though, or that the existing schannel code is particularly badly implemented. It seems to me that it's more a case of the schannel / secur32 API being somewhat unclear, even to the applications actually using it. Tests would certainly help there, but what IMO complicates writing them is that only the client part of schannel is currently implemented.
Well, it doesn't help make schannel less buggy, but it doesn't aim to. However, it does help Macs without GnuTLS (the default) go from a completely non-functional schannel to a merely buggy schannel.
I suppose that argument is also why we got the buggy (sorry, Henri) GnuTLS schannel in the first place.
Not really. IMO it's just a case of neglect. For what it's worth, at some point the plan at CodeWeavers was that Hans would do some work on schannel, but I assume msi bugs took priority there.
Well, I think that regardless of what schannel ends up using, wininet and winhttp should be implemented on top schannel in the long term, instead of using OpenSSL directly. I don't think GnuTLS is really the
Well, that's certainly true, as there are features of at least wininet that can't be implemented as long as OpenSSL is using a file descriptor directly. I don't have enough confidence in schannel's current implementation to start that, though.
problem though, or that the existing schannel code is particularly badly implemented. It seems to me that it's more a case of the schannel / secur32 API being somewhat unclear, even to the applications actually using it. Tests would certainly help there, but
Perhaps. Tests would help convince me.
what IMO complicates writing them is that only the client part of schannel is currently implemented.
That might be true for writing tests against Wine's implementation, but there's nothing to stop them from being skipped if a server implementation isn't available. In general, I write tests against Windows first. How is this case different? Furthermore, adding a server implementation to schannel isn't likely to be that complex, as GnuTLS does support server-side connections as well, so if that's what's holding back tests, it shouldn't be.
Not really. IMO it's just a case of neglect.
Agreed that it is neglected. Without tests, I'm nervous to take on ownership of it. There have been a few half-hearted attempts to work in this area, but I haven't seen much contribution from people willing to maintain the code over the long term.
I may be flogging a dead horse here, but I personally am loath to see another implementation creep in, side by side with the existing one, that has no guarantee of working any better. I don't see how this helps CodeWeavers, either, other than reducing installation complexity. If there are bugs in the new implementation, and I expect there will be, you'll still have a large support load. Worse, even if you succeed in fixing bugs for your Mac customers, the rest of us don't benefit, as the current implementation still isn't getting any support. If there are development resources available to work on schannel, why not put them into something that benefits the project as a whole? --Juan
On 1 February 2011 17:19, Juan Lang juan.lang@gmail.com wrote:
what IMO complicates writing them is that only the client part of schannel is currently implemented.
That might be true for writing tests against Wine's implementation, but there's nothing to stop them from being skipped if a server implementation isn't available. In general, I write tests against Windows first. How is this case different? Furthermore, adding a server implementation to schannel isn't likely to be that complex, as GnuTLS does support server-side connections as well, so if that's what's holding back tests, it shouldn't be.
I wrote some tests when doing the initial implementation, but those were standalone, running against a real https server running locally. I suppose I could check if I still have them somewhere and send them to you, but they would be fairly useless for preventing regressions as long as they're not part of the Wine tests, and are actually run.
Not really. IMO it's just a case of neglect.
Agreed that it is neglected. Without tests, I'm nervous to take on ownership of it. There have been a few half-hearted attempts to work in this area, but I haven't seen much contribution from people willing to maintain the code over the long term.
Yeah, but that's hardly specific to schannel.
I may be flogging a dead horse here, but I personally am loath to see another implementation creep in, side by side with the existing one, that has no guarantee of working any better. I don't see how this helps CodeWeavers, either, other than reducing installation complexity. If there are bugs in the new implementation, and I expect there will be, you'll still have a large support load. Worse, even if you succeed in fixing bugs for your Mac customers, the rest of us don't benefit, as the current implementation still isn't getting any support. If there are development resources available to work on schannel, why not put them into something that benefits the project as a whole?
Note that in general I agree with your position, I'm just trying to clarify some of the reasons of why the current situation is the way it is. I think it would be a good thing for CodeWeavers to spend some time on Schannel by adding server support and tests, but it's not my decision to make. If it was something I'd have to do on my own time, I'm simply not going to have the time any time soon though.
On Feb 1, 2011, at 10:19 AM, Juan Lang wrote:
I may be flogging a dead horse here, but I personally am loath to see another implementation creep in, side by side with the existing one, that has no guarantee of working any better.
Well, it won't work any better, just as well as.
I don't see how this helps CodeWeavers, either, other than reducing installation complexity.
Well, Outlook didn't used to be able to connect to Gmail IMAP in our Mac product and now it does.
If there are bugs in the new implementation, and I expect there will be, you'll still have a large support load. Worse, even if you succeed in fixing bugs for your Mac customers, the rest of us don't benefit, as the current implementation still isn't getting any support.
That's not true. First, if there are bugs that affect our products, it will likely affect both our Linux and Mac products, and we'd fix it in both.
But more to the point, as I've said before, the schan_imp_* stuff is a very, very thin wrapper around the platform library (Secure Transport on the Mac and GnuTLS elsewhere). It is quite unlikely that the sorts of bugs you're concerned about -- in the logic of schannel -- would be in the platform-specific code. They'd be in the code that's shared. So, the fixes would be shared, too.
If there are development resources available to work on schannel, why not put them into something that benefits the project as a whole?
Everybody, whether volunteer or commercial, devotes development time to Wine to "scratch their itch", however they define that. For us, it's largely to meet customer needs. This work did that. The work you describe doesn't, particularly. It may, someday. It is quite a bit more likely to now because our Mac product has schannel support, so it will get exercised by many more of our customers, and they'll find the problems with it. (Or, if few real-world applications encounter limitations with schannel as it stands, then schannel is de facto fine as-is.)
Lots of work contributed to Wine doesn't benefit everybody, but only improves things for one particular use case. It's still an improvement to the project as a whole, even if most don't receive the benefit.
Regards, Ken
I don't see how this helps CodeWeavers, either, other than reducing installation complexity.
Well, Outlook didn't used to be able to connect to Gmail IMAP in our Mac product and now it does.
As I said, this only reduces installation complexity: I assume that, had you installed GnuTLS, it would have as well. If not, then there's a bug in the GnuTLS implementation.
Everybody, whether volunteer or commercial, devotes development time to Wine to "scratch their itch", however they define that. For us, it's largely to meet customer needs. This work did that. The work you describe doesn't, particularly. It may, someday. It is quite a bit more likely to now because our Mac product has schannel support, so it will get exercised by many more of our customers, and they'll find the problems with it. (Or, if few real-world applications encounter limitations with schannel as it stands, then schannel is de facto fine as-is.)
That's fine. You asked for feedback on your general approach, and described it as a proof of concept. I gave you feedback on it as such. If you wish to treat it as a fait accompli, then I'm not the one who can give input anyway: only Alexandre is.
In any event, I've said my piece: I don't like this approach, and I think there are better ones. I'll repeat it just so it's in one place: I think tests would be the most valuable improvement to schannel. If a Mac friendlier implementation is desired, I'll note that OpenSSL may work as well on the Mac, with the added advantage that it's also available on Linux(*), and is also already a requirement for wininet and winhttp on all platforms.
(*) Damjan raised an objection to OpenSSL, which I'll address separately.
Regards, --Juan
On Feb 2, 2011, at 11:38 AM, Juan Lang wrote:
That's fine. You asked for feedback on your general approach, and described it as a proof of concept. I gave you feedback on it as such.
I appreciate your feedback. Although, in truth, I was asking more about how to do it (wether to separate the two implementations into separate modules, etc.) rather than whether. :)
I described the patch as a proof of concept to emphasize that it wasn't in the final form, but a snapshot of a particular point in my development as I got it working the first time.
Anyway, thanks. I guess I'll try submitting actual patches and see how far that gets. :)
Cheers, Ken
On Tue, 1 Feb 2011, Juan Lang wrote: [...]
I may be flogging a dead horse here, but I personally am loath to see another implementation creep in, side by side with the existing one, that has no guarantee of working any better.
As far as I understand it's not going to be another implementation. But you're probably right to warn about having multiple backends; that can be bad too as has been seen with sound.
Worse, even if you succeed in fixing bugs for your Mac customers, the rest of us don't benefit, as the current implementation still isn't getting any support.
Not true. Anyone using Wine on Mac OS X will benefit by not having to hunt down for a non-standard library to either compile or run Wine. That means Mac users will be more likely to actually have a somewhat functional schannel. Even those who use a packaged Wine will benefit because it means they will no longer either receive an outdated GnuTLS library that contains vulnerabilities with their Wine, or have to hunt one down on their own, or have no schannel support.
You say that schannel needs a lot of improvement and you say that we/the community should work on that first. However making schannel perfect will not make the dependency on GnuTLS any more acceptable on Mac OS X. So both need to be done it's only a matter of 'in which order'?
Option 1 1) Improve Mac support 2) Improve schannel Drawback is (1) makes (2) much harder but this has not been conclusively proven.
Option 2 1) Improve schannel until it's 'good enough' 2) Improve Mac support This means _most_ Mac users won't get any schannel support for a long time. And in terms of development it means a big refactoring phase near the end which may well be pretty disruptive too (hopefully it wouldn't be as bad as the display backend or DIB engine refactoring).
Not that I care about schannel anyway.
Hi Francois,
As far as I understand it's not going to be another implementation. But you're probably right to warn about having multiple backends; that can be bad too as has been seen with sound.
Yes, that's part of my concern.
Not true. Anyone using Wine on Mac OS X will benefit by not having to hunt down for a non-standard library to either compile or run Wine. That means Mac users will be more likely to actually have a somewhat functional schannel. Even those who use a packaged Wine will benefit because it means they will no longer either receive an outdated GnuTLS library that contains vulnerabilities with their Wine, or have to hunt one down on their own, or have no schannel support.
Perhaps. I'm not aware of too many apps that actually work with the built-in schannel. You tell me Outlook is one: that's news, although I suspect that primarily affects CodeWeavers' customers. It doesn't work for everyone, either: see bug 20562. Many apps depend on schannel, yet don't work. Google Talk, VMware Infrastructure Client, and Miranda off the top of my head, probably a few that I'm forgetting.
You say that schannel needs a lot of improvement and you say that we/the community should work on that first. However making schannel perfect will not make the dependency on GnuTLS any more acceptable on Mac OS X. So both need to be done it's only a matter of 'in which order'?
Option 1 1) Improve Mac support 2) Improve schannel Drawback is (1) makes (2) much harder but this has not been conclusively proven.
No. Tests would help determine the cost. As it is, it's only knowable ex post facto, and that means users suffer if it's true.
Option 2 1) Improve schannel until it's 'good enough' 2) Improve Mac support This means _most_ Mac users won't get any schannel support for a long time. And in terms of development it means a big refactoring phase near the end which may well be pretty disruptive too (hopefully it wouldn't be as bad as the display backend or DIB engine refactoring).
Well, that's why tests are important: they mitigate the risk during migration.
Besides, I'm still not convinced that GnuTLS on the Mac is such an onerous problem. If it's an issue for your (CodeWeavers') customers, then your installer needs to be improved. If it's an issue for Wine on Mac users, well, there are already dependencies on non-Mac things, and most users end up using MacPorts or something akin to it to get them. As I see it, your option 2 is a false choice: improving schannel until it's good enough doesn't preclude improving Mac support. --Juan
On Mon, Jan 31, 2011 at 6:08 PM, Juan Lang juan.lang@gmail.com wrote:
As Henri said, it's that it's a set of external dependencies (not just one; GnuTLS has its own dependencies) and that they are security-related. To the greatest extent practical, security-related libraries should come from one's distro or OS vendor.
Sure, I can buy that. I'll note that OpenSSL is also available for the Mac, and already loaded by wininet and winhttp. It could be appropriate to move from GnuTLS to OpenSSL for schannel, so we'd only have a single implementation for both Linux and Mac in schannel.
Just to be clear, legal issues were raised once before with OpenSSL. See here for Geoff Thorpe's reply regarding this issue: http://www.winehq.org/pipermail/wine-devel/2004-July/028061.html
It sounds like things aren't nearly as murky as other licenses, but if we were in the position where we had to ship OpenSSL ourselves we might run into a problem.
-Brian
It sounds like things aren't nearly as murky as other licenses, but if we were in the position where we had to ship OpenSSL ourselves we might run into a problem.
We don't, we load it dynamically. --Juan
-
Alexandre Julliard -
Brian Vincent -
Damjan Jovanovic -
Francois Gouget -
Henri Verbeet -
James McKenzie -
Juan Lang -
Ken Thomases