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
