Re: [tor-dev] [Twisted-Python] please can haz code review - Tor-ified Twisted Python HTTP proxy server - txtorhttpproxy
Dear Aaon Gallagher, Thanks for the helpful observation. i'm going to make the correction soon and then we'll be underscore free. On Wed, Aug 12, 2015 at 7:06 AM, Aaron Gallagher _...@habnab.it wrote: David Stainton dstainton...@gmail.com writes: If I get rid of this last terrible import: from twisted.web._newclient import ResponseDone then I'm not sure how to detect when to call the finish() method here: https://github.com/david415/txtorhttpproxy/blob/master/txtorhttpproxy/proxy.py#L38-L52 Fortunately, ResponseDone is re-exported by twisted.web.client: import twisted.web.client twisted.web.client.ResponseDone is twisted.web._newclient.ResponseDone True twisted.__version__ '11.0.0' I couldn't get 9.0 to compile in the five seconds I tried, but 11.0 is still pretty old. I think it always was re-exported like this. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor's definition of 'median'
On Wed, Aug 12, 2015 at 5:34 PM, nusenu nus...@openmailbox.org wrote:
from today's measurement meeting:
15:00:20 virgil karsten: I've decided I'm going to fix the definition of
median
15:00:26 virgil in the tor sourcecode
15:00:36 karsten virgil: is it broken?
15:00:53 karsten or just not specified as clearly as it should be?
15:01:01 virgil for ordered list {a,b,c,d}, it returns b instead of
(b+c)/2.
15:01:24 karsten yes. maybe that's for a reason (which I don't know).
15:01:40 virgil I look forward to hearing this reason when my patch is
rejected.
15:01:41 karsten like, using value (b+c)/2 would break for some reason,
whereas any of a, b, c, d would be fine.
15:01:45 Sebastian you cannot do that
15:01:51 Sebastian without breaking Tor's voting
15:02:21 Sebastian Tor's specification requires low median for a bunch of
directory stuff
I'd be interested in the reason as well.
The correct fix here is to update the code documentation to define the
functions as returning the low-median, and to update dir-spec.txt to
say so too. I'd accept documentation patches like that.
Changing the code to return the mean of the two center elements from
even arrays would break all authority voting, and wouldn't actually be
useful.
--
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor's definition of 'median'
Changing the code to return the mean of the two center elements from even arrays would break all authority voting, and wouldn't actually be useful. Yes, that is what Sebastian said on IRC as well. Can you shed some light as to why it would break voting? thanks signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor's definition of 'median'
On 14 Aug 2015, at 03:10 , nusenu nus...@openmailbox.org wrote: Changing the code to return the mean of the two center elements from even arrays would break all authority voting, and wouldn't actually be useful. Yes, that is what Sebastian said on IRC as well. Can you shed some light as to why it would break voting? If the authorities supply different values in the consensus, voting breaks. Authorities using the low-median would supply one value, and authorities using the mean-median would supply another value. (Authorities typically run different versions of tor, and don't upgrade all at once.) Breaking changes like this are typically negotiated among the authorities using numbered consensus methods. Once enough authorities support a new consensus method, it is activated during voting. Rather than creating a new consensus method to implement mean-median, it's much easier to patch the documentation to specify low-median. (And I see no significant gain in changing from low-median to mean-median.) I'd rather see bandwidth measurements become more accurate, for more relays, more of the time, than change how their median is defined. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
people wrote: And just where exactly and in what protocols and apps are going to build in that feedback popup... browsers? ssh? MUA? ping? skype? Vanity addresses encourage people to only verify the human-readable part That said, if an address is completely incapable, even hostile to validation by human eyeballs, then what happens is “trust” migrates Humans give up on long strings of anything because it requires work to validate. If not at first glance different, how many people here give up, pipe to hash, and use the avalanche to compare. Outside of better introduction, pinning, bookmarking, chaining, namespaces and WOT, humans and strings are just intractable. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor's definition of 'median'
On 13 Aug 2015, at 18:50, Nick Mathewson ni...@alum.mit.edu wrote:
On Wed, Aug 12, 2015 at 5:34 PM, nusenu nus...@openmailbox.org wrote:
from today's measurement meeting:
15:00:20 virgil karsten: I've decided I'm going to fix the definition of
median
15:00:26 virgil in the tor sourcecode
15:00:36 karsten virgil: is it broken?
15:00:53 karsten or just not specified as clearly as it should be?
15:01:01 virgil for ordered list {a,b,c,d}, it returns b instead of
(b+c)/2.
15:01:24 karsten yes. maybe that's for a reason (which I don't know).
15:01:40 virgil I look forward to hearing this reason when my patch is
rejected.
15:01:41 karsten like, using value (b+c)/2 would break for some reason,
whereas any of a, b, c, d would be fine.
15:01:45 Sebastian you cannot do that
15:01:51 Sebastian without breaking Tor's voting
15:02:21 Sebastian Tor's specification requires low median for a bunch of
directory stuff
I'd be interested in the reason as well.
The correct fix here is to update the code documentation to define the
functions as returning the low-median, and to update dir-spec.txt to
say so too. I'd accept documentation patches like that.
The documentation for the code already says that. The spec could be
updated to say low-median consistently, tho.
Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
