Mike Perry:
> teor:
> >
> >
> > > On 25 Apr 2018, at 18:30, Mike Perry wrote:
> > >
> > > 1. Hidden service use can't push you over to an unused guard (at all).
> > > 2. Hidden service use can't influence your choice of guard (at all).
> > > 3. Exits and websites can't push you over to an unu
Hi nusenu,
I've just finished catching up with this thread, ticket changes,
and the IRC discussion overnight.
> On 28 Apr 2018, at 09:30, teor wrote:
>
> On 28 Apr 2018, at 05:56, nusenu wrote:
>
>>> And also we will be able to reduce the
>>> requirements for becoming an HSDir which will stre
On 28 Apr 2018, at 04:48, Damian Johnson wrote:
>> OnionBalance requires STEM support for V3
>
> Hi Alec, would you mind clarifying what you need from Stem? As far as
> I'm aware Stem supports v3 onion service creation...
>
> https://trac.torproject.org/projects/tor/ticket/25124
>
> See the '
On 28 Apr 2018, at 05:56, nusenu wrote:
>> And also we will be able to reduce the
>> requirements for becoming an HSDir which will strengthen and make our
>> network more robust.
>>
>> That said, I think we are unfortunately still far from deprecating v2
>> onions:
>
>
> thanks for listing a
Hi,
> On 28 Apr 2018, at 06:59, meejah wrote:
>
> After reading the spec diff and your mail, I'm still not sure I
> understand the distinction -- if the x25519 is used to decrypt the
> descriptor then:
>
>> The spec says that the client must have both keys and use both to
>> authenticate, but,
teor:
>
>
> > On 25 Apr 2018, at 18:30, Mike Perry wrote:
> >
> > 1. Hidden service use can't push you over to an unused guard (at all).
> > 2. Hidden service use can't influence your choice of guard (at all).
> > 3. Exits and websites can't push you over to an unused guard (at all)
> > 4. D
Greetings,
(
Meejah and I made txtorcon report the reason for circuit
build failures here: https://github.com/meejah/txtorcon/pull/299
My scanner now uses this txtorcon feature:
https://github.com/david415/tor_partition_scanner
)
I used a collector consensus file: 2018-04-27-19-00-00-consensus
On Fri, Apr 27, 2018 at 04:03:00PM -0400, grarpamp wrote:
> a) If defined as shifting v3 to be "provisioned by default" via docs
> and function, while *continuing to support v2* functionality
> on the network, there's no problem, everyone is happy.
> b) While v2 and v3 do share some capabilities, s
Suphanat Chunhapanya writes:
After reading the spec diff and your mail, I'm still not sure I
understand the distinction -- if the x25519 is used to decrypt the
descriptor then:
> The spec says that the client must have both keys and use both to
> authenticate, but, for me, these two things are q
As I am currently implementing the client authorization for onion
service v3 (https://github.com/torproject/tor/pull/36), I found some
problems in how we should let the users configure the client auth for
their services.
Before getting into the problem, I will explain how it works first.
--
Each
On Fri, Apr 27, 2018 at 6:44 AM, Jonathan Marquardt wrote:
> v3 onion services just seem like a way worse deal to the average user and
> the unknowledgeable admin. Mainly because the addresses are way too long.
Then it's analyzing whether shifting the default to v3 for the clueless and the
perhap
> Yes indeed. The sooner we deprecate v2 the sooner we can stop worrying
> about malicious HSDirs.
yes, that was indeed the motivation for my email (mostly because I see how much
time
goes into the constant detection and rejection of these relays - not by me)
> And also we will be able to reduce
On 27 April 2018 at 19:48, Damian Johnson wrote:
> > OnionBalance requires STEM support for V3
>
> Hi Alec, would you mind clarifying what you need from Stem? As far as
> I'm aware Stem supports v3 onion service creation...
> ...
> I'm unaware of the ball being in my court on any v3 Onion Service
On Fri, Apr 27, 2018 at 8:01 AM, Alec Muffett wrote:
> OnionBalance
Forgot to include this in the former list of
common / useful onion tools, thanks.
If anyone knows of others, feel free to add to thread.
> OTOH, I have been performance testing simultaneous regular-expression
> matching of v2/3
> OnionBalance requires STEM support for V3
Hi Alec, would you mind clarifying what you need from Stem? As far as
I'm aware Stem supports v3 onion service creation...
https://trac.torproject.org/projects/tor/ticket/25124
See the 'version 3' note at the end of...
https://stem.torproject.org/api/
Jonathan Marquardt writes:
> On Wed, Apr 25, 2018 at 04:58:36PM -0400, grarpamp wrote:
>> In onionland, there seems to be little knowledge of v3, thus little worry
>> about v2 in cases where v3 would actually apply to benefit, that's bad.
>
> v3 onion services just seem like a way worse deal to t
It's not just about getting the protocol stack right, but also the
ancillary software environment; people keep asking me for "V3 support in
EOTK" and my stock response is this:
BEGIN
OnionBalance requires STEM support for V3, before it can be updated
(possibly a substantial rewrite will
On Wed, Apr 25, 2018 at 04:58:36PM -0400, grarpamp wrote:
> In onionland, there seems to be little knowledge of v3, thus little worry
> about v2 in cases where v3 would actually apply to benefit, that's bad.
v3 onion services just seem like a way worse deal to the average user and
the unknowledge
18 matches
Mail list logo
