00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:07:51  * toothrotjoined
00:10:07  <trevnorris>tjfontaine: just checks it can spawn an empty file with undefined and empty object.
00:10:15  <trevnorris>the UNKNOWN error is the strange part.
00:13:20  <tjfontaine>that's probably from libuv
00:13:32  <tjfontaine>or could be anyway
00:15:28  * hayesquit (Ping timeout: 256 seconds)
00:15:47  * hayesjoined
00:24:21  <srl295>jgi: hi.. going to make some changes, commit, push re pr#8719 ok?
00:24:28  <jgi>srl295, tjfontaine: regarding OS X and Windows installers with full ICU data included (but not embedded in the binary), the way we set the ICU_DATA_DIR now at built time means that we have to put the file in a known absolute path, like AppData on Windows or /usr/(local)?/share on OS X. Am I right or am I missing something?
00:24:50  <trevnorris>tjfontaine: oh, I meant, why UNKNOWN. I'd have expected some useful error...
00:25:08  <jgi>srl295: sounds good!
00:25:11  <srl295>jgi: that sounds right
00:25:13  <srl295>re: path
00:25:31  <tjfontaine>jgi, srl295: well... does icu support a relative directory path?
00:25:39  * jreyno40quit (Quit: jreyno40)
00:26:15  <srl295>tjfontaine: jgi: the path is just passed to mmap() - so it can be relative to cwd or absolute.
00:26:21  <tjfontaine>I guess the question more specifically is, when during icu initialization does it inspect that path, and would that be before any process has been .chdir()'d
00:27:06  <tjfontaine>if that path is specified before process object is created and we are in javascript, let's leave it as relative
00:27:49  <tjfontaine>oh well, I guess $CWD is not what I want
00:27:51  <tjfontaine>hrm
00:28:21  <tjfontaine>blargh... :)
00:28:24  <jgi>:)
00:28:40  <srl295>tjfontaine: it would be the first time v8 calls something in ICU. Node could make that happen early, but there's a slight startup cost even if Intl is never used
00:29:00  <tjfontaine>so, what I'd like is for us to keep the node executable in its by default portable nature
00:29:02  <srl295>tjfontaine: Yes. All of this is why we usually link the data at compile time, as ugly as that otherwise is
00:29:26  <srl295>then ld.so, say, gets to hunt for it
00:31:25  <tjfontaine>blech, an absolute path here is more what I was thinking, as far as ICU_DATA_DIR=$PREFIX/share/node/icu
00:31:52  <tjfontaine>but that doesn't keep node portable, and may cause for odd breakage for people using prebuilt binaries in odd paths
00:32:08  <jgi>tjfontaine: yes, the problem is more that on Windows, the installation location can be changed at installation time, so we’d need either a relative path or an absolute path that is “safe”, like AppData
00:32:23  <tjfontaine>technically the same could be done wiht the osx installer
00:32:29  <jgi>tjfontaine: exactly
00:32:32  <tjfontaine>and also for people using th ebinary tarballs
00:32:56  <srl295>tjfontaine: Right now node doesn't otherwise have a "node.d" dir in the sense of a "node homedir", I think
00:33:08  <jgi>tjfontaine: yes, although for binary tarballs I thought we wanted to let users load the full ICU data themselves by using either the environement variable or the —icu-data-dir command line switch
00:33:35  <tjfontaine>the environment variable is a fallback configuration swithc really
00:33:42  <tjfontaine>something hosting providers could provide
00:34:31  <tjfontaine>srl295: so tell me more about the shared library approach
00:35:52  <tjfontaine>node could dlopen(join(dirname(basename(execPath)), '..', 'share', 'node', 'icu'))
00:36:53  <srl295>tjfontaine: OK so if you download ICU binaries, the default case has libicuuc.so, libicui18n.so, libicudata.so. The latter just has one symbol in it, containing the data. That's about it. The platform has to take care of finding the shared library.
00:36:58  <jgi>tjfontaine, srl295: when ICU loads the data from a relative path, does it load it relative to the exec path?
00:37:14  <tjfontaine>jgi: cwd almost certainly
00:37:21  <srl295>tjfontaine: in Node's case, everything is staticly bound, so there's no shared libraries involved.
00:37:24  <srl295>jgi: cwd.
00:37:29  <jgi>ok
00:37:31  <tjfontaine>jgi: which is decidedly not predictable
00:37:45  <tjfontaine>srl295: for the default case, many people do use shared versions
00:37:58  <jgi>tjfontaine: yes, that’s what I assumed from the start, but then I thought I’d ask anyway :)
00:38:19  <srl295>tjfontaine: yes, it's managed by rpm, pkgadd, apt..etc
00:38:21  <tjfontaine>srl295: can you join the call tomorrow morning at 9AM PST?
00:39:22  <srl295>tjfontaine: possibly
00:39:50  <tjfontaine>just like to talk this all out in real time
00:40:05  * dap_1quit (Quit: Leaving.)
00:42:39  <jgi>tjfontaine, srl295: so far we have 3 solutions: 1) linking the binary with full ICU data, 2) Storing the full ICU data in a location to which we can always refer with an absolute path (e.g AppData on Windows) 3) Load the ICU data “manually” from Node relative to the exec path. Does that summarize our discussion correctly?
00:43:13  <srl295>jgi: I don't know of any code today that does #3
00:44:28  <srl295>but, the u_setDataDirectory() call can be made at any point prior to load (that's what the --icu-data-dir= node parameter does). It could be exposed to js calls as well if need be, if that helps
00:46:07  * quijotejoined
00:50:24  <srl295>tjfontaine: is the 9am call an existing call? trying to figure out scheduling here.. otherwise just after 10?
00:50:42  * quijotequit (Ping timeout: 244 seconds)
00:50:47  <tjfontaine>srl295: the call was yes previously scheduled
00:51:13  <srl295>tjfontaine: ok. I should be able to attend. can you send me info at srl295 at gmail or /msg?
00:51:34  <tjfontaine>yup
01:00:09  <trevnorris>off for the night.
01:00:24  <trevnorris>tjfontaine: what's left on the merge?
01:00:37  <trevnorris>i'm not sure how to debug those failures.
01:04:04  <jgi>tjfontaine, trevnorris, chrisdickinson,cjihrig: looking at https://github.com/joyent/node/issues/8894 right now
01:04:33  <jgi>might be because of root certs that have been updated
01:04:56  <trevnorris>that was my first thought.
01:05:23  <jgi>yep, confirmed
01:10:18  <jgi>indutny: ping
01:14:01  <indutny>jgi: pong
01:14:30  <jgi>indutny: I’m investigating this issue: https://github.com/joyent/node/issues/8894#issuecomment-67426636
01:15:45  * avalanche123quit (Remote host closed the connection)
01:17:00  <indutny>jgi: this is very odd
01:17:06  <indutny>jgi: I see this cert in our chain
01:17:12  <jgi>indutny: yep
01:17:43  * avalanche123joined
01:18:08  <indutny>jgi: seems to work with latest v0.10
01:19:35  * avalanche123quit (Remote host closed the connection)
01:19:35  <jgi>indutny: it doesn’t work for me
01:20:10  * mswanjoined
01:20:55  <indutny>jgiah
01:20:57  <indutny>wait a sec
01:21:20  <indutny>may be I was using wrong branch
01:23:14  * chris_99quit (Quit: Ex-Chat)
01:23:29  <jgi>indutny: using the builtin https module seems to work fine though
01:23:54  <srl295>jgi: getting readyto commit a round of review responses
01:24:56  <indutny>jgi: aaaah
01:25:00  <indutny>jgi: it follows redirect
01:25:10  <indutny>jgi: to bbuseruploads.s3.amazonaws.com
01:26:51  <jgi>srl295: ok
01:27:03  <srl295>jgi: addressed everything except vcbuild.bat https://github.com/joyent/node/pull/8719#discussion_r22018717
01:27:18  * Fishrock123quit (Quit: Leaving...)
01:28:43  <indutny>jgi: my guess would be
01:28:47  <indutny>jgi: that they are not sending intermediate cert
01:29:30  <indutny>checking it out
01:30:07  <indutny>hm...
01:30:20  <jgi>srl295: I agree with you regarding my comment on vcbuild.bat
01:31:18  * GTLjoined
01:31:24  <srl295>jgi: ok
01:34:06  <srl295>jgi: pushed, f758028 - think I have addressed all comments.
01:35:08  * avalanche123joined
01:35:11  <jgi>indutny: it seems that root certs update deleted *.s3.amazonaws.com’s root CA’s cert right ?
01:35:26  <jgi>indutny: the “Verisign Class 3 Public Primary Certification Authority” cert
01:37:40  <indutny>jgi: this should be fine
01:37:44  <indutny>jgi: server sends it
01:37:50  <jgi>indutny: ok
01:44:53  * avalanche123quit (Remote host closed the connection)
01:47:03  * quijotejoined
01:47:32  * jreyno40_joined
01:48:55  * GTLquit (Ping timeout: 246 seconds)
01:49:22  * jreyno40_quit (Client Quit)
01:51:55  <indutny>jgi: brb, breakfast
01:52:02  * quijotequit (Ping timeout: 264 seconds)
01:52:11  * jreyno40_joined
01:53:29  * jreyno40_quit (Client Quit)
01:54:21  * cofzquit (Quit: cofz)
01:56:29  * abraxas_joined
01:57:44  <srl295>jgi: out-ish. tjfontaine talk to you tomorrow, may check in later
01:57:52  <jgi>srl295: thank you!
01:58:14  <srl295>thank you.
02:04:45  * petka_quit (Quit: Connection closed for inactivity)
02:05:39  * avalanche123joined
02:09:17  * jreyno40joined
02:10:18  <jgi>indutny: if I add back the /* Verisign Class 3 Public Primary Certification Authority */ cert, I cannot reproduce the issue
02:11:18  * avalanche123quit (Remote host closed the connection)
02:11:24  * avalanche123joined
02:12:52  * Orbordejoined
02:13:18  <Orborde>If I use uv_queue_work, does the uv_work_t need to remain undeleted after uv_queue_work is called?
02:13:21  <Orborde>Or can I free it?
02:20:42  * tjkrusinskiquit (Ping timeout: 245 seconds)
02:20:49  * Ralithquit (Ping timeout: 272 seconds)
02:22:11  * avalanche123quit (Remote host closed the connection)
02:24:29  <jgi>indutny, tjfontaine: I’m taking off now, I’ll reconnect later. I guess we may need to do another release, or at least to communicate about the issue.
02:28:19  * jgiquit (Quit: jgi)
02:30:47  * avalanche123joined
02:31:48  <Orborde>Just posted a mailing list thread covering this in more detail: https://groups.google.com/forum/#!topic/libuv/MBl46Ofe2Is
02:37:19  * iarnaquit (Remote host closed the connection)
02:42:41  * iarnajoined
02:43:28  * avalanche123quit (Remote host closed the connection)
02:45:07  * Ralithjoined
02:45:27  * iarnaquit (Read error: Connection reset by peer)
02:45:57  * iarnajoined
02:47:40  * quijotejoined
02:52:28  * quijotequit (Ping timeout: 255 seconds)
02:54:29  * tjkrusinskijoined
03:10:36  * brsonquit (Quit: leaving)
03:37:23  * a_lequit (Remote host closed the connection)
03:38:04  * a_lejoined
03:40:50  * a_lequit (Read error: Connection reset by peer)
03:41:25  * a_lejoined
03:43:47  * AvianFluquit (Ping timeout: 244 seconds)
03:43:53  * avalanche123joined
03:48:26  * avalanche123quit (Ping timeout: 244 seconds)
03:48:33  * quijotejoined
03:50:49  * Left_Turnquit (Remote host closed the connection)
03:52:54  * quijotequit (Ping timeout: 250 seconds)
03:57:42  <cjihrig>trevnorris: i'm still only seeing the one tls failure when running the merge-review2 branch. ran locally on OS X and on a DO x86_64 linux box
04:06:58  <indutny>cjihrig: it is still here
04:07:02  <indutny>cjihrig: I haven't fixed it yet
04:08:00  <cjihrig>indutny: yea. we're expecting to see that right now. however, there are other unexpected failures on jenkins - http://jenkins.nodejs.org/job/node-review-unix/DESTCPU=x64,label=linux/329/tapResults/
04:08:22  <cjihrig>indutny: but trevnorris mentioned they weren't happening on his machine. they're not showing up on two boxes for me
04:09:12  <indutny>cjihrig: I see only one crypto issue
04:09:17  <indutny>s/crypto/tls/g
04:09:27  <indutny>cjihrig: test-tls-honorcipherorder-secureOptions.js
04:09:42  <indutny>and this is expected
04:10:27  <cjihrig>indutny: ok. not sure what jenkins is smoking then :-)
04:10:39  <indutny>cjihrig: http://jenkins.nodejs.org/job/node-review-unix/DESTCPU=x64,label=linux/329/tapTestReport/
04:10:46  <indutny>only one tls test failure here as well
04:10:52  <indutny>or am I wrong?
04:11:24  <cjihrig>indutny: i'm seeing other errors there. for example 49
04:11:46  <cjihrig>215
04:12:01  <cjihrig>419
04:12:24  <cjihrig>574
04:12:46  <cjihrig>670 is the expected failure
04:14:10  <indutny>cjihrig: this is not a tls, right?
04:14:27  <indutny>I think I'm on wrong page here :)
04:14:47  <cjihrig>i think so too
04:17:19  <cjihrig>indutny: if you want context on what i'm talking about, here is the spot in the logs - http://logs.libuv.org/libuv/2014-12-17#23:18:28.587
04:17:59  <cjihrig>i'm going to bed :-)
04:18:14  <indutny>ttyl!
04:18:19  <cjihrig>night
04:18:24  * inolenquit (Ping timeout: 244 seconds)
04:49:21  * quijotejoined
04:53:37  * quijotequit (Ping timeout: 240 seconds)
05:16:24  <srl295>Jgi tjfontaine trevnorris: ok I see the news about 0.12 RC tomorrow, yay!
05:16:52  <srl295>https://twitter.com/nodejs/status/545349270241435648
05:19:40  * jgijoined
05:22:45  <indutny>jgi: it seems that amazon is sending wrong cert chain
05:22:54  <indutny>and OpenSSL fails to interpret it
05:23:00  <indutny>I'm still investigating
05:24:34  <jgi>indutny: ok, what does it send and what _should_ it send?
05:24:45  <indutny>jgi: https://www.ssllabs.com/ssltest/analyze.html?d=bbuseruploads.s3.amazonaws.com&s=54.231.244.9
05:26:22  <indutny>ha!
05:26:23  <indutny>nice
05:26:25  <indutny>there are two possible chains
05:26:31  <indutny>they have two certificates with the same hash
05:26:37  <indutny>one leads to 1024bit CA
05:26:40  <indutny>another to 2048bit CA
05:26:48  <indutny>thank you VeriSign :)
05:27:02  <indutny>jgi: AWS is including old certificate chain
05:27:07  <indutny>jgi: with 1024bit CA
05:28:40  <jgi>indutny: interesting
05:29:10  * cofzjoined
05:29:12  * stagasjoined
05:29:12  <indutny>I have a solution
05:29:18  <indutny>but not sure about security
05:29:19  <indutny>it implies patching openssl
05:30:10  <indutny>it seems to be fixing the problem though
05:30:11  <indutny>basically
05:30:18  <indutny>the algorithm is following right now
05:30:19  <indutny>1. Take the last cert
05:30:23  <indutny>erm
05:30:26  <indutny>1. Pop the last cert
05:30:37  <indutny>in chain
05:30:43  <indutny>2. If it is self-signed - break
05:30:51  <indutny>3. Find it's issuer
05:30:54  <indutny>4. Not found - break
05:31:04  <indutny>5. Found - continue with the issue cert, using step 1
05:31:10  <indutny>but ideally
05:31:18  <indutny>it could do a continue in 4 step
05:31:33  <indutny>thus skipping the cert without issuer in the bas
05:31:38  <indutny>chain*
05:34:23  <jgi>indutny: I’m not sure I understand what you mean. In the case of bbuseruploads.s3.amazonaws.com, you’re saying that openssl examines the intermediate CA’s cert, can’t find the issuer (the root CA) in the trusted root CAs and thus breaks, but it should continue and find the root CA’s cert at the root of the chain?
05:35:26  <indutny>it should skip that cert in a chain
05:35:33  <indutny>I'm working on patch
05:35:37  <indutny>will show you it in a bit
05:35:49  <jgi>indutny: also, why in the case of a connection initiated by Node.js, the root certificate that is sent by the server uses a 1024 bits key, and why the one sent to browsers uses a 2048 bits key?
05:36:25  <indutny>jgi: because the browsers are using NSS
05:36:27  <indutny>and it handles it
05:36:34  <indutny>i.e. it skips the certs that are sent by server
05:36:42  <indutny>and is using it's own cert storage
05:36:46  <jgi>indutny: ok
05:36:52  <indutny>jgi: technically
05:36:54  <indutny>it is AWS to blame
05:37:06  <indutny>the issue is here for 3 months
05:37:09  <indutny>and they are not doing anything
05:37:12  <jgi>indutny: ok, now I understand your initial explanation better
05:37:36  <indutny>https://gist.github.com/indutny/554cb6637dadda84460a
05:37:41  <indutny>jgi: this is the patch ^
05:37:54  <indutny>it should probably free the cert, though
05:38:22  <indutny>updated
05:39:10  <indutny>sorry, updated again
05:39:14  <indutny>made a stupid mistake
05:39:24  <jgi>indutny: hehe no problem :)
05:39:30  <indutny>ok, it works fine now
05:40:33  * tjkrusinskiquit (Ping timeout: 244 seconds)
05:40:41  <indutny>nah, it is incorrect
05:40:45  <indutny>need to move looping below
05:41:30  <srl295>Jgi: fyi I'm now aware of the rc announced for tomorrow -let me know as you need anything
05:41:33  <indutny>btw, I have an awesome idea of how it could be done in node.js
05:42:53  <jgi>srl295: sure, I think regarding ICU we will need to land https://github.com/joyent/node/pull/8719 before 0.12, so maybe before 0.11.15
05:43:32  <indutny>yay
05:43:54  <jgi>srl295: but like I said, I’m optimistic we can merge that as it is now, I just need to take a final look at your updated changes, and then check with trevnorris and tjfontaine that it corresponds to what they were looking for
05:44:31  <srl295>Jgi ok. Think
05:44:45  <srl295>Sorry.
05:45:38  <srl295>Makes sense. I'll check in in the ear ly am
05:48:47  <jgi>srl295: ok thank you again
05:49:56  * quijotejoined
05:50:45  <Dirkson>Hey all. I've got some 0.10.25 code which I begin to suspect is having some libuv-centric problems. I'd like to upgrade to libuv 0.11... Er... I guess 1.0 now! Is that process likely to be difficult for me? Are there any guides on it?
05:50:52  <srl295>Jgi no problem. Btw do you know if there's a smartos package for icu? Should retest it when I fix the XOPEN thing upstream
05:51:20  <srl295>.. And see if it has any patches tjat need to go into icu
05:51:42  <jgi>srl295: I am not sure there’s a package for that, let me check
05:52:12  <jgi>srl295: icu-51.2 Robust and full-featured Unicode services
05:52:14  <jgi>:)
05:55:05  * quijotequit (Ping timeout: 264 seconds)
05:55:47  * bajtosjoined
05:56:24  <srl295>Jgi thanks. Maybe it was a regression we saw.
05:57:03  <srl295>Ran into it with a Solaris Gcc box in our lab. Wasn't in the continuous build oops.
05:57:21  <srl295>Anyways thanks , I'll look into that and add it to my list of downstreams.
05:57:53  <jgi>srl295: great thanks!
05:58:33  <srl295>Np
05:58:39  <Dirkson>Also, were many bugs fixed between 0.10.28 and 1.0?
05:59:01  <Dirkson>I'm having some weird signal crashes that I'm having a really hard time pinning down.
05:59:26  * avalanche123joined
06:01:52  <srl295>Sorry for the aside, dirkson- this is actually the uv channel !
06:02:50  <Dirkson>srl295: Y-yes? Good?
06:03:25  <jgi>srl295: there was actually already a patch that I believe would have fixed our issue: https://github.com/joyent/pkgsrc/blob/trunk/textproc/icu/patches/patch-common_uposixdefs.h
06:03:33  <jgi>srl295: somewhat I didn’t find it the first time :(
06:03:47  <jgi>somehow
06:03:51  <Dirkson>srl295: https://github.com/libuv/libuv - This, yes?
06:04:54  <srl295>Dirkson yes
06:05:11  <srl295>Jgi aha- that will do it.
06:05:15  * jreyno40quit (Quit: jreyno40)
06:14:43  * avalanche123quit (Remote host closed the connection)
06:14:56  * mswanquit (Quit: Page closed)
06:22:36  <srl295>Jgi indutny dirkson: g'night
06:22:44  <jgi>srl295: you too!
06:22:52  <jgi>srl295: can you make it for tomorrow’s meeting?
06:23:02  <srl295>Yes. Details?
06:23:46  <indutny>jgi: so
06:23:53  <indutny>jgi: what are your thoughts on that OpenSSL patch?
06:24:00  <indutny>I have submitted it
06:24:03  <indutny>but I don
06:24:08  <jgi>indutny: submitted upstream?
06:24:13  <indutny>I don't really know if we should expect reply
06:24:15  <indutny>jgi: yep
06:24:20  <indutny>they are not really responsive
06:24:22  <jgi>indutny: thank you!
06:26:15  <jgi>indutny: I’m not familiar with the OpenSSL codebase, and thus I would need to take a longer look at it to have a better opinion about the technical details of the patch, but the concept of doing something similar to NSS makes sense
06:26:23  <indutny>ok
06:26:40  <jgi>indutny: however I don’t feel comfortable with releasing a new version with a change in OpenSSL without testing it thoroughly first
06:26:47  <indutny>yeah, indeed
06:26:56  <indutny>the tests are passing
06:26:59  <indutny>in both openssl and node
06:27:25  * tjkrusinskijoined
06:28:09  <jgi>indutny: that’s good, but I would rather perform tests similar to what has been done by Mozilla and/or Fedora when they decided to not trust 1024 bits certs anymore
06:30:20  <srl295>jgi: should b e able to make the meeting, i'll ping here for details.
06:30:28  <jgi>srl295: awesome, thanks!
06:31:25  <jgi>indutny: something similar to the “compatibility test run of 200,000+ SSL-enabled sites” mentioned here: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c2
06:32:00  <indutny>jgi: good luck with that :)
06:32:31  <jgi>indutny: we could contact them to know how they did that
06:36:43  <jgi>indutny: in the meantime, would specifying additional trusted CA certificates in the TLS options (it’s forwarded by the request module) be an acceptable workaround?
06:37:45  <jgi>indutny: we could provide a link to the old 1024 certificate and document why it’s unsafe, but people could use it if they have issues connecting to s3.amazonaws.com
06:37:56  <indutny>jgi: it should be
06:38:00  <indutny>also
06:38:06  <indutny>we may ask people to submit bug ticket
06:38:07  <indutny>to AWS
06:38:18  <indutny>to stop sending insecure cert chain
06:38:20  <jgi>indutny: yes, that sounds like a good idea
06:38:46  <jgi>indutny: so to summarize the proposed plan:
06:39:13  <jgi>1) document the workaround of specifying this additional CA cert for users who want to connect to s3.amazonawz.com
06:39:24  <jgi>2) test your OpenSSL change thoroughly
06:40:08  <jgi>3) do another release when we’re confident that your change is robust and doesn’t break
06:40:30  <jgi>indutny: how does that sound?
06:40:38  <indutny>you forgot
06:40:44  <indutny>4) Ask users to submit bug ticket to AWS
06:40:52  <jgi>indutny: indeed sorry :)
06:41:02  <indutny>np
06:41:05  <indutny>otherwise lgtm
06:41:10  <jgi>indutny: that could actually be merged into 1)
06:41:30  <jgi>indutny: but that’s a technical detail
06:41:52  <indutny>ok
06:42:47  <jgi>indutny: alright, then I suggest that we communicate our current intentions on this GitHub issue, and check tomorrow morning with the rest of the team if they agree with this plan
06:43:01  <indutny>ok
06:43:11  <indutny>we need to stress out that 1024 bit CA certs is a more serious problem
06:43:19  <indutny>than failing requests to AWS
06:43:30  <indutny>latter makes connecting to AWS problematic
06:43:38  <indutny>former poses a security risk for all tls.connect() operations
06:44:08  <jgi>indutny: indeed
06:48:41  <jgi>indutny: I’m writing a response to the issue right now
06:50:57  * quijotejoined
06:53:39  * jreyno40_joined
06:55:19  <jgi>indutny: what do you think: https://gist.github.com/misterdjules/645bda5868d436bc3548?
06:55:38  * quijotequit (Ping timeout: 264 seconds)
07:00:26  <jgi>indutny: updated: https://gist.github.com/misterdjules/645bda5868d436bc3548
07:07:54  * [spoiler]joined
07:09:37  * bajtosquit (Quit: bajtos)
07:11:48  * jreyno40_part
07:13:44  * bajtosjoined
07:14:40  * bradleymeckquit (Quit: bradleymeck)
07:18:42  <jgi>indutny: posted here: https://github.com/joyent/node/issues/8894#issuecomment-67449458
07:23:49  * rmgquit (Remote host closed the connection)
07:36:13  <jgi>indutny: I have to go, thank you for investigating this SSL issue!
07:39:05  * SergeiRND1joined
07:40:15  * jgiquit (Quit: jgi)
07:41:15  * SergeiRND1quit (Client Quit)
07:46:01  * avalanche123joined
07:50:48  * avalanche123quit (Ping timeout: 250 seconds)
07:51:32  * quijotejoined
07:55:55  * quijotequit (Ping timeout: 250 seconds)
08:01:04  * jreyno40joined
08:03:16  * rendarjoined
08:04:05  * quijotejoined
08:11:13  * bajtosquit (Quit: bajtos)
08:17:11  * bajtosjoined
08:24:17  * rmgjoined
08:24:57  * inolenjoined
08:29:50  * rmgquit (Ping timeout: 264 seconds)
08:45:08  * tjkrusinskiquit (Ping timeout: 265 seconds)
08:47:57  * tjkrusinskijoined
09:07:30  * quijotequit (Ping timeout: 250 seconds)
09:35:40  * quijotejoined
09:38:42  * jreyno40part
09:39:55  * quijotequit (Ping timeout: 250 seconds)
09:42:26  * inolenquit (Ping timeout: 264 seconds)
09:46:29  * stagasquit (Ping timeout: 245 seconds)
09:55:50  * SergeiRNDjoined
10:07:15  * bajtosquit (Quit: bajtos)
10:17:00  * quijotejoined
10:17:38  * Left_Turnjoined
10:27:29  * chris_99joined
10:37:04  <txdv>here we go
10:43:14  * SergeiRNDquit (Quit: Leaving.)
10:48:28  * SergeiRNDjoined
10:52:25  * chris_99quit (Quit: Ex-Chat)
10:53:45  * cammmjoined
10:54:50  * cammmquit (Client Quit)
10:55:06  * cammmjoined
10:57:01  * abraxas_quit (Remote host closed the connection)
10:57:39  * abraxas_joined
11:02:20  * abraxas_quit (Ping timeout: 250 seconds)
11:18:14  * bajtosjoined
11:19:07  * SergeiRNDquit (Quit: Leaving.)
11:20:14  * quijotequit (Ping timeout: 245 seconds)
11:24:34  * bajtosquit (Ping timeout: 255 seconds)
11:28:21  * bajtosjoined
11:29:44  * AlexisMochajoined
11:42:59  * petka_joined
11:59:28  * SergeiRNDjoined
12:02:55  * rmgjoined
12:07:20  * rmgquit (Ping timeout: 250 seconds)
12:17:37  * quijotejoined
12:21:57  * quijotequit (Ping timeout: 245 seconds)
12:35:44  * quijotejoined
12:39:49  * quijotequit (Ping timeout: 245 seconds)
12:46:26  * abraxas_joined
12:51:24  * abraxas_quit (Ping timeout: 256 seconds)
12:52:19  * cofzquit (Quit: 0)
12:55:39  * bajtosquit (Quit: bajtos)
13:02:59  * chris_99joined
13:05:15  * iarnaquit (Read error: Connection reset by peer)
13:05:53  * iarnajoined
13:19:45  * chris_99quit (Remote host closed the connection)
13:20:48  * chris_99joined
13:28:37  * iarnaquit (Remote host closed the connection)
13:36:19  * quijotejoined
13:39:13  * lance|afkchanged nick to lanceball
13:40:39  * quijotequit (Ping timeout: 245 seconds)
14:25:27  * Fishrock123joined
14:34:17  * [spoiler]quit (Quit: Leaving)
14:35:19  * abraxas_joined
14:37:04  * quijotejoined
14:40:09  * abraxas_quit (Ping timeout: 258 seconds)
14:41:32  * quijotequit (Ping timeout: 245 seconds)
14:56:03  * AvianFlujoined
14:56:39  <AlexisMocha>tjfontaine: Jenkins is down
15:11:39  * stagasjoined
15:16:23  * SergeiRNDquit (Quit: Leaving.)
15:21:32  * lanceballchanged nick to lance|afk
15:26:36  * quijotejoined
15:39:19  * cammmquit (Quit: Nettalk6 - www.ntalk.de)
15:56:53  * avalanche123joined
16:23:55  * abraxas_joined
16:29:17  * abraxas_quit (Ping timeout: 264 seconds)
16:29:28  * iarnajoined
16:30:09  * avalanche123quit (Remote host closed the connection)
16:33:34  * iarnaquit (Ping timeout: 245 seconds)
16:33:55  * quijote_joined
16:34:13  * quijotequit (Read error: Connection reset by peer)
16:37:02  <srl295>Tjfontaine trevnorris jgi : ping
16:42:30  * avalanche123joined
16:42:35  * jgijoined
16:42:40  * tarrudajoined
16:42:46  * bajtosjoined
16:42:59  <jgi>srl295: pong
16:43:04  * tarrudachanged nick to Guest21899
16:43:14  * Guest21899quit (Client Quit)
16:44:10  <tjfontaine>AlexisMocha: ok
16:45:05  <tjfontaine>https://bluejeans.com/647321816 <-- link for meeting, srl295 jgi chrisdickinson cjihrig indutny trevnorris AlexisMocha
16:45:13  <tjfontaine>I'm going to grab some coffee I just got off another call
16:46:34  * tarruda_joined
16:46:53  <srl295>Tjfontaine jgi thanks and good morning.
16:47:05  <jgi>srl295: good morning!
16:56:27  * seishunjoined
16:58:36  * rmgjoined
17:01:51  <tjfontaine>trevnorris, indutny, chrisdickinson, AlexisMocha, srl295 -- meeting is open if you wish to join
17:01:58  <tjfontaine>(as is any other passer by)
17:08:56  * avalanche123quit (Remote host closed the connection)
17:17:02  <chrisdickinson>CA changes appear to be on the mozilla side: https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/
17:17:43  <chrisdickinson>well, possibly.
17:19:13  <tjfontaine>seems reasonable
17:20:58  * SergeiRNDjoined
17:21:22  * avalanche123joined
17:23:35  * lance|afkchanged nick to lanceball
17:23:35  * avalanche123quit (Remote host closed the connection)
17:38:43  * c4milojoined
17:38:45  * c4miloquit (Remote host closed the connection)
17:39:50  * c4milojoined
17:41:19  * bajtosquit (Quit: bajtos)
17:50:02  * tarruda_quit (Ping timeout: 256 seconds)
17:51:03  <MI6>joyent/node: Chris Dickinson v0.12 * 9158666 : stream: switch _writableState.buffer to queue - http://git.io/R8aOjg
17:55:24  <srl295>thanks!
17:55:56  <chrisdickinson>tjfontaine: so, question 1: does ben have a machine?
17:55:59  <chrisdickinson>s/machine/time machine/g
17:56:04  <chrisdickinson>sorry, accidentally a word, there.
17:56:39  <chrisdickinson>the only commit touching `src/node_root_certs.h` between the v0.10.33 and v0.10.34 tags is dated 2013-11-09
17:56:58  <chrisdickinson>but the commit message contains "Update tools/certdata.txt to [0] (last updated on 2014-11-14)"
17:57:22  <chrisdickinson>(I imagine the date could have gotten mangled somehow in a merge
17:57:26  <chrisdickinson>)
17:58:54  <tjfontaine>chrisdickinson: you can make git believe anything :
17:58:55  <tjfontaine>:)
17:59:01  <chrisdickinson>(looking at the output of `git log v0.10.33...v0.10.34 src/node_root_certs.h`)
17:59:03  <tjfontaine>but he authored that commit last year
17:59:32  <tjfontaine>f9456a2d3657145878dfcae52af1defc1e22e3bb is what we're talking about, right?
17:59:40  <chrisdickinson>yep
18:00:04  <chrisdickinson>(re: git believing anything: yep, it's just odd that the date ended up in 2013 but the message is 2014 -- was it amended?)
18:00:49  <srl295>tjfontaine: actually u_setDataDirectory isn't mutexed but officially not threadsafe. So, calling it from main() is the right path for now.
18:01:12  <tjfontaine>chrisdickinson: almost certainly, would need to check wiht whomever actually committed it, I presume it was fedor or trevor
18:01:45  <tjfontaine>srl295: right, makes sense, I can't imagine wanting to do it in any other path, and node in this context (for the short to medium term) will only ever be single threaded
18:02:07  <chrisdickinson>I think the root cause (har har) is that mozilla got rid of their 1024-bit certs
18:02:25  * piscisaureusjoined
18:04:27  * davijoined
18:04:40  * brsonjoined
18:05:03  <tjfontaine>chrisdickinson: seems quite likely, we could optionally try and convince openssl to take the alternate path for the aws case, or we can manually merge back in the 1024 bit certs
18:05:33  <tjfontaine>chrisdickinson: the latter is the easiest short term solution, we would just want to verify that none of those certificates have been revoked before manually adding them back in
18:06:20  <chrisdickinson>cool
18:07:28  <tjfontaine>Caused by: java.lang.OutOfMemoryError: Java heap space
18:07:28  <tjfontaine>Dec 18, 2014 5:38:15 PM hudson.triggers.SafeTimerTask run
18:07:28  <tjfontaine>SEVERE: Timer task com.cloudbees.jenkins.Cleaner@f9c6c3 failed
18:07:29  <tjfontaine>java.lang.OutOfMemoryError: Java heap space
18:07:31  <tjfontaine>gawd
18:07:36  <tjfontaine>I hate java
18:08:26  <tjfontaine>why wouldn't it die if it couldn't recover from taht.
18:11:17  <jgi>trevnorris: ping
18:11:22  * bajtosjoined
18:13:09  * abraxas_joined
18:17:24  * abraxas_quit (Ping timeout: 250 seconds)
18:20:47  * dap_joined
18:21:19  <srl295>tjfontaine: Hopefully we can count on the invariant of main() starting out as a single thread :]
18:26:33  * iarnajoined
18:27:18  * inolenjoined
18:32:03  * daviquit (Ping timeout: 250 seconds)
18:32:50  * avalanche123joined
18:35:56  * AlexisMochaquit (Ping timeout: 256 seconds)
18:36:38  * SergeiRND1joined
18:37:21  <chrisdickinson>for a first stab, I'm going to try re-adding just the CA certs listed here: https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/
18:38:17  * SergeiRNDquit (Ping timeout: 264 seconds)
18:39:26  * SergeiRNDjoined
18:41:17  * SergeiRND1quit (Ping timeout: 264 seconds)
18:42:16  * tarruda_joined
18:45:36  * chris_99quit (Remote host closed the connection)
18:46:00  * tjkrusinskiquit (Ping timeout: 250 seconds)
18:49:05  * tarruda_quit (Ping timeout: 264 seconds)
18:50:41  * SergeiRND1joined
18:50:43  * SergeiRND1quit (Read error: Connection reset by peer)
18:50:56  * SergeiRND1joined
18:51:29  * SergeiRNDquit (Ping timeout: 264 seconds)
18:55:24  * avalanche123quit (Remote host closed the connection)
18:55:38  * SergeiRND1quit (Client Quit)
18:55:49  * avalanche123joined
19:00:34  <tjfontaine>chrisdickinson: sounds good
19:01:45  <jgi>tjfontaine, chrisdickinson,srl295: afk for about 25 minutes (heading to the office), I still haven’t found a repro for https://github.com/joyent/node/issues/8897, but I’ll keep you updated
19:01:52  <tjfontaine>jgi: thanks
19:01:55  * tjkrusinskijoined
19:02:08  <jgi>tjfontaine, chrisdickinson, srl295: also, there seem to be an issue with another timer change: https://github.com/joyent/node/issues/8900
19:02:34  <tjfontaine>ya, I was going to make the same guess
19:02:40  <tjfontaine>as far as what change that broke it
19:02:47  <jgi>tjfontaine, chrisdickinson: I haven’t looked into it yet, I just confirmed the bug by reproducing the issue with the change, and not reproducing it without it
19:03:28  <tjfontaine>ya, their claim seems likely to be the cause, at least we can write a test to cover it
19:04:33  * sblomjoined
19:06:41  <jgi>tjfontaine: yes, we can write a test for https://github.com/joyent/node/issues/8900, but are you saying that the two are related?
19:07:14  * tjkrusinskiquit (Ping timeout: 250 seconds)
19:09:01  * sblomquit (Read error: Connection reset by peer)
19:09:15  <tjfontaine>no they are not related
19:09:24  <tjfontaine>at least I don't expect them to be
19:11:04  <chrisdickinson>tjfontaine: best way to check if a cert has been revoked?
19:11:17  * jgiquit (Quit: jgi)
19:11:54  <tjfontaine>chrisdickinson: the issuer should list it, there are websites that track the information, for each finger print of the certs we have, there's a service out there that will check it
19:13:09  * tjkrusinskijoined
19:15:19  * bajtosquit (Quit: bajtos)
19:21:26  * AlexisMochajoined
19:27:35  * bradleymeckjoined
19:33:37  * quijote_quit (Read error: Connection reset by peer)
19:33:55  * quijotejoined
19:38:26  * quijotequit (Ping timeout: 250 seconds)
19:40:49  * jgijoined
19:40:58  <jgi>tjfontaine: ok, that was my understanding too
19:44:50  <chrisdickinson>secom is hard to verify :\
19:57:26  <chrisdickinson>tjfontaine: https://github.com/joyent/node/pull/8904
19:58:30  * sblomjoined
19:58:42  <tjfontaine>chrisdickinson: I need to look more closely, but first glance it looks right to me
19:58:56  <chrisdickinson>there's one commented out CA that I couldn't verify
19:59:16  <chrisdickinson>(the SECOM valicert class 1 ca)
19:59:51  <tjfontaine>chrisdickinson: want to add a comment about that
20:00:04  <tjfontaine>I'm fine with that though
20:00:43  * piscisaureusquit (Ping timeout: 255 seconds)
20:01:53  * quijotejoined
20:02:04  * abraxas_joined
20:05:37  * srl295is inflating ICU's download counts by a very small percentage with all of these tests
20:06:20  * chris_99joined
20:06:31  * quijotequit (Ping timeout: 250 seconds)
20:06:32  * abraxas_quit (Ping timeout: 245 seconds)
20:14:11  <srl295>jgi: tjfontaine: going to file a PR myself on the --download change, then look at the execpath
20:14:18  <srl295>^against myself
20:14:25  <jgi>srl295: alright!
20:16:36  * brsonquit (Quit: leaving)
20:16:38  * AvianFluquit (Ping timeout: 264 seconds)
20:16:50  * brsonjoined
20:18:57  * brsonquit (Client Quit)
20:19:12  * brsonjoined
20:25:36  * brsonquit (Ping timeout: 244 seconds)
20:26:13  <jgi>chrisdickinson: if you have some time, I wouldn’t mind having another pair of eyes looking at this issue: https://github.com/joyent/node/issues/8897
20:26:31  <jgi>chrisdickinson: I haven’t been able to reproduce it yet
20:26:52  <chrisdickinson>will do!
20:27:41  <jgi>chrisdickinson: thanks!
20:27:49  <jgi>afk for a bit
20:32:13  <srl295>jgi: https://github.com/srl295/node/pull/21
20:35:37  <srl295>tjfontaine: jgi: https://github.com/srl295/node/pull/21 - the --download option. I will merge it into https://github.com/joyent/node/pull/8719 when it looks good
20:36:14  * brsonjoined
20:38:01  * avalanche123quit (Remote host closed the connection)
20:38:11  * jgiquit (Quit: jgi)
20:41:19  * avalanche123joined
20:50:58  <srl295>tjfontaine: jgi: trevnorris: I'm looking at node.cc . right now I call InitializeICUDirectory from Init(). exec_path is calcualted in SetupProcessObject which is called from CreateEnvironment which is called after Init
20:52:58  <srl295>tjfontaine: jgi: trevnorris: .. and specifically: Init(), then V8::initialize(), then CreateEnvironment(). Questoin: would it be possible to call uv_exepath() much earlier, such as from Init? That way we avoid v8 possibly (though it doesn't today) calling ICU before we get to it
20:57:52  * avalanche123quit (Remote host closed the connection)
21:02:33  * quijotejoined
21:03:42  * avalanche123joined
21:05:31  * AlexisMochaquit (Ping timeout: 255 seconds)
21:07:11  * quijotequit (Ping timeout: 250 seconds)
21:07:24  <srl295>Be back
21:07:37  * jgijoined
21:11:18  * sblomquit (Read error: Connection reset by peer)
21:14:38  * tjkrusinskiquit (Ping timeout: 250 seconds)
21:15:13  <jgi>chrisdickinson, tjfontaine: someone posted a repro here: https://github.com/joyent/node/issues/8897#issuecomment-67553445
21:25:07  * tjkrusinskijoined
21:26:14  * avalanche123quit (Remote host closed the connection)
21:29:43  * tjkrusinskiquit (Ping timeout: 250 seconds)
21:36:42  <trevnorris>tjfontaine: sorry I missed. one kid is popping 3 teeth and the other is sick. when I tag teamed w/ my wife I crashed and slept through my meeting alarm. sorry about that. I'm catching up on the irc logs now.
21:39:52  * sblomjoined
21:39:55  * creationixquit (Remote host closed the connection)
21:40:32  * creationixjoined
21:41:33  * avalanch_joined
21:43:09  <srl295>trevnorris: yup.. I'll never use the expression "teething pains" flippantly again!
21:44:25  <trevnorris>haha. yeah.
21:46:43  * tarruda_joined
21:47:43  * creationixquit (Quit: ZNC - http://znc.in)
21:48:17  * creationixjoined
21:50:15  * brsonquit (Ping timeout: 258 seconds)
21:50:49  * abraxas_joined
21:53:47  * creationixquit (Quit: ZNC - http://znc.in)
21:54:44  * creationixjoined
21:55:17  * abraxas_quit (Ping timeout: 250 seconds)
22:03:16  * quijotejoined
22:04:24  <srl295>trevnorris: let me know if you have any comments on https://github.com/srl295/node/pull/21 and also my question on uv_exepath. The exepath question came up during the call, whether we can set the icu data path relative to exepath
22:05:20  * quijote_joined
22:06:29  <srl295>ah, i'll just call uv_exepath twice for now
22:07:51  * brsonjoined
22:08:19  * quijotequit (Ping timeout: 272 seconds)
22:08:29  * lanceballchanged nick to lance|afk
22:10:13  * quijote_quit (Ping timeout: 272 seconds)
22:11:13  <trevnorris>srl295: thanks. reviewed. :)
22:12:05  <srl295>trevnorris: thanks
22:12:41  <srl295>i'll go ahead and merge it into 8719
22:14:08  * Fishrock123quit (Remote host closed the connection)
22:18:32  <trevnorris>great. thanks.
22:18:42  <srl295>merged. fyi jgi
22:25:00  <jgi>srl295, trevnorris: ok, I’ll take a look when I’m done with https://github.com/joyent/node/issues/8897#issuecomment-67553445
22:26:17  * Ralithquit (Ping timeout: 240 seconds)
22:26:29  <trevnorris>jgi: ah, interesting. thanks for pointing me to that.
22:33:29  * seishunquit (Ping timeout: 264 seconds)
22:36:24  * Fishrock123joined
22:39:01  * tjkrusinskijoined
22:40:07  * bradleymeckquit (Quit: bradleymeck)
22:46:58  * avalanch_quit (Ping timeout: 256 seconds)
22:47:25  * avalanche123joined
22:51:54  <tjfontaine>trevnorris: no problem
22:52:10  <tjfontaine>srl295: yes, there's no reason you can't either call uv_execpath earlier, or multiple times for our first iterations
22:53:47  * avalanche123quit (Ping timeout: 250 seconds)
22:54:15  * avalanche123joined
22:54:19  * Ralithjoined
22:55:43  <srl295>tjfontaine: ok. doing just that
22:58:28  <srl295>tjfontaine: jgi: https://github.com/joyent/node/pull/8719 now behaves as discussed (doesn't download automatically unless --download=all is set)
22:59:16  <tjfontaine>srl295: thank you
23:00:11  * inolen1joined
23:03:00  * inolenquit (Ping timeout: 245 seconds)
23:04:10  <jgi>tjfontaine, chrisdickinson, trevnorris: I have a candidate for a fix for this issue: github.com/joyent/node/issues/8897. I’m going to test it more, but here’s what I have so far: https://gist.github.com/misterdjules/a7b5baf352cfb892972c
23:05:34  <tjfontaine>why not just unenroll when we've found it?
23:05:50  <trevnorris>jgi: drop the forEach
23:06:00  * quijotejoined
23:06:36  <tjfontaine>ya I would like to avoid the closure there as well, should be reasonable
23:08:51  <trevnorris>I think the logic is sound. i can't recall, is the "list" global to all timers? if so, i'm trying to think of a case where even running the new list of timers could screw up future execution.
23:09:03  <trevnorris>other than that case seems like it should work.
23:10:38  * quijotequit (Ping timeout: 264 seconds)
23:11:07  <jgi>tjfontaine: unenroll would make code like this trigger the timeout only once: https://gist.github.com/misterdjules/692825714c200af4108c
23:11:41  <jgi>I agree that the closure should be avoided
23:12:05  <jgi>trevnorris: the list is global for unref timers
23:14:27  <tjfontaine>jgi: is that a reasonable pattern given how people actually interface with this?
23:14:44  <tjfontaine>jgi: is there a path where net.js actually leads to this problem?
23:15:10  <tjfontaine>is that equivalent to socket.setTimeout(100, function() { this.write(); })?
23:16:39  * Fishrock123quit (Remote host closed the connection)
23:17:35  <jgi>tjfontaine: yes, it seems that socket.setTimeout(100, function() { this.write(); }) is equivalent to that
23:17:52  <tjfontaine>ok
23:21:32  * brsonquit (Ping timeout: 256 seconds)
23:24:28  * brsonjoined
23:24:34  * Fishrock123joined
23:37:16  * Fishrock123quit (Remote host closed the connection)
23:39:41  * abraxas_joined
23:42:27  * tjkrusinskiquit (Ping timeout: 244 seconds)
23:44:15  * abraxas_quit (Ping timeout: 264 seconds)
23:44:36  <srl295>tjfontaine: trevnorris: jgi:is it possible or a good idea to use uv to check whether something is a directory at main() time?
23:48:47  * rendarquit (Quit: Leaving)
23:52:00  <jgi>srl295: something like uv_fs_stat and checking if it’s a directory?
23:52:21  <srl295>jgi: ok, but it is async, so does that work?
23:52:35  <jgi>srl295: if you don’t pass a callback, it will be synchronous
23:53:24  <tjfontaine>srl295: is it necessary to do the stat?
23:53:46  <jgi>srl295: regarding if it’s a good idea to call it in main or node::Start, I don’t know. I don’t see any call to uv_fs_* there. I don’t see any problem with that, but I would wait for tjfontaine or trevnorris’ take on that.
23:53:54  <srl295>tjfontaine: to check whether the directory exists?
23:54:38  * Fishrock123joined
23:55:32  <tjfontaine>srl295: why do you want to do the stat and is it necessary? I don't think node does any explicit stat()s currently before getting to "userland" code
23:55:43  <tjfontaine>at least that's what dtruss looks like to me currently
23:56:17  <srl295>tjfontaine: so this is to see if ${EXEPATH}/../share/node/icu/ exists
23:56:44  <tjfontaine>will icu do the stat anyway when it goes to actually initialize?
23:59:37  <srl295>tjfontaine: so.. we're back to use cases again. If this is jgi's "stub-icu" mode, we can always set the directory to ${EXEPATH}/../share/node/icu/ if the user didn't tell us otherwise