Closed sburton84 closed 3 weeks ago
Wonder if we could solve this without changing the API with an internal hack?
We could make up a magic number IPv6 SocketAddr
, which when returned from a resolver, triggers the behavior of passing the hostname straight to TcpStream::connect
.
I'd like to avoid magic numbers if we can.
It seems like there is arguably room for another extension point. We have Resolver
, which turns names into IP addresses. We have TlsConnector
, which turns a dialed TCP connection into a TLS stream. We could add Dialer
, which creates a TCP (or other socket) connection. For the Fortanix use case described above this would require a fake Resolver
that doesn't actually do name resolution, but that's doable.
Closing since we're moving to ureq 3.x. In 3.x the resolver is pluggable and can be replaced. This should be solvable.
It would be useful to be able to use
ureq
from inside an SGX enclave that is running using the Fortanix SGX EDP (Enclave Development Platform), which is built using the Cargo targetx86_64-fortanix-unknown-sgx
.The current issue with doing this is related to DNS resolution. Because DNS resolution cannot be done from inside an SGX enclave, the Fortanix code expect a string containing the hostname to be passed to the
TcpStream::connect
function, and then performs name resolution outside of the SGX enclave. But the current ureq implementation expects theResolver
to be able to resolve the name to a concreteSocketAddr
before passing this toTcpStream::connect
. It would be good if there was some way to get it to skip explicit name resolution entirely and just pass thenetloc
string directly toTcpStream::connect
.I have things working inside SGX with the changes I've made on my fork but this is by completely ripping out the name resolution parts so is of course not a general solution.