Re: [Tails-dev] bridge mode vs. clock way off

Delete this message

Reply to this message
Autor: anonym
Data:  
A: The Tails public development discussion list
Assumptes nous: [Tails-dev] Please review and merge bugfix/tordate_vs_bridge_mode [was: bridge mode vs. clock way off]
Assumpte: Re: [Tails-dev] bridge mode vs. clock way off
22/11/12 14:11, intrigeri wrote:
> Hi,
>
> anonym wrote (21 Nov 2012 14:21:43 GMT) :
>> Log severity info is really verbose. I ran a test for 20 minutes with
>> some rather heavy Tor usage, and the log grew something like
>> 100KB/minute. That's too much, IMHO.
>
> Agreed.
>
>> However, we can save this approach
>> like this:
>
>> 1. We patch torrc at build time to have "Log info ...", as proposed.
>> 2. But once tordate finishes we edit torrc and downgrade to notice
>>    level debugging, and send a SIGHUP to Tor.

>
>> Ugly, ugly, ugly workarounds, all the time! :) What do you think?
>
> Wow... I could live with that, but if there's a trivial bugfix in Tor
> itself that can allow us to avoid yet another ugly kludge, then I'd
> rather use the possibility thereof.


I tried implementing this in a branch yesterday, hoping to get it in
0.15. I encountered some issues, and then I saw that you had already
pushed the 0.15 tag etc. so I didn't look on it again until today. It
turns step 2 isn't as easy as I initially thought:

Since we're in bridge mode, Vidalia will start before tordate so bridges
can be added. When Vidalia connects to Tor, it unsets the (hidden) Tor
option "__ReloadTorrcOnSIGHUP", so we either have to:

a. restart Tor (and Vidalia) yet again to have Tor re-read the new
torrc (now without "info" level logging), or
b. manually re-set "__ReloadTorrcOnSIGHUP", send a HUP so Tor re-reads
torrc and then possibly unset "__ReloadTorrcOnSIGHUP" again (or
restart Vidalia)

I don't like either, mostly because this was meant to be a simple,
unobtrusive fix. I guess option a is best so Vidalia doesn't get
out-of-sync with Tor's state, if that's possible. But it's yet another
Tor restart...

Note: You can't change anything about "Log" lines in torrc via the
control port. Otherwise that'd be the easy way out.

I updated the ticket. I'm not

>>>> 3. What about patching Tor to eliminate the log severity
>>>>    inconsistency? But perhaps they have good reasons for this being
>>>>    the way it is so it wouldn't get upstreamed?

>>>
>>> I think it's worth asking them if there's a good reason for the
>>> apparent inconsistency.
>
>> On second thought, if we're gonna look towards upstream, I'd rather we
>> spend our energy on a proper fix, not a fix that make our current
>> workaround work... urgh.
>
> I don't see these two approaches as incompatible.


I wasn't talking about that. I was talking about saving time and energy.

> If there are no good reasons for the log severity inconsistency, then
> that's a (minor) bug you have discovered in Tor, and I think we should
> report it as such, regardless of the solution we choose for the
> problem at hand, and regardless of whether we implement a nice new
> feature in Tor 0.2.4.x or later. I'll take care of reporting the bug
> if needed, just tell me: it'll take me less time to actually do it,
> than to argue any longer about whether we should report it or not ;)


If you feel like it shoot.

> If that works, and Tor 0.2.3.x has this bug fixed $soon,
> then problem solved, no kludge to add to our pile and maintain.
> Would $soon = end of the year seem reasonable to you?


Yes.

Cheers!