In Debian we try very hard to avoid having multiple copies of the root certificate store. As such we really want to avoid packaging the webpki-roots crate since webpki-roots not only contains a duplicate root certificate store, but causes said root certificate store to become hard-coded into all applications built against it. The result of this is that right now the rust-async-tls package in Debian is patched such that it is only usable for server applications.
To fix this I would propose restructuring the "client" feature upstream into four features.
"client-base" would enable the client functionality in the package, but would not load any root certificates by default.
"client-webpki-roots" would enable the client functionality and load root certificates from webpki-roots
"client-native-roots" would enable the client functionality and load root certificates from rustls-native-certs
"client" would be an alias for "client-webpki-roots"
Then in Debian, rather than disabling the client functionality completely as we do now, we would disable "client-webpki-roots" and change "client" to be an alias for "client-native-roots".
Hi, I'm one of the Debian rust maintainers.
In Debian we try very hard to avoid having multiple copies of the root certificate store. As such we really want to avoid packaging the webpki-roots crate since webpki-roots not only contains a duplicate root certificate store, but causes said root certificate store to become hard-coded into all applications built against it. The result of this is that right now the rust-async-tls package in Debian is patched such that it is only usable for server applications.
To fix this I would propose restructuring the "client" feature upstream into four features.
Then in Debian, rather than disabling the client functionality completely as we do now, we would disable "client-webpki-roots" and change "client" to be an alias for "client-native-roots".
What do you think of this proposal?