Due to the check in Makefile.vc and MakefileBuild.vc, no make call can
be invoked unless a build-type was specified. However, a clean target
only existed when a build type was specified. As a result, the clean
target was unreachable. Made clean target unconditional.
Closes#2455
Added support for a WITH_CARES option to be used when invoking nmake
via Makefile.vc. This option enables linking against both the DLL and
static versions of the c-ares libraries, as well as the debug and
release varients, depending on the value of DEBUG. The USE_ARES
preprocessor symbol is also defined.
This is just fundamentally broken. SPNEGO (RFC4178) is a protocol which
allows client and server to negotiate the underlying mechanism which will
actually be used to authenticate. This is *often* Kerberos, and can also
be NTLM and other things. And to complicate matters, there are various
different OIDs which can be used to specify the Kerberos mechanism too.
A SPNEGO exchange will identify *which* GSSAPI mechanism is being used,
and will exchange GSSAPI tokens which are appropriate for that mechanism.
But this SPNEGO implementation just strips the incoming SPNEGO packet
and extracts the token, if any. And completely discards the information
about *which* mechanism is being used. Then we *assume* it was Kerberos,
and feed the token into gss_init_sec_context() with the default
mechanism (GSS_S_NO_OID for the mech_type argument).
Furthermore... broken as this code is, it was never even *used* for input
tokens anyway, because higher layers of curl would just bail out if the
server actually said anything *back* to us in the negotiation. We assume
that we send a single token to the server, and it accepts it. If the server
wants to continue the exchange (as is required for NTLM and for SPNEGO
to do anything useful), then curl was broken anyway.
So the only bit which actually did anything was the bit in
Curl_output_negotiate(), which always generates an *initial* SPNEGO
token saying "Hey, I support only the Kerberos mechanism and this is its
token".
You could have done that by manually just prefixing the Kerberos token
with the appropriate bytes, if you weren't going to do any proper SPNEGO
handling. There's no need for the FBOpenSSL library at all.
The sane way to do SPNEGO is just to *ask* the GSSAPI library to do
SPNEGO. That's what the 'mech_type' argument to gss_init_sec_context()
is for. And then it should all Just Work™.
That 'sane way' will be added in a subsequent patch, as will bug fixes
for our failure to handle any exchange other than a single outbound
token to the server which results in immediate success.
Renamed the CURLX_ONES file list definition in order to a) try and be
consistent with other file lists and b) to allow for the addition of
the curlx header files, which will assist with Visual Studio project
files generation rather than hard coding those files.
Since Simple and Protected GSSAPI Negotiation Mechanism
is already implemented in curl and supported by the MinGW
builds, this change adds build support to winbuild makefiles.
Cleaned up order of handled build options by ordering them
nearly alphabetically by using the order of the generated
config name. Preparation for future/more build options.
Since WinSSL cannot be build without SSPI being enabled,
USE_WINSSL now defaults to the value of USE_SSPI.
The makefile does now raise an error if WinSSL is enabled
while SSPI is disabled.
Renamed external parameter USE_SSPI = yes/no to ENABLE_SSPI = yes/no.
Backwards compatible change: USE_SSPI can still be passed as external
parameter with yes/no value as long as ENABLE_SSPI is not given.
USE_x defines are passed around with true/false values internally,
USE_SSPI is now aligned to this approach, but still accepts external
values yes/no being passed, just like the other defines.
- Changed space usage to line up with the whole file
- Renamed CFLAGS_SSPI/IPV6 to SSPI/IPV6_CFLAGS to be
consistent with the other CFLAGS_x variables
- Make use of existing CFLAGS_IPV6 (previously IPV6_CFLAGS)
instead of appending directly to CFLAGS
The changes introduced in commit 2bfa57bc32 are not enough
to make it actually possible to use the USE_WINSSL option.
Makefile.vc was not updated and the configuration name which is
used in the build path did not match between both build files.
This patch fixes those issues and introduces the following changes:
- Replaced the -schannel name with -winssl in order to be consistent
with the other options
- Added ENABLE_WINSSL option to winbuild/Makefile.vc (default yes)
- Changed winbuild/MakefileBuild.vc to set USE_WINSSL to true if
USE_SSL is false and USE_WINSSL was not specified as a parameter
- Separated WINSSL handling from SSPI handling to be consistent with
the other options and their corresponding code path
Removed specific WITH_SSL=schannel paramter that did not fit the general
schema and complicated the parameters. For now Schannel will be enabled
if SSPI is enabled and OpenSSL is disabled.
Fixed USE_IPV6 and USE_IDN not being passed
from Makefile.vc to MakefileBuild.vc
Fixed whitespace and formatting issues
Fixed typo and format in help message
This is a separate makefile for MSVC builds. It is deliberately put in
another dir than src/ and lib/ to allow a different build experience
than the previous - at least during a period. Eventually we should
unify.
