Re-introduce source-built libcurl with BoringSSL on Linux #1860
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
This reverts commit da1f056.
To avoid issues caused by linking against the system-provided libcurl on Linux, always use a source-built libcurl. As part of this change, add BoringSSL as the SSL backend for libcurl and use it on Linux (and other Unix-like systems except macOS). Linking static libcurl with either static or system OpenSSL is neither secure nor reliable across diverse Linux distributions.
To reduce the size and attack surface of the embedded libcurl used in vcpkg, disable unused protocols and features.
This aims to enhance security and reliability in the build process.
Since we are not using the system OpenSSL, we need to manually configure curl to use the system’s SSL root certificates. This is done by setting the CA file and path based on common locations used by Linux distributions.
BillyONeal
requested changes
Nov 19, 2025
Member
BillyONeal
left a comment
BillyONeal
left a comment
There was a problem hiding this comment.
This does not obey system TLS root certificate policy.
Author
|
I added
This means we rely on the same root store the distro’s TLS stack uses (including their If you have a specific mechanism or location you’d like us to use for “system TLS root certificate policy” on Linux, I will adjust the helper accordingly. |
Member
|
I believe @vicroms was working on using dlopen/dlsym to talk to curl as @ras0219-msft was looking at a stub library instead. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Motivation
Relying on the system
libcurland OpenSSL on Linux is brittle and can lead to subtle breakages across different distributions and versions.By switching to a source-built
libcurlwith BoringSSL on Linux and other Unix-like platforms (excluding macOS), we gain a consistent, controlled, and more secure environment with a reduced attack surface.Changes
cmake/FindBoringSSL.cmaketo fetch, patch, and build BoringSSL using a pinned URL and SHA.cmake/FindOpenSSL.cmaketo map BoringSSL’sssl/cryptotargets toOpenSSL::SSL/OpenSSL::Cryptoon Unix and to populate curl’s feature checks appropriately.cmake/FindLibCURL.cmaketo keepVCPKG_DEPENDENCY_EXTERNAL_LIBCURLdisabled by default on all platforms, making the embeddedlibcurlthe default for official builds.libcurlconfiguration by disabling unused protocols and high-surface features, keeping it focused on HTTP(S) and FTPvcpkgbinaries do not link against systemlibcurl/OpenSSL (libcurl.so,libssl.so,libcrypto.so).libcurl4-openssl-devinstallation from GitHub Actions workflows and Azure Pipelines Dockerfiles now that the build no longer relies on systemlibcurl.