-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
-
False
-
-
Goal:
- Build hf-transfer package with system OpenSSL instead of vendored, self-compiled OpenSSL from openssl-src crate.
The hf-transfer package uses Rust. Amongst others it depends on the openssl crate with "vendored" feature.
https://github.com/huggingface/hf_transfer/blob/v0.1.9/Cargo.toml#L13
[dependencies] ... openssl = { version = "0.10", features = ["vendored"] }
The "vendored" feature pulls in https://crates.io/crates/openssl-src, which contains a copy of OpenSSL sources. The sources are compiled at build time and OpenSSL is statically linked into the shared extension module.
The openssl crate has an option to disable vendored OpenSSL (https://docs.rs/openssl/latest/openssl/)
OPENSSL_NO_VENDOR - If set, always find OpenSSL in the system, even if the vendored feature is enabled.
I have verified that our current build of hf-transfer 0.1.9 does not have a dependency on libssl and libcrypto. A local build with OPENSSL_NO_VENDOR=1 depends on OpenSSL system libraries:
$ OPENSSL_NO_VENDOR=1 python -m build -w -o dist $ cd dist $ unzip hf_transfer-0.1.9.dev0-cp38-abi3-linux_x86_64.whl $ ldd hf_transfer/hf_transfer.abi3.so linux-vdso.so.1 (0x00007ffd8c750000) libssl.so.3 => /lib64/libssl.so.3 (0x00007f09e463e000) libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f09e3c00000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f09e4623000) libm.so.6 => /lib64/libm.so.6 (0x00007f09e4548000) libc.so.6 => /lib64/libc.so.6 (0x00007f09e3800000) /lib64/ld-linux-x86-64.so.2 (0x00007f09e46f0000) libz.so.1 => /lib64/libz.so.1 (0x00007f09e452c000)