00:37:14  * indexzerojoined
01:00:08  * `3rdEdenquit (Quit: Zzzzzzz)
01:12:41  * indexzeroquit (Quit: indexzero)
01:21:26  * indexzerojoined
01:29:09  * indexzeroquit (Quit: indexzero)
01:35:36  * indexzerojoined
01:38:36  * indexzeroquit (Client Quit)
01:39:18  * mikealjoined
01:39:30  * indexzerojoined
01:44:23  * mikealquit (Quit: Leaving.)
01:55:16  * mikealjoined
02:00:01  * indexzeroquit (Quit: indexzero)
02:04:21  * perezdquit (Quit: perezd)
02:12:33  * brsonquit (Quit: leaving)
02:17:06  * mikealquit (Quit: Leaving.)
03:10:16  * isaacsquit (Remote host closed the connection)
05:00:46  * kuebkjoined
05:04:37  * kuebk^quit (Ping timeout: 252 seconds)
06:10:32  * isaacsjoined
06:13:48  * mikealjoined
06:53:04  * indutny_sleepingchanged nick to indutny
06:53:11  <indutny>pquerna: blocking whom?
06:53:48  <indutny>pquerna: oh I see, better ask ryah about that
06:54:06  <indutny>pquerna: is there any risks of upgrading to that version?
07:03:45  * mikealquit (Quit: Leaving.)
07:07:29  * mikealjoined
07:09:07  * mralephjoined
07:15:09  <pquerna>indutny: i mean, it has somenice features built in and mainline, not as patch sets
07:15:19  <pquerna>indutny: along with the asm updates for EC stuff
07:15:57  <isaacs>pquerna: what version of what now?
07:16:18  <isaacs>oh, openssl?
07:17:24  <indutny>0.9.8r
07:17:55  <indutny>oh there're some bug fixes since it
07:17:59  <indutny>http://www.openssl.org/news/changelog.html
07:18:11  <indutny>we should really consider updating it in unstable branch
07:22:12  * mikealquit (Quit: Leaving.)
07:26:58  * mikealjoined
07:35:35  * mikealquit (Quit: Leaving.)
08:14:23  * indexzerojoined
08:22:52  * mikealjoined
08:34:05  * `3rdEdenjoined
08:34:52  * isaacsquit (Remote host closed the connection)
08:35:29  * isaacsjoined
08:42:54  * isaacsquit (Ping timeout: 252 seconds)
08:42:55  * `3rdEdenquit (Read error: Connection reset by peer)
09:40:22  * `3rdEdenjoined
09:52:46  * indexzeroquit (Quit: indexzero)
10:36:46  * AndreasMadsenjoined
10:51:27  * paddybyersjoined
10:54:42  <indutny>hey, any unix uv guys here?
10:55:03  <indutny>would be neat if someone will review that https://github.com/joyent/libuv/pull/292
10:55:16  <indutny>bnoorhuis: actually that was addressed to you ^
10:55:20  <indutny>;)
12:20:10  * indutnychanged nick to indutny_away
13:12:13  * kuebkquit
13:15:58  * `3rdEdenchanged nick to `3E|Movie
13:18:09  * `3E|Moviequit (Quit: ppapapapappfpapfdsasjdf;asdjfa;sdlkfjadls; fapfapfap)
13:43:20  * paddybyersquit (Quit: paddybyers)
14:26:07  * paddybyersjoined
14:57:40  * `3rdEdenjoined
15:17:09  * `3rdEdenquit (Read error: Connection reset by peer)
15:22:36  * bnoordhuisjoined
15:23:06  * `3rdEdenjoined
15:27:21  <bnoordhuis>pquerna: we build openssl without asm support (for now anyway)
15:35:24  <bnoordhuis>indutny_away: reviewed
15:38:32  * indutny_awaychanged nick to indutny
15:38:36  <indutny>heya
15:39:44  <indutny>bnoordhuis: applying your patch
15:39:58  <indutny>bnoordhuis: do you think increasing delta and max will help fixing race?
15:41:12  <bnoordhuis>indutny: why is that check there in the first place?
15:41:47  <indutny>bnoordhuis: bnoordhuis does place matter?
15:42:05  <indutny>bnoordhuis: after starting eio reqs, counters should not change
15:42:10  <bnoordhuis>indutny: sorry, i mean what's it supposed to guard against?
15:42:19  <bnoordhuis>that there aren't too many requests in flight?
15:42:45  <indutny>bnoordhuis: if you'll print out LOGF("%d - %d\n", opened, closed)
15:42:50  <indutny>bnoordhuis: you'll see what's happening
15:43:05  <indutny>bnoordhuis: 90% of eio reqs are delayed
15:43:12  <indutny>so opened will grow fast
15:43:17  <indutny>and closed very slow
15:43:36  <indutny>with patch they're almost equal
15:43:41  <indutny>and close to each other
15:43:50  <bnoordhuis>not when i run it through valgrind :)
15:44:07  <indutny>bnoordhuis: black voodoo magic
15:44:14  <indutny>bnoordhuis: I increased delta
15:44:21  <indutny>bnoordhuis: and force pushed patch
15:44:46  <indutny>bnoordhuis: I don't have valgrind installed, can you verify it again?
15:45:39  <indutny>bnoordhuis: even with delta = 9000 patched uv will pass test
15:45:55  <indutny>oh, incorrect sentence
15:46:07  <bnoordhuis>it works but ask yourself if it's a good check
15:46:13  <bnoordhuis>btw, there's valgrind for the mac
15:46:15  <indutny>bnoordhuis: non-patched uv will fail even with delta = 9000
15:46:58  <indutny>bnoordhuis: kk, building
15:47:05  <indutny>brb
15:47:38  * dshaw_joined
15:48:01  <AndreasMadsen>bnoordhuis: did you find any problems with https://github.com/joyent/node/pull/2463
15:52:45  <CIA-115>node: Ben Noordhuis master * r93465d3 / configure : build: support --dest-cpu configure switch again - http://git.io/QBgfRA
16:04:21  * travis-cijoined
16:04:21  <travis-ci>[travis-ci] joyent/node#238 (master - 93465d3 : Ben Noordhuis): The build is still failing.
16:04:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/2202887...93465d3
16:04:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/526743
16:04:21  * travis-cipart
16:14:10  * `3rdEdenchanged nick to `3E|DINNER
16:32:50  <indutny>bnoordhuis: ohh, automake problems
16:33:06  <indutny>bnoordhuis: building now
16:33:47  * paddybyersquit (Quit: paddybyers)
16:39:50  <indutny>bnoordhuis: ok, tested it. correct delta is 4000 for me
16:39:59  <indutny>bnoordhuis: force pushing
16:40:31  <indutny>bnoordhuis: done, https://github.com/joyent/libuv/pull/292
16:40:33  <indutny>ping?
17:40:31  <indutny>bnoordhuis: ping ? :)
17:42:41  * `3E|DINNERchanged nick to `3rdEden
17:55:44  * paddybyersjoined
18:20:24  * benviequit
18:35:33  * ErikCorryV8joined
18:35:41  * ErikCorryV8changed nick to ErikCorry_
18:43:12  * isaacsjoined
18:46:18  * isaacsquit (Remote host closed the connection)
18:47:58  <indutny>ErikCorry_: hello!
18:48:50  <ErikCorry_>Hi
18:49:46  * mikealquit (Quit: Leaving.)
18:49:58  <indutny>ErikCorry_: what do you think? is that possible to land split-dictionary stuff next week?
18:50:11  <indutny>ErikCorry_: do you need any help?
18:50:13  <ErikCorry_>I should think so.
18:50:43  <ErikCorry_>Well it's been waiting for review since 3 in the morning on Saturday morning.
18:50:56  <ErikCorry_>I wouldn't expect anyone to review it between that time and Sunday night.
18:51:03  <ErikCorry_>So I'm not worried.
18:51:06  <indutny>:)
18:51:12  <indutny>yeah, that's understood
18:51:13  <ErikCorry_>How is the mitigation coming along on the node side.
18:51:56  <ErikCorry_>Are you guys just expecting V( to solve all the problems, or is there a feeling that perhaps it's not a good idea to allow anyone to dump many megabytes of HTTP headers on a node server by default?
18:53:02  <indutny>ErikCorry_: I think we'll eventually add limits, but that's not depends on me
18:53:51  <ErikCorry_>Should I hold off fixing the NumberDictionary DOS until limits have been added, in order not to remove the motivation to do the right thing?
18:53:54  <indutny>ErikCorry_: personally, I think we can just add limits to http_parser.c
18:54:02  <indutny>ErikCorry_: hahaha :)
18:54:31  <indutny>ErikCorry_: btw, NumberDictionary DoS is not so effective
18:55:01  <indutny>ErikCorry_: as string DoS
18:56:00  <indutny>ErikCorry_: I'll open PR on http_parser tonight or tomorrow, but I think ryah has more clear view on that things
18:56:35  <ErikCorry_>the arguments to GET and POST have the same issue, right?
18:57:04  <indutny>ErikCorry_: yes, but POST should limited on user-land
18:57:14  <indutny>ErikCorry_: we ain't parsing it in node
18:57:27  <indutny>ErikCorry_: we ain't parsing GET url too
18:57:57  <indutny>ErikCorry_: so I can only add limits to headers count and to querystring js module
19:02:34  <ErikCorry_>User-land or not, it needs fixing. Is there at least an open bug on querystring?
19:02:40  <ErikCorry_>Also, looking at https://github.com/visionmedia/node-querystring/blob/master/examples.js
19:03:08  <indutny>ErikCorry_: that's another query string
19:03:15  <ErikCorry_>It seems like if someone makes a query like ?toString=foo or ?__proto__=foo then you are borked.
19:03:27  <ErikCorry_>Which querystring do you mean then?
19:04:16  <indutny>ErikCorry_: https://github.com/joyent/node/blob/master/lib/querystring.js
19:04:48  <ErikCorry_>That looks like it's part of node to me.
19:05:24  <ErikCorry_>So saying that it is user-land is a bit of a cop-out if it's coming from the same place as the non-user-land (kernel-land?)
19:05:31  <indutny>ErikCorry_: it is
19:05:43  <indutny>ErikCorry_: but isn't parsing all POST requests
19:05:52  <indutny>ErikCorry_: what about JSON POST
19:05:56  <indutny>ErikCorry_: that's what I meant
19:06:07  <indutny>ErikCorry_: and btw, it won't be borked with __proto__=val
19:06:19  <indutny>ErikCorry_: because it checks for HasOwnProperty
19:06:49  <indutny>ErikCorry_: I really do care more about http headers
19:08:33  <ErikCorry_>Not every web server accepts untrusted JSON, but they pretty much all accept untrusted HTTP headers, and GET and POST requests.
19:08:39  <ErikCorry_>So the issue is much less acute with JSON
19:09:02  <indutny>ErikCorry_: agreed
19:09:04  <ErikCorry_>Does the http parser allow HTTP keys to be numeric?
19:09:38  <ErikCorry_>Seems like you could just ban that without any compatibility problems at all.
19:10:09  <mraleph>IMHO VM can't solve all problems for developers and should not try to.
19:10:50  <mraleph>why not ask VM to convert arbitrary O(n^2) algorithm into O(1) one?
19:11:13  <indutny>ErikCorry_: as I can see it allows both numeric and string keys
19:11:28  <indutny>mraleph: that would be cool :) can you disagree? :)
19:11:32  <mraleph>"omg my VM does not optimize bublesort into radix sort where appropriate, we are all doomed"
19:11:53  <indutny>mraleph: a boundary, man, there's a boundary
19:12:21  <indutny>mraleph: between: "VM please do it for me", and that stuff is expected to work but it causes DoS on my server
19:12:51  <ErikCorry_>indutny: It's all about being careful with untrusted data.
19:12:55  <mraleph>expect to work on what exact reason?
19:13:24  <indutny>mraleph: because JSON objects with many collisions are different from regular objects in only one way
19:13:27  <indutny>mraleph: they're big
19:13:54  <indutny>mraleph: and when you're using JSON inside your app or platform's core you should not care about collisions
19:14:03  <mraleph>does ECMA-262 specify any time complexity bounds on JSON.parse?
19:14:18  <indutny>mraleph: lets add sleep(3) to it then :)
19:14:20  * isaacsjoined
19:14:24  <ErikCorry_>You can allow untrusted data into your program in the form of data, but not in the form of code. If you are using an object as a hash map, just adding properties that the attacker provides to your object then you are getting pretty close to allowing the attacker to control the code on your server.
19:14:31  <ErikCorry_>That's the real issue here.
19:14:44  <indutny>ErikCorry_: say that to couchdb ;)
19:14:51  <ErikCorry_>Just because a JS object acts a little like a hash map that doesn't mean you should be using it that way.
19:15:30  <indutny>ErikCorry_: yes, but JSON object is a "black box" for platform
19:15:35  <mraleph>if somebody is doing it wrong that does not mean everybody have to do it wrong and hope that VM somehow magically saves them from understanding complexity of involved algorithms.
19:16:00  <indutny>mraleph: everybody understand that lookup and insert time varies for hashmaps
19:16:13  <indutny>mraleph: but you're using some assumptions to make it as fast as possible
19:16:26  <indutny>mraleph: because of that assumptions hash-collisions dos attack is possible
19:16:40  <indutny>mraleph: if you would use b-tree buckets instead of key-space
19:16:52  <indutny>mraleph: collisions will be impossible
19:17:03  <indutny>mraleph: but speed will suffer dramatically
19:17:29  <indutny>mraleph: making something fast w/o caring about security is not good
19:17:42  <indutny>mraleph: you can assume that all keys are smaller than 10 chars
19:17:50  <indutny>mraleph: and create symbol for every key
19:18:09  <indutny>mraleph: that'll kill many apps immediately
19:18:31  <indutny>mraleph: why should they care about way you implemented something well-known like hashmaps?
19:18:46  <ErikCorry_>indutny: We care about security. But do the node developers care? What non-V8 patches have gone in since this issue cropped up?
19:19:08  <indutny>ErikCorry_: it's hard to do this w/o breaking compatibility
19:19:20  <mraleph>no it is not
19:19:43  <indutny>mraleph: something may stop working
19:20:15  <mraleph>I don't see how e.g. seeding things on node.js side is going to make thing "stop working"
19:20:20  <indutny>mraleph: for example, I'm going to add option argument to qs.parse that'll allow changing new 'default' limit
19:20:22  <ErikCorry_>These bad excuses: It's hard to do due to compatibility. It's in user-space so it's not our problem. But V8 is expected to fix stuff that is only broken if someone has let the attacker decide the names of the member variables on an object.
19:20:58  * mikealjoined
19:21:00  <indutny>ErikCorry_: yes, that's why we'll do it on both sides
19:21:13  <indutny>ErikCorry_: probably we'll land that in 0.6.0 branch, that's not upon on me
19:21:22  <ErikCorry_>Good, both sides, but can you point at progress on the other side?
19:21:48  <indutny>ErikCorry_: I'll send you a link once I'll finish pull request (just started)
19:22:01  <indutny>isaacs: yt? what do you think?
19:22:20  <isaacs>hi
19:22:30  <indutny>isaacs: hi
19:22:59  * isaacsreading scrollback
19:24:26  <isaacs>the bigger issue that querystring.parse is the http header object.
19:24:34  <indutny>isaacs: +1
19:24:40  <indutny>isaacs: that can be done on lib/http.js side
19:24:40  <isaacs>because, *every* nodejs server is vulnerable to this, whether they do querystring.parse() or not.
19:24:50  <indutny>isaacs: we're collecting all headers in array first
19:25:36  <isaacs>indutny: right, but fixing this in lib/http.js or in lib/querystring.js is silly if the v8 team decides that its worth fixing in v8 itself.
19:25:56  <indutny>isaacs: that's what I was trying to say
19:26:04  <isaacs>also, this means that we will need to get all users to be very careful about using JSON.parse
19:26:24  <indutny>ErikCorry_: mraleph: sorry guys if I misunderstood you
19:26:27  <isaacs>right or wrong, the fact of the world today is that people run JSON.parse on user-supplied data all the time.
19:26:37  <isaacs>because we've all been saying for ages that it's the "safe" way to do it.
19:27:02  <isaacs>if we now need to say that JSON.parse, even on relatively small strings of data, is unsafe, then that's a big change in the message.
19:27:48  <isaacs>if it's for some reason not fixable in v8 itself, then of course we'll address this in node.
19:28:25  <isaacs>from where i'm sitting, as a user of v8 rather than a v8 maintainer or developer, that would be disappointing, but we'd deal.
19:29:13  <ErikCorry_>JSON.parse is safe in the sense that noone can use it to pwn you.
19:29:22  <ErikCorry_>But if you have no size restriction then they can DOS you.
19:29:40  <ErikCorry_>We can fix the hash collision issue, but they can still DOS you if you have no size restriction.
19:29:49  <indutny>ErikCorry_: you're right!
19:29:51  <isaacs>ErikCorry_: yes.
19:29:55  <ErikCorry_>They can just use up all memory.
19:30:03  <indutny>ErikCorry_: prob, time to add require('json'). isaacs what do you think?
19:30:09  <isaacs>ErikCorry_: we're not asking v8 to prevent users from accepting arbitrarily large bits of data into memory.
19:30:22  <isaacs>indutny: no, JSON is a javascript language feature now, right or wrong.
19:31:16  <isaacs>ErikCorry_: but, it's quite common for a user to say, the limit is 1kb or 1mb, and plan for a relatively predictable amount of time/cpu/space required to parse that. if a user sends a message that is too big, node leaves it in the user's hands to set that limit.
19:31:25  <ErikCorry_>The way I see it, if you are accepting JSON from somewhere and not limiting the size then you are trusting them to some extent.
19:31:32  <isaacs>ErikCorry_: absolutely.
19:31:43  <isaacs>ErikCorry_: i expect node users to limit the size that they are willing to buffer in memory.
19:31:56  <ErikCorry_>Not to the extent that you would let them pwn your server, but to the extent that you say, I don't think that they would fsck me around, and if they do I will notice it and block them.
19:32:11  <isaacs>ErikCorry_: there are also a few streaming json parsers out htere, if you want ot parse json without storing it all in memory. they're slower, but smaller space for large message.
19:32:25  <isaacs>ErikCorry_: +1, yes.
19:32:46  <ErikCorry_>The streaming parsers are probably not vulnerable to the hash collision issue.
19:33:00  <isaacs>ErikCorry_: why not?
19:33:13  <indutny>ErikCorry_: that depends on how you're processing gathered data later
19:33:36  <isaacs>ErikCorry_: at least one of them builds up an object just like json.parse does, but it just does it without requiring that you buffer the entire message in memory first.
19:33:53  <ErikCorry_>Well if they are keeping the whole object in memory at once then they are not streaming, and if you are not keeping the whole object in memory at once then you can't have the hashes colliding (they are not simultaneously there)
19:34:16  <isaacs>ErikCorry_: i mean, streaming the incoming string data
19:34:24  <ErikCorry_>isaacs: Since the object takes up more space than the text version of the JSON then that isn't going to buy you much
19:34:44  <isaacs>ErikCorry_: i know this, but people are weird :)
19:35:06  <ErikCorry_>OK, but then I don't see how the streaming parsers are really relevant to the discussion.
19:35:12  <isaacs>ErikCorry_: the point is, if you have a reasonable sized job that suddenly becomes unreasonable because the attacker can exploit an edge case in v8, then that becomes an issue.
19:35:43  <isaacs>query string and http headers are already very limited in size.
19:35:54  <ErikCorry_>They are?
19:36:01  <ErikCorry_>Then how can someone make an attack with them?
19:36:12  <ErikCorry_>The demos I have seen have been with 10s of thousands of keys.
19:36:22  <isaacs>ErikCorry_: 1MB isn't that big
19:36:48  <ErikCorry_>I don't think it qualifies as 'very limited in size' for HTTP headers?
19:36:56  <isaacs>i mean, it's not arbitrary.
19:37:13  <ErikCorry_>Have you ever seen a real app that required more than a few K of HTTP headers?
19:37:21  <isaacs>you can test pushing it to its limits without collisions, and it will perform fine.
19:37:39  <isaacs>then an attacker comes along and makes it take an OOM more time and cpu to parse.
19:37:41  <isaacs>that's a problem.
19:37:48  <ErikCorry_>No OOM.
19:37:51  <ErikCorry_>Memory use does not change.
19:38:34  <isaacs>oom = order of magnitude
19:38:38  <isaacs>not "outof memory"
19:38:44  <isaacs>sorry, ambiguous acronyms :)
19:39:49  <ErikCorry_>Sure it's a problem, and we are fixing it. But another part of the problem is that 1Mbytes is just too big a limit for a set of HTTP headers.
19:39:49  <isaacs>so... you said that you're going to fix the hash collision issue for 3.6, or no? i'm sorry, i'm a little unsure what we're actually discussing.
19:39:58  <ErikCorry_>Yeah, we are fixing it.
19:40:03  <isaacs>awesome!
19:40:04  <isaacs>:)
19:40:47  <mraleph>we are discussing the fact that people should be more security aware themselves
19:41:02  <indutny>mraleph: +1
19:41:13  <isaacs>mraleph: yes
19:41:18  <isaacs>mraleph: that's not disputed :)
19:42:01  <indutny>mraleph: assume that v8 is a black box for almost everyone (including me)
19:42:01  <isaacs>anyway, i believe that apache limits header size to 8kb by default, and iis to 16 or so.
19:42:02  <indutny>:D
19:42:12  * AndreasMadsenquit (Remote host closed the connection)
19:42:17  <ErikCorry_>I wish we could have fixed the issue faster in V8, but it's a pretty central part of the VM, and there have been a few hiccups along the way. In this time I'm a little disappointed that no defense-in-depth stuff has (apparently - correct me if I am wrong) been committed on the node side to protect users.
19:42:45  <indutny>ErikCorry_: finishing pull req now
19:43:34  * AndreasMadsenjoined
19:44:34  <isaacs>ErikCorry_: it hasn't been that long.
19:45:23  <isaacs>ErikCorry_: and, since most node services *do* limit the size of their acceptable http header size, it's not a gigantic threat.
19:45:29  * TooTallNatejoined
19:47:04  <indutny>ErikCorry_: mraleph isaacs https://github.com/joyent/node/pull/2538
19:47:29  <indutny>brb
19:50:41  <isaacs>indutny: can use use 10000 instead of 1000, and still be relatively safe from attack there?
19:51:25  <indutny>isaacs: yeah, of course
19:51:50  <indutny>but you can build a DoS collisions with 10000 keys :)
19:52:19  <pquerna>http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfields
19:53:11  <pquerna>http headers: 100, size of single header: 8190 bytes
19:53:36  <isaacs>ok, 1000 is probably fine then.
19:56:58  <indutny>isaacs: mat
19:57:12  <indutny>s/mat/may be we should limit header value size too?
19:58:06  <pquerna>cookies can be a target of simliar attacks
19:58:12  <pquerna>since express etc all parse em
19:59:34  * AndreasMadsenquit (Remote host closed the connection)
20:00:12  <indutny>pquerna: that's express issue indeed
20:01:02  <indutny>isaacs: should we wait for others to review my patch or just push it to master?
20:01:16  <isaacs>i'm still kind of studying it
20:01:17  <isaacs>just a sec
20:01:23  <isaacs>i'll lgtm it, and then you can master push it :)
20:01:25  <indutny>isaacs: do you have any ammendments, comments?
20:01:32  <indutny>isaacs: ok :)
20:01:35  <indutny>sounds good
20:03:19  <indutny>I'll add docs after that
20:04:15  <indutny>btw, looks like http_parser is not limiting header name and value size at all
20:04:44  <isaacs>indutny: that parser object in lib/http.js is exposed yes? so the user can change it if necessary?
20:04:45  <indutny>so node'll just buffer incoming data until client will send ":" after header name
20:05:20  <isaacs>yikes
20:06:04  <isaacs>k, lgtm for master. not sure about v0.6
20:06:10  <isaacs>indutny: ^
20:06:14  <indutny>isaacs: it's exposed only in .request()
20:06:19  <indutny>isaacs: not visible inside server
20:06:26  <isaacs>indutny: i see...
20:06:46  <indutny>isaacs: but you can change it in runtime, though
20:06:49  <isaacs>indutny: it'd be nice if there was a way to change it. i don't know why you would, but people do weird things with node http servers.
20:06:54  <isaacs>sure
20:06:59  <isaacs>in runtime?
20:07:03  <indutny>isaacs: have you seen my example?
20:07:12  <indutny>isaacs: server.maxHeadersCount
20:07:25  <indutny>isaacs: new parser is created on each connection
20:07:32  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
20:07:34  <isaacs>ok
20:07:36  <indutny>isaacs: so it'll just take it from server
20:07:36  <isaacs>kewl, lgtm
20:07:39  <indutny>cool
20:07:41  <isaacs>gotta run for #nodeup podcast
20:07:46  <indutny>heh
20:07:46  <indutny>ok
20:08:01  <indutny>I'll add docs and open separate PR
20:08:11  <indutny>or can you wait for docs too?
20:09:51  <indutny>isaacs: ^
20:10:15  <isaacs>indutny: can you add docs to the same pr?
20:10:21  <isaacs>same commit, even
20:10:27  <isaacs>then it's easier to roll back if necessary
20:10:39  <indutny>isaacs: yeah, 1 minute
20:14:00  <indutny>isaacs: force pushing, 1 sec
20:14:34  <indutny>isaacs: updated! https://github.com/joyent/node/pull/2538
20:15:21  <indutny>isaacs: oops, runtime error. but I'll fix it, don't mind of it
20:16:15  <indutny>fixed
20:16:43  <indutny>https://github.com/indutny/node/commit/fabc966419df8f6dc578da13c1ecdc4bf3440e7c
20:16:46  <indutny>isaacs: ^
20:18:05  <indutny>brb
20:28:56  * mjr_joined
20:40:55  <indutny>isaacs: oh, you left :(
20:41:01  <indutny>k, tomorrow then
20:41:26  <isaacs>hi
20:41:29  <isaacs>i'm here kinda
20:42:05  <isaacs>indutny: lgtm
20:42:08  <isaacs>push to master, plz.
20:42:10  <isaacs>then you may sleep :)
20:42:24  <indutny>isaacs: ok, does doc text looks good to you?
20:42:33  <isaacs>sure
20:42:38  <indutny>I haz no good english at all
20:42:41  <indutny>:D
20:42:45  <indutny>kthanks
20:43:13  <isaacs>indutny: for querystring.parse, we should maybe think about putting sep/eq into the options object
20:43:23  <isaacs>but that can come later, i guess.
20:43:36  <isaacs>if anyone cares :)
20:43:53  <indutny>isaacs: yeah
20:44:03  <indutny>isaacs: I thought noone will ever use it
20:44:08  <isaacs>yeah
20:44:08  <indutny>or only in rare situation
20:44:13  <isaacs>but same with sep/eq
20:44:18  <indutny>so preserving old API is more vluable
20:44:21  <isaacs>may as well just pass in parse(string, options)
20:44:28  <indutny>yeah, prob
20:44:36  <isaacs>minor detail
20:44:37  <isaacs>meh
20:44:38  <indutny>but in current form , it's simplier to merge it ito v0.6
20:44:41  <indutny>s/ito/into
20:44:42  <isaacs>yeah
20:44:46  <isaacs>agreed.
20:45:37  <CIA-115>node: Fedor Indutny master * r8a98c2f / (5 files in 3 dirs): http, querystring: added limits to prevent DoS - http://git.io/4ufUnA
20:46:09  <indutny>done :)
20:48:26  * indutnychanged nick to indutny_sleeping
20:48:31  * indutny_sleepingis going to sleep now
20:48:32  <mmalecki>night indutny_sleeping!
20:48:33  <indutny_sleeping>ttyl
20:48:37  <indutny_sleeping>mmalecki: night
20:48:54  <mmalecki>just wanted to nitpick about using past simple in git commit msg ;)
20:49:46  <indutny_sleeping>:)
20:49:51  <indutny_sleeping>kk, learning learning
20:50:02  * indutny_sleepingis finally away...
20:50:08  <mmalecki>indutny_sleeping: good resource http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
20:50:16  <mmalecki>but yeah, do some sleep, I heard it's good
20:57:10  * travis-cijoined
20:57:10  <travis-ci>[travis-ci] joyent/node#239 (master - 8a98c2f : Fedor Indutny): The build is still failing.
20:57:10  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/93465d3...8a98c2f
20:57:10  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/527715
20:57:10  * travis-cipart
21:01:12  * AndreasMadsenjoined
21:06:26  * mralephquit (Quit: Leaving.)
21:06:39  <indutny_sleeping>mmalecki: thanks, I know it. just tired and want to sleep :)
21:07:32  <indutny_sleeping>mmalecki: being fresh is espcially imporant when you're writing on foreign language
21:21:28  * pieternjoined
21:26:23  * brsonjoined
22:01:41  * sh1mmerquit (Read error: Connection reset by peer)
22:02:07  * sh1mmerjoined
22:02:42  * sh1mmerquit (Read error: Connection reset by peer)
22:04:15  * sh1mmerjoined
22:05:37  * txdv_quit (Read error: Connection reset by peer)
22:11:25  * txdvjoined
22:14:01  * AndreasMadsenquit (Remote host closed the connection)
22:27:36  * mikealquit (Quit: Leaving.)
22:35:55  * pieternquit (Quit: pietern)
22:43:48  * ErikCorry_quit (Quit: Page closed)
23:09:45  * mikealjoined
23:21:26  * paddybyersquit (Quit: paddybyers)
23:31:03  * `3rdEdenquit (Quit: Zzzzz)
23:51:28  * txdvquit (Read error: Operation timed out)