Hi Nick,
It would be useful to have a way of controlling access to the SOCKS port
so that untrusted applications running on the same device as a Tor
client can't use the Tor client's SOCKS proxy. This is something that
people auditing Briar have raised as a security concern.
Unix sockets are
On Tue, Sep 10, 2024 at 6:26 PM Jim Newsome wrote:
>
> It'd be helpful to have more context about the object IDs and what we're
> trying to accomplish with them here; why we need/want them in arti but
> didn't in c-tor. I'm inferring (maybe incorrectly) that the idea is that
> this is effectively
It'd be helpful to have more context about the object IDs and what we're
trying to accomplish with them here; why we need/want them in arti but
didn't in c-tor. I'm inferring (maybe incorrectly) that the idea is that
this is effectively letting us multiplex differently-configured
SOCKS->Tor ser
On Tue, Sep 10, 2024 at 9:25 AM Q Misell via tor-dev
wrote:
>
> Is there a reason why this proposal extends the existing username/password
> auth, instead of defining a new SOCKS5 authentication type? c.f.
> https://datatracker.ietf.org/doc/html/rfc1928#section-3
Indeed there is! The one I was
Is there a reason why this proposal extends the existing username/password
auth, instead of defining a new SOCKS5 authentication type? c.f.
https://e.as207960.net/w4bdyj/5dQ6fT3QLm2aTfUx
--
Any statements contained in this email are personal to the author and are
not ne
(You can see this proposal rendered at
https://spec.torproject.org/proposals/351-socks-auth-extensions.html )
```
Filename: 351-socks-auth-extensions.md
Title: Making SOCKS5 authentication extensions extensible
Author: Nick Mathewson
Created: 9 September 2024
Status: Open
```
## Introduction
Cur
