RFC: Adding Mac support to secur32/schannel.c
juan.lang at gmail.com
Fri Jan 28 10:36:56 CST 2011
> 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.
More information about the wine-devel