Introduce Schannel and SSPI for Windows #6533
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Provide a stream interface for Schannel - the native crypto APIs - on Windows. This allows Windows to use the same HTTP transport that all the other platforms use, with its own native crypto. Ultimately this allows us to deprecate WinHTTP and we need not add support for our socket changes in two places (our HTTP stack and the WinHTTP stack).
Name the GSSAPI and ntlmclient authentication providers as such. Today
they're named after the authentication mechanism ("Negotiate", "NTLM")
instead of their implementation.
If we have competing implementations for the same mechanism (eg, a
future Windows SSPI-based provider for Negotiate and NTLM) then this
will get confusing.
Add functions to use convert a string with length, instead of assuming NUL termination. In addition, move the utf8 to 16 conversion routines into the `git_utf8` namespace instead of using namespaceless `git__` prefixed names.
Add support for SSPI on Windows, which offers NTLM and Negotiate authentication.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Today, Windows uses WinHTTP by default. Our other platforms use our own HTTP client stack that handles various types of TLS providers (OpenSSL, mbedTLS, stransport, etc), and various types of authentication (basic, NTLM via ntlmclient, Negotiate via GSSAPI).
Having two high-level HTTP client implementations means that we need to add support for things like cookie handling in both places, which is disappointing and awkward. There's also a possibility of having bugs in one but not the other. And although (admittedly) it has only happened that our HTTP client has been the buggy one, we can't standardize on WinHTTP. And, blessedly, getting rid of WinHTTP means that we can stop converting things from ASCII to UTF16 so that WinHTTP can convert it back to ASCII. 😢
Add an Schannel stream, which provides a TLS implementation on Windows. This allows us to use our own HTTP client stack on Windows with native TLS support.
Additionally, add an SSPI authentication provider, which provides NTLM and Negotiate authentication on Windows.
Today, this neither removes WinHTTP support, nor does it change the default on Windows.