logs archiveIRC Archive / Oftc / #tor / 2010 / March / 18 / 1
ilter
Hello all. When a user wants to be a relay enter Tor netw. , it sends it's router descriptor to directory authorities. Then directory authorities verifies this descriptor and if it matches some rules they decide to accept uploading it, After all these, when does a directory authority prepare it's new vote document with this new descriptor?
Sebastian
ilter: once an hour
ilter
Thank you Sebastian. From where did you find this information? in dir-spec?
Sebastian
it's the current voting interval
ilter
Now, i've realized that dir-spec says about times; @ 1858 "Lacking a latest consensus, they SHOULD default to a 30-minute Interval, a 5 minute VotingDelay, and a 5 minute DistDelay."
So can we say that new router descriptor will be included by vote documents of directory authorities in 30 minutes max. ?
Sebastian
no
they have a latest consensus
so they make a new one every hour.
If your timing is unlucky, you might have to wait longer than one hour
nsa
or: pootle committed revision 22001 (/translation/trunk/projects/website/nb): Commit from The Tor Translation Portal by user bleakgadfly. 65 of 65 messages translated (0 fuzzy).
ilter
Hmm .. ok. Then how long voting of all directory authorites takes?
fossiiil
Sebastian: how to spell couns*$##!sus properly? ;-)
and how to pronounce it? :-D
cuntcensus
? ;-)
         

Sebastian
consensus
fossiiil
ok
stupid joking
ilter1
Sorry my net conn. dropped. Was there any answer?
Sebastian
i suggest you ask a dictionary for pronounciation of the word cnsensus.
consensus even
ilter1
Sebastian: is it for me? ..
Sebastian
oh
hah
you didn't ask that question
ilter1
:)
Sebastian
i think authorities vote at :55
then they make a new consensus within the next 5 minutes, and publish it at :00
nsa
or: arma committed revision 22002 (/website/trunk/en): add "Rewrite TorDNSEL" to our project wishlist
ilter1
what about between :30 and :55 ? What is going on this time?
Sebastian
they don't do anything at :30
I think between :50 and :55 they synchronize the descirptors they have
ilter1
Does it mean voting?
Sebastian
no they vote afterwards
arma
Mar 17 18:50:01.779 [notice] Time to vote.
ilter1
*synchronize the descriptors = ? voting
Sebastian
hah
arma
Mar 17 18:52:31.305 [notice] Time to fetch any votes that we're missing.
ilter1
:)
arma
Mar 17 18:55:01.189 [notice] Time to compute a consensus.
Sebastian
I should get my private Tor network back up
         

arma
Mar 17 18:57:31.721 [notice] Time to fetch any signatures that we're missing.
Mar 17 19:00:01.454 [notice] Time to publish the consensus and discard old votes
those are the five steps.
ilter1
arma: Where are these useful logs? Do you collect them from one of authority?
arma
are the typical timing for them.
ilter1: yes
Sebastian
ilter1: yeah, I guess I was confused about the terminology of voting.
sorry -.-
ilter1
No problem Sebastian. You're telling always good for me.
arma
tor defaults to a new consensus every 30 minutes if it doesn't know a number
our current number is 60, so it uses that.
ilter1
arma: Can we access these logs from somewhere?
arma
not really. run a tor network of your own if you want?
or look at the code
ilter1
Hmm.. So how can i learn the current number? Is it written source codes?
*on source codes
Sebastian
ilter1: see the V3AuthVotingInterval N minutes|hours config option
(and related options)
ilter1
Sebastian: you mean in torrc?
Sebastian
yeah
The code sets it to 1 hour by default (in contrast to what arma said, afaiui)
ilter1
I couldn't find V3AuthVotingInterval parameter in torrc?
Sebastian
not every possible option is in the default torrc
see the manpage
arma
sebastian: see dirvote_recalculate_timing()
in particular, the case when !consensus
Sebastian
right
nsa
or: [debian-tor/debian-0.2.1] 2010-02-18 16:54:26 Nick Mathewson <nickm@torproject.org>: Add changelog for latest openssl fix
or: [debian-tor/debian-0.2.1] 2010-02-24 08:36:15 Sebastian Hahn <sebastian@torproject.org>: Proper NULL checking in circuit_list_path_impl()
or: [debian-tor/debian-0.2.1] 2010-02-21 22:27:12 Roger Dingledine <arma@torproject.org>: bump to 0.2.1.24
or: [debian-tor/debian-0.2.1] 2010-02-21 22:52:52 Roger Dingledine <arma@torproject.org>: put 0.2.1.24 in release notes too
or: [debian-tor/debian-0.2.1] 2010-02-23 16:09:02 Sebastian Hahn <sebastian@torproject.org>: Proper NULL checking for hsdesc publication
or: [debian-tor/debian-0.2.1] 2010-03-02 15:40:21 Nick Mathewson <nickm@torproject.org>: Backport fix for time-goes-forward test. Fix bug 1267
or: [debian-tor/debian-0.2.1] 2010-02-18 04:55:03 Nick Mathewson <nickm@torproject.org>: Even more conservative option-setting for SSL renegotiation.
or: [debian-tor/debian-0.2.1] 2010-02-25 09:31:36 Sebastian Hahn <sebastian@torproject.org>: Properly handle non-terminated strings
or: [debian-tor/debian-0.2.1] 2010-03-04 23:37:40 Nick Mathewson <nickm@torproject.org>: Apply Roger's bug 1269 fix.
or: [debian-tor/debian-0.2.1] 2010-02-27 22:13:37 Nick Mathewson <nickm@torproject.org>: Update Tor Project copyright years
or: [debian-tor/debian-0.2.1] 2010-02-22 10:39:29 Sebastian Hahn <sebastian@torproject.org>: Zero a cipher completely before freeing it
or: [debian-tor/debian-0.2.1] 2010-02-18 12:08:57 Sebastian Hahn <sebastian@torproject.org>: Fix compile
or: [debian-tor/debian-0.2.1] 2010-02-18 16:57:47 Nick Mathewson <nickm@torproject.org>: Bump version to 0.2.1.23-dev
or: [debian-tor/debian-0.2.1] 2010-03-16 12:32:57 Peter Palfrader <peter@palfrader.org>: No longer needs patches/15_enable_renegotiation_on_098k.dpatch
or: [debian-tor/debian-0.2.1] 2010-03-15 22:08:29 Roger Dingledine <arma@torproject.org>: bump to 0.2.1.25
or: [debian-tor/debian-0.2.1] 2010-03-16 04:44:30 Roger Dingledine <arma@torproject.org>: give us a blurb; add stanza to the releasenotes
or: [debian-tor/debian-0.2.1] 2010-03-17 22:19:49 Peter Palfrader <peter@palfrader.org>: Merge branch 'debian-merge' into debian-0.2.1
or: [debian-tor/debian-0.2.1] 2010-03-17 22:21:14 Peter Palfrader <peter@palfrader.org>: Change order of recommends from privoxy | polipo to polipo | privoxy.
Sebastian
arma: I guess "giving it a number" might mean "out it in the source as a default" ;)
nsa
or: [debian-tor/debian-0.2.1] 2010-03-07 03:39:34 Roger Dingledine <arma@torproject.org>: clean up the 0.2.1.25 changelog
or: [debian-tor/debian-0.2.1] 2010-03-16 12:30:29 Peter Palfrader <peter@palfrader.org>: Merge commit 'tor-0.2.1.25' into debian-merge
or: [debian-tor/debian-0.2.1] 2010-03-16 12:31:55 Peter Palfrader <peter@palfrader.org>: New upstream version
Sebastian
someone might want to update the topic
and announce 0.2.1.25 ;)
ah, tbb isn't built
arma
yep. i'm blocking on that for the announce
also, i plan to declare 0.2.0.x obsolete in that announce
in other news. http://metrics.torproject.org/new-users-graphs.html#burma -- what country does it say that graph is for, for you?
weasel
which probably means I should patch out the thing that starts bi**hing to users if they run a version you don't like anymore. for next time when that happens
Sebastian
arma: Burmese Tor users
ilter1
Ok guys i got it thank you so much.
weasel
arma: the captions are somehow off, aren't they?
arma
weasel: for some browsers they are, for some apparently not.
Sebastian
yes they look weird
weasel
ah
I see what happens
Sebastian
but it's the right graph for me
weasel
maybe you should insert linebreaks when you go from one country to the next
arma
what's a linebreak? "<br />"?
weasel
or <p> or whatever
Sebastian
setting targets with <p> borders works usually
weasel
also, it's not entirely clear if the caption belongs to the image above or below
Sebastian
but some browsers have a cute problem:
They render the page, and take you to the anchor
dr|z3d
(Action) resists the urge to engage in a webdev type discussion.
Sebastian
then they realize they need to fit all those images
then they fetch them, and expand the website
and you're in a totally wrong place
the way to fix that is give the images dimensions that reflect reality
or update your browser
(Action) suspects arma is on IE 5.0
karsten: ^^^^ you might want to implement some of these suggestions.
ilter1
arma: Finally can we summarize it like this order?; a user who wants to be a relay prepares its router descriptor / it sends this new router descriptors to all authorities @any time / authorities check it @any time / if they accept it they put it in their vote documents before :50 ? / :50 time to vote / :52 time to fetch missing votes / 00: time to publish consensus / Then new OR is ready to be used.
Sebastian
ilter1: except not quite
once the consensus is published, it needs to be cached
and people need to start using it
that takes more time again
it will only be available to newly bootstrapping clients
ilter1
Oops i forgot it. What about the others? Are they in right order?
Sebastian
They start making the vote document at :50
from all the descriptors they know about
when they're done, they publish to the other auths they know about.
arma
ilter1: see section 1.4 of dir-spec.txt
you've left out some steps, and i think you misunderstand others but i'm not sure.
ilter1
I've just looked it.
Sebastian
hah. I know have one favorite gsoc project, and one that I'd like to mentor most. yay
arma
sebastian: which one is that?
Sebastian
favorite is unit testing, and I'd most like to mentor dnsel
ilter1
arma: I'm trying to make it certain. As far as i read there're 2 distinct documents (vote and consensus).
Sebastian
I pondered learning Go so I could rewrite it in a new totally sketchy language that nobody knows
arma
we should recruit good people to do each of those, then, rather than waiting and suggesting them to people who show up. i fear that people who show up have a higher likelihood of being flaky and clueless
ilter1: yes. plus there are signatures.
ilter1
All authorities firstly making their own vote documents?
Sebastian
ilter1: they all make a vote. Then from all the votes, a consensus is computed.
they all compute the consensus in the same way
following the same rules
minus bugs
arma: I'll start promising stuff to people once we're in.
ilter1
Sebastian: they all don't make a vote as far as i understood. They all make their own vote documents. Then there are 7 votes before preparing consensus doc. Please verify me?
*7 vote documents
Sebastian
every authority makes its own vote document
ilter1
Yes that's what i know.
ilter
Thank you so much Sebastian, arma. Now it seems more clearly for me.
arma
ilter: great. sorry the dir-spec is not as easy to read as it could be
nsa
or: arma committed revision 22003 (/website/trunk/en): explain why we need a rewrite
Sebastian
arma: maybe would/could?
erm
+This project would make use of <a
could instead of would?
arma
are there any other reasonable alternatives, if you want to finish it in a summer?
i guess the torflow side isn't too big a part of it.
still, i think torctl is your best bet, and torflow is an easy choice once you've chosen torctl
Sebastian
ok
hm
yeah
arma
if somebody wants to do it in something that's not C or python or perl, we'll have a tougher time maintaining it
and if they want to do it in C or perl, they're nuts.
Sebastian
being nuts isn't always bad
unless they really want perl ;P
bja
So i changed proxy, I use polipo now, so i restarted the tor daemon several times today, but it is been painfully slow and painfully lagging. Is there a way to pinpoint why?
Will a git alpha version behave properly or is it something out of sheer luck?
formalist
sometimes tor is fast and sometimes it is slow.
i think it gets faster as more nodes follow more current versions of tor.
nsa
or: phobos committed revision 22004 (/website/trunk/include): osx ppc packages for 0.2.1.25 now available.
narr
today is a bad tay for the tor network
arma
how so?
phobos
funny, i've found today quite acceptable
bja
Not good for me either,
narr
my node wasn't up
;-)
nsa
or: n8fr8 committed revision 22005 (/projects/android/trunk/Orbot/src/org/torproject/android): fixed a few small bugs, added new network package classes for future functionality
or: n8fr8 committed revision 22006 (/projects/android/trunk/Orbot): updated changelog and resource definition files
or: n8fr8 committed revision 22007 (/projects/android/trunk/Orbot): returned AUTHORS file to its proper and rightful state
rudi_s_
Hi. I'm searching for the 0.2.1.25 changelog. Can't find it in http://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=ReleaseNotes ; f=ChangeLog displays it as not yet released.
arma
rudi_s_: try the maint-0.2.1 branch
rudi_s_: or grab the tarball and read the ReleaseNotes or ChangeLog files in the tarball
rudi_s_
arma: Thanks. Just curious, why isn't Git up to date?
arma
because we develop the 0.2.1.x releases in the maint-0.2.1 branch,
and periodically merge the maint-0.2.1 branch into master
i guess nobody has done that merge lately
rudi_s_
arma: Ah, okay. Then maybe the link at the download page to the changelog should get updated (or point to a version from the current tarball).
arma
yes. hm.
once upon a time we had source tree checkouts to link to
we got rid of those when we moved to git, because officially there's no such thing as "the checkout". that makes me sad.
rudi_s_
arma: Why not just use a git checkout using the tag of the release?
arma
why not indeed. because the nice volunteer setting up the gitweb isn't doing that. :)
Sebastian
https://gitweb.torproject.org//tor.git?a=blob;f=ChangeLog;hb=tor-0.2.1.25 that exists.
and the nice volunteer thought his work was done with gitweb because everyone was happy, and that he didn't need to convince we*sel that we should use non-stable debian packages
arma
i wonder if we should change the ChangeLog url to point to hb=<version> and let wml keep updating the url.
Sebastian
I'm not sure what kind of checkout people want.
I think gitweb is fine
« prev 1 2 3 4 next »