Open
Description
Type of feature
π Feature
Current behavior
Ideally we wouldn't be consuming openssl through the native-tls chain of dependencies:
β― cargo tree -i native-tls
native-tls v0.2.11
βββ hyper-tls v0.5.0
β βββ reqwest v0.11.18
β βββ cached-path v0.6.1
β β βββ tokenizers v0.13.3
β β βββ open-sauced-repo-query v0.1.0 (/Users/jpmcb/workspace/opensauced/repo-query)
β βββ open-sauced-repo-query v0.1.0 (/Users/jpmcb/workspace/opensauced/repo-query)
β βββ openai-api-rs v0.1.11
β β βββ open-sauced-repo-query v0.1.0 (/Users/jpmcb/workspace/opensauced/repo-query)
β βββ qdrant-client v1.3.0
β β βββ open-sauced-repo-query v0.1.0 (/Users/jpmcb/workspace/opensauced/repo-query)
β βββ tokenizers v0.13.3 (*)
βββ reqwest v0.11.18 (*)
βββ tokio-native-tls v0.3.1
βββ hyper-tls v0.5.0 (*)
βββ reqwest v0.11.18 (*)
But it looks like a there are some upstream changes that would need to be made in order to flip them to using rustls (or at least enable a feature that can use rustls-tls instead of native-tls)
Suggested solution
We'd need to upstream some changes to those libraries that are deep in our rust dependencies.
And this shouldn't be a priority until we consider adding TLS for requests to the repo-query engine. More just noting this for myself and others to be aware of.
Additional context
No response
Code of Conduct
- I agree to follow this project's Code of Conduct
Contributing Docs
- I agree to follow this project's Contribution Docs
Metadata
Metadata
Assignees
Labels
No labels