On Mon, 10 Apr 2017 19:35:24 +0400 meejah <meejah@xxxxxxxxx> wrote: > Obviously as per my other post I agree with fragmented / limited views > given to "real" applications of the control-port. However, personally > I don't see the point of implementing this in 'tor' itself -- existing > control-port filters are "fairly" limited code, typically in "safer > than C" languages anyway. So then you have the situation where > there's a single trusted application (the filter) conencted to the Tor > control-port. I agree with this, because it's basically required to do certain things, and for certain adversarial models. > Ultimately, it would probably be best if there was "a" robust > control-port filter that shipped as part of a Tor release. So if that > means "must implement it in C inside Tor" I guess so be it. I moderately disagree with this. It's not clear to me if a one size fit's all solution (that supports all "first class platforms" and use cases) would be easy to develop initially, and it will take continuous love and care to support everything that people want to do. By "first class" platforms in this context (since it's more client facing) I'll start off with "Whatever Tor Browser happens to be packaged for" as a first pass narrow definition. Even if this was shipped, I'm trying to keep the external dependencies required for correct sandbox functionality to a minimum, and something that's part of the bundle it downloads/auto updates doesn't feel great to me. > Maybe this would be a good target for "experiment with Rust" if > anyone's excited about writing control-port code in Rust...? I disagree with this, but since it'll never be used by the sandbox, my disagreement shouldn't stop anyone. -- Yawning Angel
Attachment:
pgpPJVYNa8t_S.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev