On 2018-01-10 at 23:25:05 +, teor wrote:
Sending every remote site address from the Tor process to an extension
increases the surface area for attacks.
[...]
This gives the extension access to the content of every encrypted page.
[...]
Please develop a least-authority design. Don't beco
> On 11 Jan 2018, at 11:30, Beastr0 wrote:
>
> (yeah, ik you guys got this running on some automated script or something but
> I don't have access and that sounds unnecessarily complicated so I'm just
> gonna do this quick header for context)
We have fallback directory mirrors to make it eas
On 10 Jan 2018, Teor wrote:(yeah, ik you guys got this running on
some automated script or something but I don't have access and that sounds
unnecessarily complicated so I'm just gonna do this quick header for context)
>Sounds great!
>>Are there any particular parts of Tor you want
teor:
> I've looked at the Tor source code that handles versions. Version
> parsing and voting seem to happen unconditionally.
>
> I also checked router_differences_are_cosmetic(), and it seems to
> handle platform string changes correctly.
I'll need to read a spec to know what "correctly" exac
Hi,
On 11 Jan 2018, at 05:38, nullius wrote:
>> Here's what I suggest you do:
>>
>> Blocking an entire CDN would be a major change to either Tor or Tor
>> Browser's design. It's not likely to happen, because of the security vs
>> usability tradeoff. Significantly reducing the usability of Tor
> On 11 Jan 2018, at 00:43, nusenu wrote:
>
> Hi,
>
> the goal of this email is to avoid a false positive warning for relay
> operators
> on atlas but the root cause might be in core tor.
>
> background:
> I really liked when irl added the big red warning to atlas when a tor relay
> runs an o
At https://trac.torproject.org/projects/tor/ticket/24774#comment:5 ,
nickm stated:
I'm not sure that the sandboxing section is necessary. We should say
that _all_ plugins should only access the network over Tor, unless they
are using some comparably strong anonymity mechanism. [...]
In reply
I am the reporter of #24351. As thereto, thanks for your thoughts,
teor; I will respond accordingly:
2018-01-10 at 00:57:53 +, teor wrote:
On 10 Jan 2018, at 10:23, debug wrote:
Is there any specific reason why there is no comment from Tor-team for
this issue?
https://trac.torproject
Hi,
the goal of this email is to avoid a false positive warning for relay operators
on atlas but the root cause might be in core tor.
background:
I really liked when irl added the big red warning to atlas when a tor relay
runs an outdated (aka not running a "recommended") tor version
because it a
> On 10 Jan 2018, at 22:22, Beastr0 wrote:
>
> T,
>
> I'm interested in helping you guys with Tor development. I don't really care
> what I work on, except I do not support .onion websites (though I am willing
> to be convinced otherwise) so I would prefer not to participate directly in
> t
Hi,
We've merged a new list of fallbacks in the version 2.0.0 format.
But we also want to keep a separate list of authorities, rather than hiding
them in the middle of config.c:
https://trac.torproject.org/projects/tor/ticket/24818
So we are changing the current authority and fallback list form
T,
I'm interested in helping you guys with Tor development. I don't really care
what I work on, except I do not support .onion websites (though I am willing to
be convinced otherwise) so I would prefer not to participate directly in their
development. I have plenty of experience with writing co
Hello all,
I am just going to update my tor server, building packages from source. I do
that not only for tor but also for libevent. So I downloaded the tarballs plus
signature from libevent.org and that's what I found:
$ gpg --verify libevent-2.0.22-stable.tar.gz.asc
gpg: Signature made Mon Ja
13 matches
Mail list logo
