Hi,
Looking at my flagged emails, I found that thread that seems
unfinished. Is it still relevant?
Cheers
On Wed, 28 Nov 2012 21:12:44 +0100 intrigeri intrig...@boum.org wrote:
hi,
(Let's kill this old stalled discussion, and free some mental space
of ours.)
intrigeri wrote (24 Sep 2012
hi,
(Let's kill this old stalled discussion, and free some mental space
of ours.)
intrigeri wrote (24 Sep 2012 10:11:59 GMT) :
anonym wrote (06 Feb 2012 14:24:31 GMT) :
[...] It turned out that if we want a long, stable Tor session with
a time only handled by tordate (like when htpdate
Hi,
Maxim Kammerer wrote (28 Jan 2012 21:40:02 GMT) :
It will download a new consensus after an hour. If htpdate fails,
that's where Tor stops working.
I'm surprised a Tor client with a clock less than 30 minutes off will
behave that poorly, but well, I'll let anonym, who knows much more
than
On Sat, Jan 28, 2012 at 20:52, anonym ano...@lavabit.com wrote:
When Tor shuts down it writes the consensus to the data dir even if it
is unverified. When Tor starts it will load the saved consensus, and now
it will find that it's valid, and hence *NOT* download a new consensus.
All should be
I have reviewed and tested them with positive results, so they are now
merged too.
:)
Just to make this tordate story a bit more never-ending I came up
with a one-liner improvement (wrap-warning!):
[...]
According to dir-spec.txt all directory authorities generates a new
consensus every
01/27/2012 09:36 AM, intrigeri:
Just to make this tordate story a bit more never-ending I came up
with a one-liner improvement (wrap-warning!):
[...]
According to dir-spec.txt all directory authorities generates a new
consensus every hour (see: fresh-until). Since we fetch a new consensus
at
On Fri, Jan 27, 2012 at 17:39, Maxim Kammerer m...@dee.su wrote:
When writing and testing that script, I noticed that the incoming
valid-after is never more than an hour earlier from the current
(correct) time, but at that point it was all kind of black magic, and
I didn't know that (as you
01/21/2012 04:16 PM, anonym:
01/20/2012 07:15 PM, intrigeri:
Hi,
I've pushed some robustness improvements to feature/tordate (forked
from stable branch, targetted at 0.10.1).
I have now tested the additional commits, i.e.:
35a88c3 Only HUP Tor after setting the system time to the release
01/26/2012 02:18 PM, anonym:
01/21/2012 04:16 PM, anonym:
01/20/2012 07:15 PM, intrigeri:
Hi,
I've pushed some robustness improvements to feature/tordate (forked
from stable branch, targetted at 0.10.1).
I have now tested the additional commits, i.e.:
35a88c3 Only HUP Tor after setting
01/20/2012 07:15 PM, intrigeri:
Hi,
I've pushed some robustness improvements to feature/tordate (forked
from stable branch, targetted at 0.10.1). I've tested it a dozen of
times or so with various seriously wrong system clocks, and it works
nicely for me; I could not reproduce the bugs a
Hi,
I've pushed some robustness improvements to feature/tordate (forked
from stable branch, targetted at 0.10.1). I've tested it a dozen of
times or so with various seriously wrong system clocks, and it works
nicely for me; I could not reproduce the bugs a few people have been
reporting on the
hi,
anonym wrote (04 Oct 2011 17:00:48 GMT) :
This doesn't work:
In the clock way in the future case we'll only get an
unverified-consensus. When tor restarts it will read
unverified-consensus, see that it now is valid, and then start using
it. cached-consensus will never be written, so
10/05/2011 11:18 AM, intrigeri:
When I noticed this I talked about it with nickm and Sebastian on
#tor. The real fix is that Tor should rewrite unverified-consensus
into cached-consensus whenever it's reloaded and successfully
verified. Until that is fixed it should be safe to do the
13 matches
Mail list logo
