[tor-dev] Restricting SOCKS access now and later (was Re: Proposal 351: Making SOCKS5 authentication extensions extensible)

[Nick Mathewson]

On Thu, Sep 12, 2024 at 5:21 AM Michael Rogers <michael at briarproject.org> wrote:
> On 11/09/2024 14:12, Nick Mathewson wrote:

> > ## An answer you probably can't use: embedding Arti
> >
> > Right now, you can embed Arti in any Rust app.  Some folks have
> > already started to write wrappers for Java and other languages.  With
> > our RPC protocol, we intend to support embedding Arti in any
> > application written in any language that can call C and link a
> > library.
> >
> > So with this solution, there is no SOCKS port at all, and nobody can
> > use your Tor client but you.
>
> I think we'll want to move to embedding Arti via Java bindings in
> future, but we may still want to expose a SOCKS port so that we can use
> HTTP libraries that expect to talk to a SOCKS port.
>
> Is that expected to be a supported way of using Arti? For example, if
> we're talking to Arti via bindings rather than RPC on the control port,
> will it still be possible to open a SOCKS port and will we still have a
> session ID that we can use as a capability on the SOCKS port?

I do think this is something that we want to support, but I don't know
if we'll get it built in the earliest versions of our FFI embedding
logic.  There is a _lot_ of code to write, and a _lot_ of
functionality to support -- so please poke us again (maybe on the
bugtracker?) if this isn't easily do-able in the first supported FFI
embedding scheme we make.