RFC: Adding Mac support to secur32/schannel.c

[Juan Lang]

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