RFC: Adding Mac support to secur32/schannel.c

Juan Lang juan.lang at gmail.com
Thu Feb 3 09:41:31 CST 2011

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

> 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

More information about the wine-devel mailing list