rustls-platform-verifier doesn't work on termux

[NobodyXu]

cargo-bins/cargo-binstall#2473

Binaries built for aarch64-unkown-linux-* failed to get the openssl certs stored in /data/data/com.termux/files/usr/etc/tls/ and then failed in termux without getting any fallback

https://docs.rs/rustls-platform-verifier/0.6.2/src/rustls_platform_verifier/verification/others.rs.html#106

This line fails on UNIX, except for apple, android and wasm32, if rustls-native-cert cannot find any certificate , and obviously it isn't smart enough to find native certa in termux

It only uses hardcoded certificates for wasm32

For android, rusts-platform-verifier assumes you are building an android app requires extra initialization to get the java runtime, otherwise straight failure without even trying to find native certa

https://docs.rs/rustls-platform-verifier/0.6.2/rustls_platform_verifier/android/index.html

[complexspaces]

Thanks for the report! Hopefully this is actionable.

Binaries built for aarch64-unkown-linux-* failed to get the openssl certs stored in /data/data/com.termux/files/usr/etc/tls/ and then failed in termux without getting any fallback

As you noticed, on generic UNIX platforms rustls-platform-verifier uses rustls-native-certs, and transitively, openssl-probe to locate the certificates to load. From what I can tell, openssl-probe already supports termux, with that support being several years old. It looks for a single file and from skimming the linked cargo-bininstall issue the affected user has the cert.pem present so this is a weird situation.

Would it be possible for your side to check if openssl-probe locates anything when called independently to figure out if the issue is there or in rustls-native-certs? FYI @djc in case you have any thoughts as the current openssl-probe maintainer.

Binaries built for aarch64-unkown-linux-*
...
For android, rusts-platform-verifier assumes you are building an android app requires extra initialization to get the java runtime, otherwise straight failure without even trying to find native certa

This is expected behavior, FWIW. I don't expect us to support non-Java based apps on the aarch64-linux-android target anytime soon given the additional complexity of testing and detection of which backend should be used.

[djc]

Yeah, there's definitely some termux support in openssl-probe but it might be outdated? Happy to transfer this issue there if that ends up being the culprit.

(Would be good to understand which version of openssl-probe is being used here.)

[ctz]

rustls/openssl-probe#31 is worth noting. Only target_os = "android" receives the special termux knowledge. If that isn't going to work (eg, for a aarch64-unkown-linux-* target) then some other method will be needed -- at runtime -- to communicate the path.

[complexspaces]

Oh great spot, thanks. I was staring at the path itself too hard 😅.

From upstream it sounds like setting the environment variable while using a non-Android target did work for the original reporter, which explains itself and why openssl-probe isn't getting used at all.

I guess that leaves us with an open question about if, and how, we want to smooth out the non-ideal target overlap here. I've spent some thinking about this problem in the context of arboard but I haven't come up with a solution that's very satisfying yet.

• A Cargo feature would work but is problematic because it forces too many crates to be aware of Termux themself.
• Android has no target_env we could detect instead of target_os unlike some of Apple's targets.
• Runtime detection by looking at environment variables/filesystem paths is prone to edge cases and would result in these users still needing to build jni despite it being unused.
• Silently falling back to assuming Termux when the JNI objects aren't initialized sounds like a security problem waiting to happen.

[NobodyXu]

It seems that termux has some builtin environment variables such as

• PREFIX
• TERMUX_ANDROID_HOME
• TERMUX__PREFIX

It also has a termux-info command.

Unfortunately I don't have an Android device for testing of those

[MuntasirSZN]

I run termux daily, so I can do some testing here and there (if it gets implemented.)

So a lot of envs are set, termux related envs are dumped below (they are required so that termux can function):

SHELL=/data/data/com.termux/files/usr/bin/nu
PREFIX=/data/data/com.termux/files/usr
TERMUX_IS_DEBUGGABLE_BUILD=0
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX__HOME=/data/data/com.termux/files/home
TERMUX_VERSION=0.118.3
TERMUX_APP__SE_INFO=default:targetSdkVersion=28:complete
TERMUX__ROOTFS_DIR=/data/data/com.termux/files
EXTERNAL_STORAGE=/storage/self/primary
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec-ld-preload.so
TERMUX_API_VERSION=0.53.0
HOME=/data/data/com.termux/files/home
TERMUX_APK_RELEASE=F_DROID
TMPDIR=/data/data/com.termux/files/usr/tmp
TERMUX__PREFIX=/data/data/com.termux/files/usr
TERMUX_APP__SE_FILE_CONTEXT=u:object_r:app_data_file:s0:c110,c256,c512,c768
TERMUX_APP__LEGACY_DATA_DIR=/data/data/com.termux
TERMUX__SE_PROCESS_CONTEXT=u:r:untrusted_app_27:s0:c110,c256,c512,c768
TERMUX_APP_PID=15853
PATH=/data/data/com.termux/files/usr/bin
TERMUX_APP__DATA_DIR=/data/user/0/com.termux
_=/data/data/com.termux/files/usr/bin/printenv

(I have removed ANDROID_* and some other envs, they are expected in normal linux + android).

[MuntasirSZN]

What if we just check if we are in termux in unix path?

We don't need jni.

[VickWildman]

Unfortunately huggingface_hub also doesn't work on Termux because of this.

Expect rustls-platform-verifier to be initialized

Even if I set SSL_CERT_DIR to $TERMUX__PREFIX/etc/tls it fails.

'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)' thrown while requesting HEAD https://huggingface.co/unsloth/Qwen3.5-9B-GGUF/resolve/main/Qwen3.5-9B-Q8_0.gguf

Apparently rustls-platform-verifier never supported Termux, but since reqwest 1.3.0 started using it and a lot of things are using reqwest we are now having issues.

seanmonstar/reqwest#2966

It looks like git-xet still works in Termux and it works even better than hf download, so at least I'm set.

[djc]

'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)' thrown while requesting HEAD https://huggingface.co/unsloth/Qwen3.5-9B-GGUF/resolve/main/Qwen3.5-9B-Q8_0.gguf

FWIW, that does not look like an error originating from rustls-platform-verifier (or its dependencies).