Re: [tor-dev] Tor path selection upon failure

Thanks for your notes. Tim. :) From: tor-dev [tor-dev-boun...@lists.torproject.org] on behalf of teor [teor2...@gmail.com] Sent: Tuesday, September 13, 2016 19:42 To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Tor path selection upon failure >

Re: [tor-dev] "old style" hidden services after Prop224

> On 14 Sep 2016, at 00:40, s7r wrote: > > Also, we need to move with Prop 245 (deprecate TAP handshake entirely) > and the v2 hidden service code is the blocker for this. As an aside, if it wasn't for v2 hidden services, we could have removed TAP entirely in 0.2.9. Instead,

Re: [tor-dev] Tor path selection upon failure

> On 14 Sep 2016, at 07:28, Liu, Zhuotao wrote: > > Hi Folks, > > There have been some technical reports about how to deal with the problem > when a botnet uses Tor as its primary C channel. In this case, the CPU of > some relays is exhausted, causing circuit creation

Re: [tor-dev] [Patch] common/util_bug.h

> On 13 Sep 2016, at 18:52, Gisle Vanem wrote: > > The 'IF_BUG_ONCE__' for non-gcc is wrong. A simple patch: > > --- a/util_bug.h 2016-09-13 10:44:59 > +++ b/util_bug.h 2016-09-08 20:24:45 > @@ -117,7 +117,7 @@ > #else > #define IF_BUG_ONCE__(cond,var)

Re: [tor-dev] v2 to v3 onion service transition (was: "old style" hidden services after Prop224)

Forking this thread to discuss onion service transition path. David Goulet: > The question arise now. Someone running a .onion upgrades her tor that > supports v3, should we allow v2 to continue running or transition it to v3 or > make them both happy together...? We haven't discuss this in depth

Re: [tor-dev] "old style" hidden services after Prop224

I agree with both s7r and Lunar here. Just want to add some bits: > I disagree with your approach, for comparison's sake, let's say v2 is IPv4 > and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still > is to this day, although IPv6 is arguably a much better solution in a lot >

Re: [tor-dev] "old style" hidden services after Prop224

I fully agree with the security points, I was just arguing for keeping the _option_ to list a v2 service for a longer time (possibly forever). Let's not make assumptions for the service operators - ok, make them enable the option explicitly, have them do it at compile time if you want to (like

Re: [tor-dev] "old style" hidden services after Prop224

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 s7r: > So, my opinion is to deprecate v2 entirely after a sane and > reasonable transition period. Apologies to whom this will create > headaches - technologically everything can be adjusted to v3 hidden > services, it's just some work required

Re: [tor-dev] "old style" hidden services after Prop224

I disagree with your approach, for comparison's sake, let's say v2 is IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still is to this day, although IPv6 is arguably a much better solution in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a

Re: [tor-dev] "old style" hidden services after Prop224

On 9/13/2016 3:27 PM, David Goulet wrote: [SNIP] > Hello! > > So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite > complex, lots of pieces need to be glued together and prop224 will add a lot > of new code (in the 10 of thousand+). > > We decided a while back to have

Re: [tor-dev] "old style" hidden services after Prop224

On 12 Sep (22:29:00), Ivan Markin wrote: > Razvan Dragomirescu: > > Thank you Ivan! I still dont see a very good reason to _replace_ the > > current HS system with the one in Prop224 and not run the two in > > parallel. > > For me it's because it would make overall system more complex and thus >

Re: [tor-dev] "old style" hidden services after Prop224

Hello Ivan, Breaking existing (possibly automated) systems is a _very good reason_ IMHO :). Sure, warn the operators that they're using a legacy system, deprecate the option but don't disable it. https://trac.torproject.org/projects/tor/ticket/18054 sounds like a pretty sane solution btw. Even

[tor-dev] [Patch] common/util_bug.h

The 'IF_BUG_ONCE__' for non-gcc is wrong. A simple patch: --- a/util_bug.h 2016-09-13 10:44:59 +++ b/util_bug.h 2016-09-08 20:24:45 @@ -117,7 +117,7 @@ #else #define IF_BUG_ONCE__(cond,var) \ static int var = 0;

Re: [tor-dev] [tor-relays] Tor path selection upon failure

> On 13 Sep 2016, at 14:02, Liu, Zhuotao wrote: > > Hi Folks, Hi, Please don't cross post to multiple lists, it makes it hard for people to follow all the responses. Can I suggest that everyone replies to tor-dev, as it's the list for Tor development, feature, and issue