Integrate OpenSSL in vcpkg of wazuh-engine project

[juliancnn]

Description

Currently, Wazuh-Engine depends on the system-installed OpenSSL library, which can lead to inconsistencies due to varying versions across different environments. To ensure version control and consistency, we need to integrate OpenSSL into the Wazuh-Engine project using vcpkg. This approach will allow us to specify and manage the OpenSSL version explicitly, enhancing build reliability and eliminating the need to install OpenSSL via system package managers during Docker builds.

Objectives

• Version-Controlled OpenSSL Dependency:

  • Add OpenSSL to the vcpkg.json manifest file in the Wazuh-Engine project.

• CMake Configuration:

  • Link OpenSSL in CMake to the modules that utilize it, specifically the geo and fs modules.

• Docker Build Optimization:

  • Remove the dependency on system-installed OpenSSL in Docker builds.
  • Eliminate the installation of OpenSSL via apt or yum when building Docker images for DEB and RPM package creation.

Tasks

1. Add OpenSSL to vcpkg.json:

   • Update the vcpkg.json file in the Wazuh-Engine project to include OpenSSL as a dependency.
   • Specify the required version to maintain consistency across all builds.

2. Modify CMake Configuration:

   • Adjust the CMakeLists.txt files to link OpenSSL from vcpkg to the geo and fs modules.
   • Ensure that the find_package and target_link_libraries commands correctly reference the vcpkg-managed OpenSSL.

3. Update Docker Build Scripts:

   • Remove any apk, yum, or other package manager commands that install OpenSSL in the Dockerfiles used for building DEB and RPM packages.
   • Ensure that Docker builds Wazuh-Engine successfully without relying on system-installed OpenSSL.

4. Testing and Validation:

   • Compile Wazuh-Engine using the updated configuration to verify that OpenSSL is correctly integrated.
   • Run unit tests and integration tests, focusing on the geo and fs modules, to confirm functionality.
   • Test Docker builds for DEB and RPM packages to ensure they complete successfully without installing OpenSSL via system package managers.

Acceptance Criteria

• OpenSSL is included and version-controlled in the vcpkg.json file.
• The geo and fs modules are successfully linked to OpenSSL via CMake using vcpkg.
• Docker build processes no longer install OpenSSL through apt, yum, or other package managers.
• Wazuh-Engine builds and runs correctly without relying on the system-installed OpenSSL library.
• All tests pass without any OpenSSL-related issues.

[JcabreraC]

Expanded ETA.

This task has not been started because of work on other, higher priority issues.

[NahuFigueroa97]

Update

Dependency of libcurl and OpenSSL in the geo module

The geo module initially had a dependency on the libcurl library, which in turn includes OpenSSL. This was verified using the following command:

ar -t build/vcpkg_installed/x64-linux/lib/libcurl.a | grep open

The output showed that libcurl depended on OpenSSL:

fopen.c.o
openldap.c.o
openssl.c.o

This behavior was identified because libcurl typically includes OpenSSL in its build, which can cause the project to end up using an undesired version of OpenSSL if linked directly with libcurl.

Change Made: Replacing libcurl with urlRequest

In order to avoid the unwanted dependency on OpenSSL through libcurl, it was decided to replace libcurl with the urlRequest library. urlRequest is a more controllable alternative that does not include OpenSSL, allowing for more precise control over the OpenSSL dependencies in the project.

Additionally, the OpenSSL library provided by vcpkg was explicitly included to ensure the specific version of OpenSSL desired is used, instead of the version linked with libcurl.

Dependency of liblzma and Libarchive in the filesystem module

On the other hand, the filesystem module has important dependencies that need to be highlighted:

• liblzma: This library is part of XZ Utils and is used for compressing and decompressing files in .xz format, a high-performance compression format. Its inclusion in the project ensures that files compressed in this format can be handled efficiently.

• Libarchive: Libarchive is a library that provides an API to read and write various file formats such as tar, cpio, zip, among others. This library was linked to the project, but it was detected that it also has an implicit dependency on OpenSSL.

Running the following command to inspect the dependencies in libarchive:

nm build/vcpkg_installed/x64-linux/lib/libarchive.a | grep -i ssl

It was observed that libarchive uses OpenSSL, specifically in the following reference:

U OPENSSL_cleanse

This confirms that libarchive depends on OpenSSL.

Next Steps: Investigating libarchive Configuration to Use Custom OpenSSL

Since libarchive depends on OpenSSL and we are using vcpkg to manage our dependencies, it is necessary to investigate whether it is possible to configure libarchive to use the version of OpenSSL provided by vcpkg instead of the default version linked in the libarchive package.

It is important to check if libarchive’s build can be adjusted to disable its internal version of OpenSSL and instead use the version of OpenSSL installed by vcpkg. This would ensure that the project uses a consistent and controlled version of OpenSSL, avoiding potential conflicts or security issues.

Conclusion

• The geo module was found to indirectly depend on OpenSSL through libcurl, which was resolved by replacing libcurl with urlRequest and explicitly including the version of OpenSSL provided by vcpkg.
• The filesystem module has dependencies on liblzma (part of XZ Utils) and Libarchive, with the latter also depending on OpenSSL.
• It is necessary to investigate how to configure libarchive to use the version of OpenSSL provided by vcpkg, avoiding the OpenSSL version linked in the libarchive package.

[NahuFigueroa97]

Update

In vcpkg, transient dependencies are by design marked as public, meaning they are automatically exposed to packages that depend on them. While this approach simplifies dependency resolution, it can lead to problems related to environment pollution, high build times, and lack of control over which dependencies should be visible to other packages.

• Workspace Pollution:
  Public dependencies can lead to name or version conflicts if multiple libraries require different versions of the same dependency.

• Increased Build Overhead:
  Downloading, compiling, and linking all transient dependencies increases the time required to prepare the environment.

• Limited Control over Dependencies:
  There is no native mechanism in vcpkg to easily mark dependencies as private, which limits the ability to manage their visibility.

An effective solution to control the propagation of transient dependencies is through port overrides in vcpkg. This method allows you to redefine unwanted dependencies to do nothing, preventing them from being downloaded or propagated to the global environment. microsoft/vcpkg#24558 (comment)

[NahuFigueroa97]

Update

Issue blocked by microsoft/vcpkg#43251

[NahuFigueroa97]

Update

All headers for libraries installed with vcpkg are placed in the <vcpkg_installed>/include directory.
Some libraries organize their headers within specific subdirectories, such as include/subdir, and export that subdirectory as part of their include directory in the interface configuration.
Using a subdirectory (e.g. include/mylib) can provide isolation between libraries, meaning that the headers of one library do not accidentally interfere with those of another.
Many libraries do not use a subdirectory to isolate their headers, but instead place their files directly in the root include directory.
If a library like fmt adds its headers directory to your CMake project, the headers of other libraries in the same directory (e.g. openssl) become accessible as well. This happens because they share the same space in the include directory.