> I have the opposite wish case were I would like to have a terminal
> show me the addresses my tor is connecting to in real-time.
The debug log output isn't very useful for logging the final condition
of successful "connection 'requests' in realtime".
As you can see, only the initial 'Client ask
On 15/04/14 19:36, David Fifield wrote:
> On Tue, Apr 15, 2014 at 02:03:43PM +0100, Ximin Luo wrote:
>> ## The problem
>>
>> The problem with the above structure, is that it is incompatible with the
>> metaphor of connecting to a specific endpoint. This is what the PT spec is
>> about, even though
On Mon, Apr 14, 2014 at 5:32 AM, carlo von lynX
wrote:
[...]
> So the question is, would it be okay to catch ESPIPE in
> all cases, thus having it ignored in tor_fd_seekend,
> or just catch it in add_file_log? Or is there a reason to
> impede the use of unix named pipes under all circumstances?
On Tue, Apr 15, 2014 at 2:27 PM, Nick Mathewson wrote:
> On Mon, Apr 14, 2014 at 5:32 AM, carlo von lynX
> wrote:
> [...]
>> So the question is, would it be okay to catch ESPIPE in
>> all cases, thus having it ignored in tor_fd_seekend,
>> or just catch it in add_file_log? Or is there a reason t
On Tue, Apr 08, 2014 at 02:15:12PM -0500, Nicholas Hopper wrote:
> > 4. Interface
> >
> >To use this feature, a router should rename its secret_id_key
> >file to secret_id_key_OLD. The first time that Tor starts and
> >finds a secret_id_key_OLD file, it generates a new ID key if one
>
On Tue, Apr 15, 2014 at 02:03:43PM +0100, Ximin Luo wrote:
> ## The problem
>
> The problem with the above structure, is that it is incompatible with the
> metaphor of connecting to a specific endpoint. This is what the PT spec is
> about, even though it does not explicitly mention this viewpoint.
On 15/04/14 14:03, Ximin Luo wrote:
> (3, not-ideal) Bridge flashproxy (dummy addr) (fingerprint)
>
> Option (3) is quite nice, since in indirect PTs the actual address is
> irrelevant - the Tor client never tries to connect to it. I suggest that we
> have a special syntax for it though, to explic
## Background
Pluggable Transports are proxy programs that help users bypass censorship.
[App client] -> XXX EVIL CENSOR HAS YOU XXX ACCESS DENIED XXX
[App client] -> [PT client] -> (the cloud!) -> [PT server] -> [App server]
The structural design, on the client side, is roughly:
1. App client
Nicholas Hopper writes:
> On Fri, Apr 11, 2014 at 7:45 AM, George Kadianakis
> wrote:
>> I see. That makes sense, I think.
>
> Good.
>
>> I will ponder on this a bit more, and then edit the proposal.
>
> When/if you become convinced, let me know if you want me to draft a patch.
>
I think it ma
Hiya. Been around the tor dev community a bit, but
today is my first day on the legendary tor-dev
mailing list. I am asking if it makes sense to apply
a minor patch to Tor source, but first, the use case:
tor is very adamant at scrubbing the addresses that
are being connected to in the logs, but I
10 matches
Mail list logo
