Fri, 05 Dec 2014 21:30:00 UTC - Advisory Board

We assembled the Node.js Advisory Board (AB) to listen to the community and make the necessary changes to have a unified direction for Node.js, a passionate group of developers, a vibrant ecosystem of product and service providers, and a satisfied user base. Over the last month we have made great progress on an open governance model, API standards, IP management, and transparency to ensure the project is community-driven. These efforts explicitly target helping resolve conflicts and with the goal of moving the community forward together. It is important that we understand voices of dissent and frustration and work together to build the greater ecosystem. We are committed to this goal.

Node.js remains the trusted platform that users rely on for creative projects and to drive business goals. The v0.12 release will ship shortly and the project team is already engaged in discussions about the next release.

Wed, 03 Dec 2014 18:00:00 UTC - Timothy J Fontaine

A lot has been happening in Node.js, so I wanted bring everyone up to date on where we are with regards to the advisory board, its working groups, and the release of v0.12.

The interim advisory board has met three times since its creation. You can find the minutes from the advisory board meetings here: As we have more meetings and minutes, we will announce the dates and times for those meeting and their minutes here on the blog. The next meeting is this Thursday December 4th, at 1:30PM PST. We're looking to collect as much feedback and input from as many representatives of the community as we can, so it's important that we keep everyone up to date as much as possible.

The interim advisory board has been working through a series of topics (in general meetings as well as working groups) to further hone the scope of the board, as well as define the structure that the advisory board will use to conduct its meetings. Everyone on the board wants to make sure we're being as transparent as possible, so let me describe how things operate so far. The board is using a traditional two conference call structure, a public portion that is recorded and open for anyone to join, and a private portion that is only for board members.

The public portion is meant to provide an update of what happened in the previous meeting, as well as the status of action items from the previous meeting. At the end of each public session is a open comment section, where listeners are able to ask questions and the advisory board can respond.

Following the public portion the board dials into the private conference, further discussion happens during this time around specific agenda items, working groups providing updates, and facilitating conversations about those topics. These conversations are open and frank, and their content is recorded in the minutes. Those minutes are then published a few days after the meeting in the GitHub repository, as well as on the website

There are a few working groups so far, for instance one is focused on making sure the membership of the board is representative of the community Node.js serves. While the board was initially bootstrapped with its existing membership, we want to quickly move to a model that fully represents our community. We want the board to represent the broadest spectrum of our community, that also enables the board to move swiftly and make progress.

Another working group is having a conversation about governance. This includes topics like what is the team that makes decisions for Node.js, how do you become a member of that team, how does that team set the roadmap for the project, and how does that team makes decisions.

One thing that we all agree on, is that we're not going to be using the Benevolent Dictator model. In fact, recently the project hasn't been operating that way. We can be more clear about that in our documentation. We all agree we want a healthy and vibrant team, a team focused on making progress for Node.js, not for progress's sake, but for the betterment of the software project and the community we serve. We also agree that this means that there should be consensus among the team. The conversation has been fruitful, and is on going, we're continuing to work through the finer points of how much consensus we need.

I want to take a moment to describe what consensus means in this context. The consensus model is about accountability. Accountability for the changes being integrated into the project, accountability for documentation, and accountability for releases. While members of the team are responsible for subsystems or features of Node.js, everyone reviews each others changes. They make sure to understand the impact on their relevant responsibilities.

The goal of the team, especially that of the project lead, is to drive consensus and ensure accountability. This means asking critical questions and being able to answer them specifically and succinctly, for example:

  • What are we trying to solve with this change?
  • Does this change effectively solve for this problem?
  • Does this API have a consumer?
  • Does this API reach the broadest amount of use cases?
  • Is this API supportable?
  • Does this change have adverse effects on other subsystems or use cases (and is that acceptable)?
  • Does this change have tests that verify its operation, now and in the future?
  • Does this change pass our style guidelines?
  • Does this change pass our integration tests for the matrix of our supported configurations?
    • For instance: ia32 and x64 for Windows, Linux, OSX, SmartOS

These are just some of the questions, and while the questions are not unusual or unique to Node.js, they are still important.

Finally, we are very close to releasing v0.12, there's only one major patch we're waiting to land. Once that's done we'll be releasing v0.11.15 as a release candidate. Assuming no severe issues are filed against v0.11.15 we will be going live with v0.12 about two weeks after the v0.11.15 release.

If you have questions for the advisory board you can email or file an issue on its repository Thanks for all of your continued contributions to Node.js, in the form of filing issues, submitting pull requests, and publishing your modules. Node.js is lucky to have such an enthusiastic and engaged community, and we're excited to be working with you on the future of Node.js.

Thu, 23 Oct 2014 19:12:33 UTC - release

This release handles the recent POODLE vulnerability by disabling SSLv2/SSLv3 by default for the most predominate uses of TLS in Node.js.

It took longer than expected to get this release accomplished in a way that would provide appropriate default security settings, while minimizing the surface area for the behavior change we were introducing. It was also important that we validated that our changes were being applied in the variety of configurations we support in our APIs.

With this release, we are confident that the only behavior change is that of the default allowed protocols do not include SSLv2 or SSLv3. Though you are still able to programatically consume those protocols if necessary.

Included is the documentation that you can find at that describes how this works going forward for client and server implementations.

Node.js is compiled with SSLv2 and SSLv3 protocol support by default, but these protocols are disabled. They are considered insecure and could be easily compromised as was shown by [CVE-2014-3566][]. However, in some situations, it may cause problems with legacy clients/servers (such as Internet Explorer 6). If you wish to enable SSLv2 or SSLv3, run node with the --enable-ssl2 or --enable-ssl3 flag respectively. In future versions of Node.js SSLv2 and SSLv3 will not be compiled in by default.

There is a way to force node into using SSLv3 or SSLv2 only mode by explicitly specifying secureProtocol to 'SSLv3_method' or 'SSLv2_method'.

The default protocol method Node.js uses is SSLv23_method which would be more accurately named AutoNegotiate_method. This method will try and negotiate from the highest level down to whatever the client supports. To provide a secure default, Node.js (since v0.10.33) explicitly disables the use of SSLv3 and SSLv2 by setting the secureOptions to be SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2 (again, unless you have passed --enable-ssl3, or --enable-ssl2, or SSLv3_method as secureProtocol).

If you have set securityOptions to anything, we will not override your options.

The ramifications of this behavior change:

  • If your application is behaving as a secure server, clients who are SSLv3 only will now not be able to appropriately negotiate a connection and will be refused. In this case your server will emit a clientError event. The error message will include 'wrong version number'.
  • If your application is behaving as a secure client and communicating with a server that doesn't support methods more secure than SSLv3 then your connection won't be able to negotiate and will fail. In this case your client will emit a an error event. The error message will include 'wrong version number'.

2014.10.20, Version 0.10.33 (Stable)

  • openssl: Update to 1.0.1j (Addressing multiple CVEs)

  • uv: Update to v0.10.29

  • child_process: properly support optional args (cjihrig)

  • crypto: Disable autonegotiation for SSLv2/3 by default (Fedor Indutny, Timothy J Fontaine, Alexis Campailla)

This is a behavior change, by default we will not allow the negotiation to SSLv2 or SSLv3. If you want this behavior, run Node.js with either --enable-ssl2 or --enable-ssl3 respectively.

This does not change the behavior for users specifically requesting SSLv2_method or SSLv3_method. While this behavior is not advised, it is assumed you know what you're doing since you're specifically asking to use these methods.

Source Code:

Macintosh Installer (Universal):

Windows Installer:

Windows x64 Installer:

Windows x64 Files:

Linux 32-bit Binary:

Linux 64-bit Binary:

Solaris 32-bit Binary:

Solaris 64-bit Binary:

Other release files:




Hash: SHA1

03e72005a4ed612aa7a984d840f148bfb76f3c5f  node-v0.10.33-darwin-x64.tar.gz
f40319ad8720d350ea45e56d5d9018c244482ddc  node-v0.10.33-darwin-x86.tar.gz
4eba69caf7368d7f388700eb02996f85b06f457a  node-v0.10.33-linux-x64.tar.gz
62a58b74851350a935e781d216484966b04ae097  node-v0.10.33-linux-x86.tar.gz
aea7f541e21b57a07b15ab8d825c43f04a2f7440  node-v0.10.33-sunos-x64.tar.gz
97b1d889a299afd6f0c0bb320646d92b7c498d01  node-v0.10.33-sunos-x86.tar.gz
8a637d14609208d31fe466cd4961bec58a8f8f9b  node-v0.10.33-x86.msi
81fcb80d7181768a7211a337c084b4a0b139dd74  node-v0.10.33.pkg
69aeeade5fef622c3150cfc2b4a8f70eea1ef1ec  node-v0.10.33.tar.gz
69275030a0549c27189a8f25396997deb70462ad  node.exe
13dc334420abeaab9b7b3d184e0c5126250ce4e7  node.exp
0379528f6d65eef73ceaeaf9acfe327648a9bc83  node.lib
c23021453a5331954929cff26f7a7f5131af4351  node.pdb
0fe937289a228a5bbc4fc97664eabbdc3a9792e5  openssl-cli.exe
e1cff728f900bda134973666f75aae52a2d60e86  openssl-cli.pdb
6173345fb3c8388abb2a415b99bb4962ebd8e123  x64/node-v0.10.33-x64.msi
a4142d8a122317cc2e32caa643def2797e5f2cd7  x64/node.exe
e067c6d6904a15a494b6b9f3e84cb07dc738c2ea  x64/node.exp
63567e086a965f3ae452b6caace401592cd8c0ec  x64/node.lib
e2cedfc1dd02f1d365314b162167ffb12d1cb0b1  x64/node.pdb
68d60b60f03e703184a10d0a6adff69d9302b93e  x64/openssl-cli.exe
4cd9e8bcf4fa9134a2e84473ec3d7d4b4cd31013  x64/openssl-cli.pdb
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -


Thu, 25 Sep 2014 00:12:24 UTC - release

2014.09.24, Version 0.11.14 (Unstable)

  • uv: Upgrade to v1.0.0-rc1

  • http_parser: Upgrade to v2.3.0

  • npm: Upgrade to v2.0.0

  • openssl: Upgrade to v1.0.1i

  • v8: Upgrade to 3.26.33

  • Add fast path for simple URL parsing (Gabriel Wicke)

  • Added support for options parameter in console.dir() (Xavi Magrinyà)

  • Cluster: fix shared handles on Windows (Alexis Campailla)

  • buffer: Fix incorrect behavior (Feross Aboukhadijeh)

  • buffer: construct new buffer from buffer toJSON() output (cjihrig)

  • buffer: improve Buffer constructor (Kang-Hao Kenny)

  • build: linking CoreFoundation framework for OSX (Thorsten Lorenz)

  • child_process: accept uid/gid everywhere (Fedor Indutny)

  • child_process: add path to spawn ENOENT Error (Ryan Cole)

  • child_process: copy spawnSync() cwd option to proper buffer (cjihrig)

  • child_process: do not access stderr when stdio set to 'ignore' (cjihrig)

  • child_process: don't throw on EAGAIN (Charles)

  • child_process: don't throw on EMFILE/ENFILE (Ben Noordhuis)

  • child_process: use full path for cmd.exe on Win32 (Ed Morley)

  • cluster: allow multiple calls to setupMaster() (Ryan Graham)

  • cluster: centralize removal from workers list. (Julien Gilli)

  • cluster: enable error/message events using .worker (cjihrig)

  • cluster: include settings object in 'setup' event (Ryan Graham)

  • cluster: restore v0.10.x setupMaster() behaviour (Ryan Graham)

  • cluster: support options in Worker constructor (cjihrig)

  • cluster: test events emit on cluster.worker (Sam Roberts)

  • console: console.dir() accepts options object (Xavi Magrinyà)

  • crypto: add honorCipherOrder argument (Fedor Indutny)

  • crypto: allow padding in RSA methods (Fedor Indutny)

  • crypto: clarify RandomBytes() error msg (Mickael van der Beek)

  • crypto: never store pointer to conn in SSL_CTX (Fedor Indutny)

  • crypto: unsigned value can't be negative (Brian White)

  • dgram: remove new keyword from errnoException (Jackson Tian)

  • dns: always set variable family in lookup() (cjihrig)

  • dns: include host name in error message if available (Maciej Małecki)

  • dns: introduce lookupService function (Saúl Ibarra Corretgé)

  • dns: send lookup c-ares errors to callback (Chris Dickinson)

  • dns: throw if hostname is not string or falsey (cjihrig)

  • events: Output the event that is leaking (Arnout Kazemier)

  • fs: close file if fstat() fails in readFile() (cjihrig)

  • fs: fs.readFile should not throw uncaughtException (Jackson Tian)

  • http: add 308 status_code, see RFC7238 (Yazhong Liu)

  • http: don't default OPTIONS to chunked encoding (Nick Muerdter)

  • http: fix bailout for writeHead (Alex Kocharin)

  • http: remove unused code block (Fedor Indutny)

  • http: write() after end() emits an error. (Julien Gilli)

  • lib, src: add vm.runInDebugContext() (Ben Noordhuis)

  • lib: noisy deprecation of child_process customFds (Ryan Graham)

  • module: don't require fs several times (Robert Kowalski)

  • net,dgram: workers can listen on exclusive ports (cjihrig)

  • net,stream: add isPaused, don't read() when paused (Chris Dickinson)

  • net: Ensure consistent binding to IPV6 if address is absent (Raymond Feng)

  • net: add remoteFamily for socket (Jackson Tian)

  • net: don't emit listening if handle is closed (Eli Skeggs)

  • net: don't prefer IPv4 addresses during resolution (cjihrig)

  • net: don't throw on net.Server.close() (cjihrig)

  • net: reset errorEmitted on reconnect (Ed Umansky)

  • node: set names for prototype methods (Trevor Norris)

  • node: support v8 microtask queue (Vladimir Kurchatkin)

  • path: fix slice OOB in trim (Lucio M. Tato)

  • path: isAbsolute() should always return boolean (Herman Lee)

  • process: throw TypeError if kill pid not a number (Sam Roberts)

  • querystring: custom encode and decode (fengmk2)

  • querystring: do not add sep for empty array (cjihrig)

  • querystring: remove prepended ? from query field (Ezequiel Rabinovich)

  • readline: fix close event of readline.Interface() (Yazhong Liu)

  • readline: fixes scoping bug (Dan Kaplun)

  • readline: implements keypress buffering (Dan Kaplun)

  • repl: fix multi-line input (Fedor Indutny)

  • repl: fix overwrite for this._prompt (Yazhong Liu)

  • repl: proper setPrompt() and multiline support (Fedor Indutny)

  • stream: don't try to finish if buffer is not empty (Vladimir Kurchatkin)

  • stream: only end reading on null, not undefined (Jonathan Reem)

  • streams: set default hwm properly for Duplex (Andrew Oppenlander)

  • string_bytes: ucs2 support big endian (Andrew Low)

  • tls, crypto: add DHE support (Shigeki Ohtsu)

  • tls: checkServerIdentity option (Trevor Livingston)

  • tls: add DHE-RSA-AES128-SHA256 to the def ciphers (Shigeki Ohtsu)

  • tls: better error reporting at cert validation (Fedor Indutny)

  • tls: support multiple keys/certs (Fedor Indutny)

  • tls: throw an error, not string (Jackson Tian)

  • udp: make it possible to receive empty udp packets (Andrius Bentkus)

  • url: treat the same as / (isaacs)

Source Code:

Macintosh Installer (Universal):

Windows Installer:

Windows x64 Installer:

Windows x64 Files:

Linux 32-bit Binary:

Linux 64-bit Binary:

Solaris 32-bit Binary:

Solaris 64-bit Binary:

Other release files:




Hash: SHA1

aef6375b86ab40102ff6b879b60c042399fd6606  node-v0.11.14-darwin-x64.tar.gz
c0f1a9d8614513eeb9014aa385e01fd9177227bd  node-v0.11.14-darwin-x86.tar.gz
b3f2a9029e2a6cb3816be5ddcc9cf3dd87e145d6  node-v0.11.14-linux-x64.tar.gz
0c0e69ff51ce33afa192e030e082d4da34ab8060  node-v0.11.14-linux-x86.tar.gz
0308c18297398578de67abff012a7797bdbeb073  node-v0.11.14-sunos-x64.tar.gz
6411add5321401e774cb2ce2c8ca79f3a072dfc9  node-v0.11.14-sunos-x86.tar.gz
ec3fad6d8714ba6d9182974f0ee249d0e8d194b7  node-v0.11.14-x86.msi
38bc708503a91f17f3ea7b0a3a77028582d43a48  node-v0.11.14.pkg
159860fd6d27c9abf2254529e22fe67e385809d6  node-v0.11.14.tar.gz
b00d35d90de8ee133d282e5f15d038ffccc43b41  node.exe
1e7a51f619dd5f7b0d903267f87ed25d3171ccb1  node.exp
7999caa1359645cae722b03b38ebdfdd5b1972c0  node.lib
14fd5b212d48d9f42d9d24adb7b3a325d0472fe3  node.pdb
00c1cc43acf4853fdd2be5b549d3be0157b5f212  openssl-cli.exe
1ebfdc1d8572c2a167111bb11496b67cbf1177bf  openssl-cli.pdb
3f05fc2f4aa95e688bde41c3264ef9295f307ad0  x64/node-v0.11.14.20140819-x64.msi
7c808b88a4c1042ba806dfc32a79ced8cffce180  x64/node.exe
6b8f97668b44cc18ca5c3829a4082c620037d2c6  x64/node.exp
53368a3f8c37d6a716b6d78be1a20fc1e692c22a  x64/node.lib
8c524ce3726e503e4900658241983f364e5aed06  x64/node.pdb
aa1db1b7a5d2d5416c6a44023865f02f34812c29  x64/openssl-cli.exe
90b865ed6df55bde36d24ee7405bdc54b49b8c1e  x64/openssl-cli.pdb
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -


← Page 4

Page 6 →