c-ares and BoringSSL version in xgboost 2.0.3 about xgboost

[trivialfis]

? We don't use any of these. It's a machine learning library that crunches numbers.

[hcho3]

XGBoost 2.0.3 is built with dependencies of gRPC 1.49.1:

xgboost/tests/ci_build/Dockerfile.gpu_build_centos7

Lines 52 to 59 in 82d846b

	# Install gRPC
	RUN git clone -b v1.49.1 https://github.com/grpc/grpc.git \
	--recurse-submodules --depth 1 && \
	pushd grpc && \
	cmake -S . -B build -GNinja -DCMAKE_INSTALL_PREFIX=/opt/grpc -DCMAKE_CXX_VISIBILITY_PRESET=hidden && \
	cmake --build build --target install && \
	popd && \
	rm -rf grpc

[soumen-ghosh]

XGBoost 2.0.3 is built with dependencies of gRPC 1.49.1:

xgboost/tests/ci_build/Dockerfile.gpu_build_centos7

Lines 52 to 59 in 82d846b

	# Install gRPC
	RUN git clone -b v1.49.1 https://github.com/grpc/grpc.git \
	--recurse-submodules --depth 1 && \
	pushd grpc && \
	cmake -S . -B build -GNinja -DCMAKE_INSTALL_PREFIX=/opt/grpc -DCMAKE_CXX_VISIBILITY_PRESET=hidden && \
	cmake --build build --target install && \
	popd && \
	rm -rf grpc

Thank you. I'm able to trace the c-ares version number using https://github.com/grpc/grpc/tree/v1.49.1/third_party
But I'm not able to trace the BoringSSL version using the same page.

[hcho3]

@soumen-ghosh BoringSSL does not use well-defined versioning. gRPC uses a specific commit hash to refer to different versions of BoringSSL. For example: grpc/grpc#36089

[trivialfis]

Oops, forgot the federated plugin dependencies. Thank you for the reminder.

[soumen-ghosh]

Thank you all - this was helpful. I'll internally check with the quality team if they can waive the security issues with these information as the security issues were being raised assuming a very old versions pessimistically.