13:43:50 <nickm> #startmeeting
13:43:50 <MeetBot> Meeting started Wed Jan 14 13:43:50 2015 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:43:50 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:44:04 <nickm> Hi dgoulet, Yawning , asn_ , athena !
13:44:10 <nickm> Hi all!
13:44:22 <Yawning> aloha
13:44:33 <asn_> hello!
13:44:54 <asn_> over the past week
13:44:59 <asn_> i opened a few tickets related to hsdirs
13:45:14 <asn_> like #14149 and #14150 and #14202
13:45:24 <asn_> i'm currently fighting with #14090 which is really pissing me off
13:45:36 <asn_> basically, our laplace unittets broke again. this time on raspery pi.
13:45:41 <nickm> oy.
13:45:43 <nickm> why?
13:46:00 <asn_> because that part of the code is weird
13:46:11 <asn_> and that specific unittest is provocative.
13:46:20 <asn_> because it calls log(0)
13:46:24 <asn_> which returns HUGE_VAL
13:46:31 <asn_> and then it gets casted into double. and then it gets casted into int64_t
13:46:34 <asn_> and then it is tested.
13:46:39 <nickm> well that's just weird
13:46:42 <nickm> Why woiuld you do that?
13:46:49 <nickm> *would
13:46:55 <asn_> hm.
13:47:01 <asn_> i think it happened like this
13:47:16 <asn_> because log() returns double. but then we want an integer out of this. so we cast it to int64.
13:47:27 <asn_> but when log() returns infinity (or neg infinity) things get messy.
13:47:45 <asn_> i'm trying to understand why this crashes raspbery pi and not other 32-bit systems.
13:47:51 <asn_> maybe raspery pi has doubles that are 32-bits?
13:48:27 <asn_> i'm trying to get my head around log's HUGE_VAL, and the limits of doubles and int64's.
13:48:34 <asn_> but doubles are quite unspecified from what I see.
13:49:25 <nickm> If you want to cast a double safely to an int64, you need to check whether it's about INT64_MAX before you cast.
13:50:39 <asn_> this is the code of the function that returns double:
13:50:40 <asn_> return mu - b * (p > 0.5 ? 1.0 : -1.0)
13:50:40 <asn_> * tor_mathlog(1.0 - 2.0 * fabs(p - 0.5));
13:50:44 <asn_> which then gets casted to int64.
13:50:53 <asn_> the problem is when p is 0. which causes tor_mathlog(0).
13:50:58 <asn_> mu is also 0 always.
13:51:14 <nickm> sounds like you need to fix that code.
13:51:17 <nickm> how about this:
13:51:46 <asn_> b is a small positive integer.
13:52:08 <asn_> so it's basically: return - 8 * HUGE_VAL . which gets interpeted as a double, and then cast to int64.
13:52:22 <nickm> double result = mu - b * (p > 0.5 ? 1.0 : -1.0)
13:52:23 <nickm> * tor_mathlog(1.0 - 2.0 * fabs(p - 0.5));
13:52:23 <nickm> if (result >= INT64_MAX)
13:52:23 <nickm> return INT64_MAX;
13:52:25 <nickm> else if (result <= INT64_MIN)
13:52:28 <nickm> return INT64_MIN;
13:52:31 <nickm> else
13:52:32 <nickm> return (int64_t) result;
13:52:35 <nickm> would that work?
13:53:30 <asn_> maybe. i'm not sure.
13:54:00 <nickm> The portability issue could be because of undefined/implementation-defined behavior issues
13:54:26 <nickm> I don't know what the standard says about casting a double greater than INT64_MAX to an int64_t, but you probably shouldn't. :)
13:54:46 <asn_> i'm currently afraid that doubles in that platform are smaller than int64s.
13:55:15 <Yawning> that should not happen]
13:55:26 <asn_> ok.
13:55:29 <asn_> that's good.
13:55:44 <Yawning> there's architectures that have doubles that are > 64 bit
13:56:04 <asn_> and there are no archs with doubles less than 64 bit?
13:56:07 <Yawning> and therre's essoteric shit that we probably won't run on anyway
13:56:11 <asn_> 32 bits specifically.
13:56:13 <nickm> The bit width of the double isn't what matters here I think; it's whether the maximum value is > INT64_MAX
13:56:18 <Yawning> not that I'm aware of
13:57:00 <nickm> If there are at least 8 bits of exponent (including sign), you can represent a value greater than INT64_MAX
13:57:01 <Yawning> asn_: if they implement IEEE-754, double is 64 bit by definition
13:57:20 <Yawning> nickm: indeed
13:57:23 <nickm> and I've never heard of anybody having less exponent than that
13:57:25 <asn_> i see.
13:57:33 <asn_> and then there is also the HUGE_VAL thing that log() returns.
13:57:51 <Yawning> (Eg; Cray style single precision is 64 bit)
13:57:58 <asn_> i would like to assume that this is DBL_MAX (and -HUGE_VAL is DBL_MIN), but I'm not sure if this is correct.
13:58:05 <Yawning> (But I'm probably the only person here that ever used that shit)
14:00:54 <nickm> ah, yeah.
14:01:05 <nickm> When a finite value of real floating type is converted to an integer type other than _Bool,
14:01:08 <nickm> the fractional part is discarded (i.e., the value is truncated toward zero). If the value of
14:01:11 <nickm> the integral part cannot be represented by the integer type, the behavior is undefined
14:01:16 <nickm> So, programs just aren't allowed to do that.
14:01:33 <nickm> If it ever works, it's an accident; we should fix it.
14:01:47 <nickm> makes sense?
14:01:52 <asn_> i think so.
14:01:53 <Yawning> yes
14:01:57 <asn_> so basically
14:02:06 <asn_> the overflow check that currently happens in add_laplace_noise()
14:02:13 <asn_> should happen in sample_laplace_distribution() instead
14:02:21 <asn_> in a fashion like the one you suggested some minutes ago.
14:02:34 <asn_> and the problem here appears in archs where doubles are bigger than int64s.
14:02:34 <nickm> oh
14:02:41 <nickm> It's not "bigger"
14:02:52 <nickm> It's "capable of representing bigger values".
14:02:53 <asn_> wider?
14:03:00 <asn_> ack
14:03:20 <asn_> i wonder how I can learn if this is the case for raspberrys.
14:03:40 <nickm> I'd suggest you not  worry.
14:03:44 <nickm> This is undefined behavior.
14:03:51 <nickm> The compiler is allowed to do literally anythign it wants.
14:04:10 <nickm> investigating what the compiler actually does in this case is typically not a great use of your time.
14:04:41 <asn_> but if doubles can represent the same values as int64s, the integral part of a double _can_ be represented by an int64, so it's not undefined behavior, right?
14:05:38 <nickm> no
14:05:45 <nickm> Doubles can represent more values than int64s can
14:05:56 <nickm> Did you ever check out how floating point actually works?  It's kind of interesting
14:06:03 <nickm> (a larger range of values)
14:06:48 <Yawning> sign * mantissa * base ^ exponent
14:06:51 <asn_> i used to understand stuff like mantissas etc. in the past. i don't remember as much these days.
14:07:05 <nickm> what yawning said.
14:07:08 <asn_> ok.
14:07:10 <nickm> where sign is either -1 or +1
14:07:19 <Yawning> you can do interesting bitflipping shit  to make code go really fast by understanding this well
14:07:20 <nickm> and exponent is a signed binary integer  (typically)
14:07:21 <Yawning> >.>
14:07:22 <nickm> and base is 2
14:07:27 <nickm> (typically)
14:07:54 <nickm> and mantissa is a binary fraction in the range [1, 2)
14:07:57 <nickm> (typically)
14:08:08 <asn_> Yawning: would you be willing to review the patch I prepare for that ticket tomorrow or so?
14:08:19 <asn_> Yawning: and I can take some stuff from your review pile, as an exchange :)
14:08:27 <Yawning> sec
14:09:04 <Yawning> probably, will it be large?
14:09:17 <asn_> no
14:09:34 <asn_> shouldn't be at least.
14:09:41 <Yawning> http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
14:09:58 <Yawning> that's kind of old but should cover most stuff
14:10:23 <asn_> ok
14:10:26 <asn_> so thanks both of you.
14:10:39 <asn_> i will look into this, and try to have a patch ready tomorrow or the day after.
14:10:44 <nickm> great
14:10:47 <Yawning> you can ignore everywhere that talks about IEEE 854 since no one uses that shit
14:10:54 <asn_> i also have to:
14:10:54 <Yawning> ^_^
14:10:56 <asn_> ** REVIEW #7555 #14195, #14193, #12485, #13397
14:11:06 <asn_> and that's that from me.
14:11:16 <nickm> ok
14:11:22 <nickm> what's next for somebody else?
14:11:43 <Yawning> uh, tent has an implementation now, and a rough handshake spec
14:11:47 <nickm> neat
14:11:48 <Yawning> people can look at it and comment
14:11:52 <nickm> I should read the handshake spec a little
14:12:04 <nickm> does it provide evertying we wanted on our big list yet?
14:12:13 <Yawning> it needs to be changed into a real language
14:12:15 <Yawning> uh, most of it
14:12:26 <Yawning> no negotiation of primitives is the only thing I think
14:12:28 <Yawning> it doesn't do
14:12:31 <nickm> (I dreamed I was designing TLS-like handshakes last night)
14:12:34 <Yawning> it could easily with 1 more round trip but
14:12:48 <Yawning> (https://github.com/nmathewson/tentp-draft)
14:12:57 <Yawning> not sure if we want that
14:13:21 <Yawning> the spec is split between a handshake spec and what I called obfs5 which is how to make said handshake indistinguishable from random noise
14:13:34 <nickm> ok, I'll try to have a look soon, though I expect to be hyperfocused on Tor 0.2.6 for my coding for a couple of weeks
14:13:43 <nickm> sensible
14:13:55 <Yawning> obfs5 is elligator based, the handshake is primitive agnostic
14:14:06 <Yawning> though I sketeched out how ntor would be used as an example
14:14:56 <Yawning> the basic correctness first transport layer implementation I threw together is fairly sweet
14:15:04 <Yawning> I think the code is really easy to follow, but ymmv
14:16:04 <asn_> added a summary of our discussion here https://trac.torproject.org/projects/tor/ticket/14090#comment:5 .
14:16:12 <nickm> thansk
14:17:23 <nickm> Yawning: nice and short; I like it
14:17:34 <Yawning> rasp pi has hardware floating point right?
14:18:31 <nickm> dunno
14:18:34 <mkstn> Yawning: yep
14:18:56 <nickm> Yawning: I forget; did you pick out a set of Tor 0.2.6.x needs-review tickets to look at?  I'm kinda hoping I can draft reviewers for them all
14:19:09 <Yawning> nickm: not yet I shal do som
14:19:12 <Yawning> *so
14:19:30 <nickm> (so I don't need to dump the whole load on athena, and so I don't need to rationalize, "Well, I'm a different nickm now from the guy who wrote this code...")
14:19:41 <dgoulet> nickm: FYI, I did not and can't tell you when I'll be able to do that this week :S ... so feel free to assign any to me or "the rest" :)
14:19:58 <nickm> dgoulet: understood!
14:20:28 <nickm> Yawning: so what's your plan for the coming week?
14:20:44 <Yawning> catch up on pt paperwork, pick out said review stuff and do the rewview
14:20:48 <Yawning> catch up on e-mail
14:20:53 <Yawning> cuddle the cat
14:20:56 <nickm> grand
14:21:37 <Yawning> change the handshake draft into something that looks more like a spec rahter than "commiting what was in my head to a text document"
14:22:46 <nickm> sounds good to me.
14:22:52 * Guest1917 is here
14:22:57 <athena> oh hai meeting
14:23:03 <nickm> dgoulet: So, you're in meetings and sponsorR stuff all week?
14:23:18 <nickm> and I'll imagine you'll be recovering early next week
14:23:23 <nickm> athena: ohai!
14:23:30 <nickm> hi teor__
14:23:33 <dgoulet> nickm: yeah... pretty full time from 9h to 18hish and then meetings
14:23:38 <nickm> ow
14:23:40 <athena> been revising that #12585 patch and doing some code reviews this week
14:23:45 <nickm> well, good luck and say hi to everybody for me
14:23:54 <nickm> athena: cool.  What's next?
14:23:55 <dgoulet> nickm: I'm in the same time zone so I think I'll be just fine next week :)
14:24:00 <dgoulet> athena: hello!
14:24:04 <athena> going to do more code reviews and #11485 next
14:24:11 <nickm> athena: (thanks for the 12585 fixups; I merged them, I think.)
14:24:14 <Yawning> dgoulet: re TFO and that patch, what he's doing looks correct
14:24:31 <athena> yeah, i think you did
14:24:46 <Yawning> enabling TFO is "use sendto() with a flag instead of connect()"
14:24:47 <dgoulet> Yawning: ah good to know! I haven't tested it, not too familiar with tfo :S thanks!
14:25:32 <Yawning> it basically adds payload earlier in the handshake
14:25:40 <nickm> cool; 11485 will be neat
14:25:43 <Yawning> I personally think it's evil and should be destroyed but the web people like it
14:26:14 <teor__> hi nickm, I am chaos and scattered thoughts
14:26:23 <Yawning> (I likewise think that huge initial windows are evil and should be destroyed)
14:26:24 <nickm> hi teor__!  I hear you are busy.
14:27:00 <nickm> athena: that and reviews will be handy together.
14:27:13 <nickm> I'll be surprised if I get #12498 actually done for this release, but we can hope.
14:27:31 <nickm> I think I'm going to prioritize some work on #13989
14:27:35 <nickm> for my next thikng
14:27:56 <nickm> (And mikeperry pointed out that #5462 is probably the same)
14:28:57 <teor__> nickm: yeah, a few days of chaos, and then hopefully some calm over the weekend. Maybe some time to kill Friday, too.
14:29:24 <teor__> By the way, I am working on #13192 and #14090 with Karsten. Just need to rip some workarounds out of a patch and assert instead.
14:29:53 <nickm> teor__: asn is looking at 14090 too.
14:29:56 <nickm> so there' sthat
14:29:59 <nickm> *there's that
14:30:21 <teor__> Then maybe #9321 as I did a review and ran into a 32-bit crasher. But I have a weird setup with -ftrapv
14:30:51 <nickm> I'm going to have to review #9321 soon again too, and hopefully merge it rsn
14:31:10 <nickm> I wonder if I should put out another alpha in a couple of days; we've merged a lot since the start  of the year
14:31:53 <teor__> If we merge #13111 we'll need to change #9321 slightly to take FN_EMPTY into account.
14:32:06 <teor__> Notes are in both
14:32:57 <teor__> I like the idea of another alpha to test the HS changes, but that's a tor/chutney combination thing
14:33:11 <nickm> I think I did merge #13111
14:34:08 <nickm> After this meeting, I'd like to brainstorm about #13989.  A bunch of people think it's a big security win, and not too hard to implement, assuming we get the design right
14:34:11 <teor__> Yeah it's closed, so we'll need to make a call on FN_EMPTY guardfraction files in #9321
14:35:55 <teor__> Yeah, it would be like the criteria for a sane consensus - "do we have stable enough guards?"
14:37:39 <nickm> anybody else have something for this meeting?  Anything we should be thinking about?
14:37:55 * nickm kinda wants to keep these to 1 hour or less out of respect for everyone's time.
14:39:05 * teor__ is ok
14:39:14 <nickm> #endmeeting