Re: [tor-dev] tor's definition of 'median'
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.
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] [important] sponsors deliverables discussion point for Wed's meeting
Alright, now sending the list to CC and directly emailing the team. Notes from today about this and 0.2.7 freeze. For sponsor deliverables / please add your name on the 'who can do it' column if you can pick up a task. We will be checking this spreadsheet on our meetings till the sponsors deadline to make sure we are not forgetting any task behind :) On the spreadsheet: * Row 5 is top priority right now since is a dependency for Row 6 * Some of the documentation tasks could be done in a collaborative way / if you want to share a pad please add a link to it at the spreadsheet. About 0.2.7 freeze: Please review what you tagged for August and is part of 0.2.7 / not all the things we triaged for it will make it in but lets make sure what we have prioritized for August can make it. Check meetbot logs for the source! :) cheers, isabela On 08/10/2015 01:57 PM, Isabela wrote: Hello Core Tor folks! Note: if you are not a contractor or full time you can ignore this email, it is about paid deliverables. Me and Nick have been working on documenting the current status of our deliverables for the year to Sponsor S [project year ends on October] and Sponsor U [project year ends on November]. The result gave us a clear picture of where we need your help with. Please take a look at: https://docs.google.com/spreadsheets/d/1dTva10mu-FcX8KrxRjgkFvHSyNy7aBpD9xehNuUeZ-4/edit?usp=sharing For Wednesday we want to figure out how can people jump in and help on these tasks. Right now we have a lot assigned to Nick and is a big red flag that we won't make it. Not to mention that Nick also has to carry on other work and to do both is just impossible. Please take a look, ask questions and lets figure out how we can conclude all this tasks. Priorities are: * Rows 5 6 * And any help on the other tasks that are all about writing docs (rows 12, 13, 15, 16, 17) * Or maybe help out with the final push for Sponsor S tasks We will be adding the related tickets (column H) later today so you can take a look before the meeting on Wednesday. thanks! isabela ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa 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
[tor-dev] IMPT -- Re: Future Onion Addresses and Human Factors
Aside: in pursuit of helping Jake register “.onion” as a special name” in an RFC, I am currently being beaten-up on the IETF discussion mail-list regards the potential future length of onion addresses, and that they may possibly exceed the bounds of DNS’ maximum label length of 63 characters: https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html The examples in Proposal 224 are a mere 53 characters long leaving 10 to play with for padding-hyphens and possibly checksum characters. Nick: Is this likely to need to change? Or might there be a need to encode 315 bits / 63 chars total? -a — Alec Muffett Security Infrastructure Facebook Engineering London 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] IMPT -- Re: Future Onion Addresses and Human Factors
On Wed, Aug 12, 2015 at 11:59 AM, Alec Muffett al...@fb.com wrote: Aside: in pursuit of helping Jake register “.onion” as a special name” in an RFC, I am currently being beaten-up on the IETF discussion mail-list regards the potential future length of onion addresses, and that they may possibly exceed the bounds of DNS’ maximum label length of 63 characters: https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html The examples in Proposal 224 are a mere 53 characters long leaving 10 to play with for padding-hyphens and possibly checksum characters. Nick: Is this likely to need to change? Or might there be a need to encode 315 bits / 63 chars total? I don't anticipate this changing. If there were ever a need to encode more than that number of bits, we'd add an extra label. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
