android trust store

[dten]

We've had some issues using crates that use openssl for https etc because android's trust store works differently (https://nelenkov.blogspot.co.uk/2011/12/ics-trust-store-implementation.html)

We had a bit of discussion on how to get this working in reqwest as myself and @king6cong also was having the issue seanmonstar/reqwest#70

After some attemps I settled on this (very rough) fix, I'm not 100% happy with it, though it does mean it works for all crates the use openssl without needed to change them.
dten@72da006

Since this crate takes the responsibility of loading the default certificates it feels like this is the right place to fix this but I wondered if there was preferred way.

[king6cong]

@dten Can you make a PR here? This will be better.

[dten]

I'll flesh out the missing parts and neaten things up for a PR if this is something that is likely to be accepted

[dten]

This is how Android deals with loading the certs for java by the way
https://android.googlesource.com/platform/external/conscrypt/+/master/platform/src/main/java/org/conscrypt/TrustedCertificateStore.java

[sfackler]

My intuition is that this'd live outside of rust-openssl itself in the same way that openssl-probe does, but that things like native-tls would pull it in when targeting Android.

[dten]

openssl-probe can get away with setting those environment variables which the C side of things pick up. Which means the final crate that is deployed in the app can be the one who decides to run it and re-target openssl from the default.
Those env variables don't work on android sadly. Mostly because android's certs are stored using the the old hash format (pre 1.0) and there's no way to compile openssl to use that (without actual changes to the c).

[sfackler]

It wouldn't work exactly like openssl-probe at an API level (it'd probably instead fill in an X509Store?), but it'd be similar in that it's a separate crate.

[dten]

Would this be possible to do without having to intervene in every crate that used openssl?

[sfackler]

It'd hopefully only need to be done on things that are explicitly targeting Android and things that want to "magically" just work like native-tls. I want to keep the magic out of openssl itself, since it opens a pretty huge can of worms. Android isn't the only platform that'd need special support to integrate with the system - we'd need to do similar things on Windows and macOS.

[cpick]

I've updated @dten's patch from seanmonstar/reqwest#70 in cpick/rust-openssl@c5f6616 to get it working on the 0.9.x branch.

(As an aside, @dten: are you still using that patch or have you found a different solution?)

[dten]

I do not currently have another solution as this sufficed for my needs