kpcyrd/chrootable-https

Sandbox+chroot friendly https client

chrootable-https

If you ever tried chrooting an https client into an empty folder you probably ran into two problems:

• /etc/resolv.conf doesn't exist in an empty folder
• ca-certificates doesn't exist in an empty folder

This crate is working around those issues by using:

• trust-dns so the recursor can be specified expliticly
• rustls and webpki-roots to avoid loading certificates from disk

We're also trying to avoid C dependencies and stick to safe rust as much as possible.

Examples

extern crate chrootable_https;
use chrootable_https::{Resolver, Client};

let resolver = Resolver::cloudflare();
let client = Client::new(resolver);

let reply = client.get("https://httpbin.org/anything").expect("request failed");
println!("{:#?}", reply);

License

LGPL-3+

chrootable-https's Issues

Request timeout

There should be a way to timeout requests that take too long.

Serializable resolver config

The resolver config should be serializable, so it can be loaded in advance and then passed to a sandbox.

Client panics if resolver returns ipv6 addresses

There are multiple issues here:

• the connector configures the destination in an incorrect way if the resolver returned an ipv6 address
• the connector uses .expect which causes a panic
• the resolver may use the ipv6 record even if only ipv4 is available

Option to disable certificate verification

There should be a way to disable certificate verification if needed.

Enable keepalive

We currently have to disable keepalive because the request hangs forever if we enable it.

This needs some investigation if we are using hyper incorrectly or if this is a bug.

Return async responses

It would be nice if Client::get() and other request methods returned a ResponseFuture for use with async runtimes, like the current hyper::Client does for tokio. This would be great for easily managing multiple concurrent downloads and measuring the progress of individual streams. This crate already depends on tokio, so I imagine it would be technically trivial to expose the asynchronous interface underneath somehow.

udp socket leak

As mentioned in #15 there's currently a udp socket leak.

This is difficult to resolve due to trust-dns/hyper/tokio limitations.