Unable to compile curl with LDAPS

[LouisClt]

Host Environment:
Windows 10 ver 1909, compiler : VS 2019

I tried to compiled Curl with vcpkg , and was unable to get the protocol LDAPS to be enabled in curl (I tried many options). The configuration seems to enable LDAP but not LDAPS.

Steps to reproduce :
Compile curl with tool (and openssl but this does not seem to matter)(in x64 Native commands tools):
vcpkg install curl[tool,openssl] --triplet x64-windows

Then goes to package packages\curl_x64-windows\tools\curl and do:
curl ldaps://localhost
curl ldap://localhost
Result :
curl: (1) Protocol "ldaps" not supported or disabled in libcurl
curl: (7) Failed to connect to localhost port 389: Connection refused

I expect the first message to be somewhat the same as the second (here LDAPS is not activated).

When I compile LibCurl with nmake (going in the winbuild directory and doing something like :
"nmake /f Makefile.vc mode=dll WITH_SSL=dll SSL_PATH=[YOUR_SSL_PATH] VC=16 MACHINE=x64 GEN_PDB=yes ENABLE_UNICODE=yes") I am able to get the LDAPS support.

At this point I am not sure if this is vcpkg related or just a bad makefile from LibCurl, but as nmake in winbuild works I guess that this may be related to vcpkg.

config-x64-windows-out.log parts that can be relevant :
-- Looking for cldap_open in wldap32;winmm;ws2_32;advapi32;crypt32;OpenSSL::SSL;OpenSSL::Crypto
-- Looking for cldap_open in wldap32;winmm;ws2_32;advapi32;crypt32;OpenSSL::SSL;OpenSSL::Crypto - found
-- Looking for include file winldap.h
-- Looking for include file winldap.h - not found
-- Looking for include file winber.h
-- Looking for include file winber.h - not found
-- Looking for include file ldap_ssl.h
-- Looking for include file ldap_ssl.h - not found
-- Looking for include file ldapssl.h
-- Looking for include file ldapssl.h - not found
[...]
-- Enabled protocols: DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP POP3 POP3S RTSP SMB SMBS SMTP SMTPS TELNET TFTP
(no LDAPS here, it indicates it does not find winldap but I think it findsit because LDAP is activated at the end)

[LouisClt]

Hi, thank you for your answer.
I had already tested it on another computer, but I tested it again on another clean environment : installed last version of visual studio 2019, and last version of Windows 10 Kit (because maybe I thought it was needed for the installation). I did again the vcpkg installation of curl and got a similar result (but this time even ldap was not recognised at the end!).
So I must say I am surprised that you succeeded in running it. Is there something peculiar to your environment that might explain that result (for instance a package on visual studio that I have not installed?).
Maybe indeed I did something wrong, must admit I am not an expert.

[JackBoosY]

Hi @LouisClt Does this issue still exist?

[LouisClt]

Sorry for my late reply.
I am still able to reproduce this problem on my environment.
curl -V
curl 7.73.0-DEV (Windows) libcurl/7.73.0-DEV Schannel zlib/1.2.11
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps ldap mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI TrackMemory libz

As sfhacker pointed out, it may just be my environment which is not well set.
I managed to bypass the problem by compiling with nmake as previously stated.

[JackBoosY]

Because non-http is a default feature...
Please use this command ./vcpkg install curl[core,tool,openssl].

[LouisClt]

Thank you for your answer.
I tested your command. It only compiles http/https. I guess this is normal as non-http is an inverted-feature ?
It activates HTTP-ONLY when it is not put.
In the control file :
Feature: non-http
Description: Enables protocols beyond HTTP/HTTPS/HTTP2

[JackBoosY]

@LouisClt Seems the description is wrong.
In SOURCE/CMakeLists.txt:

option(HTTP_ONLY "disables all protocols except HTTP (This overrides all CURL_DISABLE_* options)" OFF)

The wrong description caused you to use the wrong feature.

[LouisClt]

Thanks for your answer. Excuse me if I'm wrong but as I understand it :
In the libcurl portfile :

vcpkg_check_features(OUT_FEATURE_OPTIONS FEATURE_OPTIONS
    FEATURES
    # Support HTTP2 TLS Download https://curl.haxx.se/ca/cacert.pem rename to curl-ca-bundle.crt, copy it to libcurl.dll location.
    http2       USE_NGHTTP2
   [...]
    INVERTED_FEATURES
    non-http HTTP_ONLY
)

As we can see non-htp is an inverted feature bound to HTTP_ONLY.
According to the vcpkg doc (https://github.com/microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_check_features.md ):

INVERTED_FEATURES:
A list of (FEATURE_NAME, OPTION_NAME) pairs, uses reversed logic from FEATURES.
For each FEATURE_NAME a definition is added to OUT_FEATURE_OPTIONS in the form of:

-D<OPTION_NAME>=OFF, if a feature is specified for installation,
-D<OPTION_NAME>=ON, otherwise.

So, according to me, if non-http is specified, the flag -DHTTP_ONLY=OFF will be put, else -DHTTP_ONLY=ON.
But I agree with you than HTTP_ONLY disables everything except HTTP. To disables HTTP_ONLY, I think we need to pass non-http as a vcpkg target.

[JackBoosY]

@LouisClt Yes, the description should be enable all protocols except HTTP.

[JackBoosY]

Although LDAPS is displayed in the configuration log:

-- Enabled protocols: DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS MQTT POP3 POP3S RTSP SMB SMBS SMTP SMTPS TELNET TFTP

the tool still does not show that it has this feature:

curl 7.73.0-DEV (Windows) libcurl/7.73.0-DEV Schannel zlib/1.2.11
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps ldap mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI TrackMemory libz

Will digger in the future.

[JackBoosY]

https://github.com/curl/curl/blob/1835cb916e0d40eb8bc1165d5627a0b64f911bac/CMakeLists.txt#L1398-L1400

There is no judgment USE_WIN32_LDAP, should be a upstream issue.

[LouisClt]

Nothing different from the last time : I am still able to reproduce the issue, and have no trouble using nmake.
I tried different things but nothing seemed to work. The CMakeLists.txt from libcurl does not seem to support windows very well...

[LouisClt]

I managed to compile libcurl with the nmake command (in the winbuild directory of libcurl) with ldaps fully functionnal, and that was all I needed (but I think there are some advantages from using vcpkg (more options than with nmake, easier to compile)). So it is not a blocking point as far as I am concerned (sorry if I misunderstood you question), and I am not really waiting.

[LouisClt]

As far as I am concerned, the issue is not resolved. Fixing the problem of the USE_WIN32_LDAP statement seems to help a bit since now it puts ldaps in the config output, but at the end there is still no ldaps.
The issue seems to be at least partly a libcurl issue, as @JackBoosY stated previously, but I can't say for sure that is only a libcurl issue (even if it seems probable).
As for closing this bug, as this issue is not fully fixed it is hard to say, but indeed if this bug is more LibCurl related and somewhat easily circumvented by using Nmake, then closing this bug would not be absurd.

Thanks

[LouisClt]

No it isn't correct : the binary built using nmake does have ldaps support.
However, it is built using the Makefile.vc from the winbuild folder, which I think is a separate build process from using directly the CMakeLists.txt from the src folder (but maybe not ?!).
So the build process using CMakeLists.txt (which I think is what is done by vcpkg) can be not fully functionnal and in the same time the build process using nmake can work well, according to me.

[JackBoosY]

@LouisClt I've report this to the upstream(curl/curl#6284), let's wait for the official reply.

[JackBoosY]

Since this issue was marked as a known bug, I think we should disable this until the official fix it.

[dg0yt]

Since this issue was marked as a known bug, I think we should disable this until the official fix it.

I don't think the current state of open and "category:port-bug" and not "depends:upstream-changes" properly reflects the state: It is not a bug in the port itself, and it does depend on upstream changes (or patching).

Anyway, in #18971 I moved WinLDAP support to a separate, non-default feature now, and documented the missing LDAPS support in the description.

[JackBoosY]

@dg0yt I think we should simply remove this feature until the upstream fix it.

[dg0yt]

@dg0yt I think we should simply remove this feature until the upstream fix it.

With #18971, LDAP is removed from the default features. I think this is good enough: opt-in when desired, and see the limitations in the feature's description.

PS: If it is entirely removed, there may be new feature requests or pull requests, and we will have to explain again why it isn't there.