RFC: Adding Mac support to secur32/schannel.c
fgouget at free.fr
Thu Feb 3 05:34:45 CST 2011
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'?
1) Improve Mac support
2) Improve schannel
Drawback is (1) makes (2) much harder but this has not been
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.
Francois Gouget <fgouget at free.fr> http://fgouget.free.fr/
In a world without fences who needs Gates?
More information about the wine-devel