c-ares and BoringSSL version in xgboost 2.0.3

[soumen-ghosh]

We are using xgboost 2.0.3 version. Blackduck scan is not able to figure out the version of c-ares and BoringSSL dependencies and as a result it’s pessimistically raising critical security issues.

How can one find out which version of these dependencies are used in xgboost 2.0.3 or any other version so that we can update the Blackduck scan reports?

Below code does not give any clue -

        import xgboost as xgb
        print(xgb.get_config())
        {‘use_rmm’: False, ‘verbosity’: 1}

I filed below post in the community but since I have not got any response, filing as an issue to resolve the BlackDuck issues.

[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: https://github.com/dmlc/xgboost/blob/82d846bbeb83c652a0b1dff0e3519e67569c4a3d/tests/ci_build/Dockerfile.gpu_build_centos7#L52-L59

[soumen-ghosh]

XGBoost 2.0.3 is built with dependencies of gRPC 1.49.1:

https://github.com/dmlc/xgboost/blob/82d846bbeb83c652a0b1dff0e3519e67569c4a3d/tests/ci_build/Dockerfile.gpu_build_centos7#L52-L59

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: https://github.com/grpc/grpc/pull/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.

[hcho3]

@soumen-ghosh You may consider building XGBoost from the source to exclude c-ares and BoringSSL dependencies. See https://xgboost.readthedocs.io/en/stable/build.html for instructions.

[soumen-ghosh]

@soumen-ghosh You may consider building XGBoost from the source to exclude c-ares and BoringSSL dependencies. See https://xgboost.readthedocs.io/en/stable/build.html for instructions.

Hi @hcho3 - I could not follow what --config-settings I need to use to skip c-ares and BoringSSL dependecies; could you point out to more elaborate instructions that I can follow to skip these related fedarated plugin dependencies?

[hcho3]

No need to specify anything. Federated plugin will be disabled by default.

[soumen-ghosh]

No need to specify anything. Federated plugin will be disabled by default.

Thank you. The default C++ compiler in our path is of version 9.2.0. However, even if we add the corresponding path to libstdc++.so.6 LD_LIBRARY_PATH, we kept getting error for GLIBCXX_3.4.20 not found.

[hcho3]

Not sure why you are having issue with glibcxx. For the record, we currently use GCC 9.3.1 to build XGBoost.

[soumen-ghosh]

I am closing the issue for now. We have requested the Blackduck team to update their knowledge base using the git hash. Hopefully, they'll take care of it.