2014.12.17, Version 0.10.34 (Stable)
uv: update to v0.10.30
zlib: upgrade to v1.2.8
child_process: check execFile args is an array (Sam Roberts)
child_process: check fork args is an array (Sam Roberts)
crypto: update root certificates (Ben Noordhuis)
domains: fix issues with abort on uncaught (Julien Gilli)
timers: Avoid linear scan in _unrefActive. (Julien Gilli)
timers: fix unref() memory leak (Trevor Norris)
v8: add api for aborting on uncaught exception (Julien Gilli)
debugger: fix when using "use strict" (Julien Gilli)
Source Code: http://nodejs.org/dist/v0.10.34/node-v0.10.34.tar.gz
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.34/node-v0.10.34.pkg
Windows Installer: http://nodejs.org/dist/v0.10.34/node-v0.10.34-x86.msi
Windows x64 Installer: http://nodejs.org/dist/v0.10.34/x64/node-v0.10.34-x64.msi
Windows x64 Files: http://nodejs.org/dist/v0.10.34/x64/
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.34/node-v0.10.34-linux-x86.tar.gz
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.34/node-v0.10.34-linux-x64.tar.gz
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.34/node-v0.10.34-sunos-x86.tar.gz
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.34/node-v0.10.34-sunos-x64.tar.gz
Other release files: http://nodejs.org/dist/v0.10.34/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 8df2fdb333dd8edee59ceaf72738e3773c7863e6 node-v0.10.34-darwin-x64.tar.gz 03168c2157baff928a397b85d8a7e6731b270f9a node-v0.10.34-darwin-x86.tar.gz f064a252827c8129126f0e8ab3c8bf46f92506ec node-v0.10.34-linux-x64.tar.gz fe0343f97c35aeb2c72bfd997dafde947ff44c23 node-v0.10.34-linux-x86.tar.gz 4b3ccf37886f8056800ed174688c8782f9857d52 node-v0.10.34-sunos-x64.tar.gz ea891434436ed91d806201eb329d3c98f7e3c6b6 node-v0.10.34-sunos-x86.tar.gz 7609d6dda6071e499a54656bbf85f16ed097c106 node-v0.10.34-x86.msi 56e2aec59ac526d3daf607c7f50c2faf3e857cff node-v0.10.34.pkg a342eb4d653ab48ba016c0c0c259565c822881cc node-v0.10.34.tar.gz c71dce9dd3f3fbff34506a4edc3e37c59e31d7bd node.exe ffc836802c3b2e25b38f4f73c0f044fef345e152 node.exp 3e24f9c69826f320d303795c3564994e4311879f node.lib 8ccb4fdaaaec797e0762cea38112af5456fe3f7e node.pdb fa0d0c098f475d6e1d6ad74c301a2361a9ac9888 openssl-cli.exe 72772212ff62ecbf76ca468f402184e3f364de51 openssl-cli.pdb c54153231d0003792c4431cea38b9cb733a142b5 x64/node-v0.10.34-x64.msi b84684c92ed41a883452eb65a3010223378eb1ca x64/node.exe c95e2dd11dc216c4b2d5a76852d2a0e7a8b247bc x64/node.exp 41db33520c33c576e4591771c371ae5f2644cadf x64/node.lib d2ebec3f34e1a7e7969bfbe3330140f253b3cf9c x64/node.pdb b678c997ad7747c4c35dc8c8362730fca5bad97c x64/openssl-cli.exe f38f6eaae3aa2b11f3835b67f2dce04f4fc0fab8 x64/openssl-cli.pdb -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlSR/MIACgkQfTP/nQJGQG3ViACcC47u19WHh+vC4rfwJOoaRBFq 4fUAnAm48HaJGYQ3sUlJlEq68LCwJfgL =yduE -----END PGP SIGNATURE-----
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.
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: http://nodejs.org/advisory-board. 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 https://github.com/joyent/nodejs-advisory-board, as well as on the website https://nodejs.org/advisory-board.
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 firstname.lastname@example.org or file an issue on its repository https://github.com/joyent/nodejs-advisory-board. 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.
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 https://nodejs.org/api/tls.html#tls_protocol_support 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-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
The default protocol method Node.js uses is
SSLv23_method which would be more
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
If you have set
securityOptions to anything, we will not override your
The ramifications of this behavior change:
- If your application is behaving as a secure server, clients who are
SSLv3only will now not be able to appropriately negotiate a connection and will be refused. In this case your server will emit a
clientErrorevent. 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
errorevent. 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
This does not change the behavior for users specifically requesting
SSLv3_method. While this behavior is not advised, it is
assumed you know what you're doing since you're specifically asking to use
Macintosh Installer (Universal): https://nodejs.org/dist/v0.10.33/node-v0.10.33.pkg
Windows Installer: https://nodejs.org/dist/v0.10.33/node-v0.10.33-x86.msi
Windows x64 Installer: https://nodejs.org/dist/v0.10.33/x64/node-v0.10.33-x64.msi
Windows x64 Files: https://nodejs.org/dist/v0.10.33/x64/
Linux 32-bit Binary: https://nodejs.org/dist/v0.10.33/node-v0.10.33-linux-x86.tar.gz
Linux 64-bit Binary: https://nodejs.org/dist/v0.10.33/node-v0.10.33-linux-x64.tar.gz
Solaris 32-bit Binary: https://nodejs.org/dist/v0.10.33/node-v0.10.33-sunos-x86.tar.gz
Solaris 64-bit Binary: https://nodejs.org/dist/v0.10.33/node-v0.10.33-sunos-x64.tar.gz
Other release files: https://nodejs.org/dist/v0.10.33/
-----BEGIN PGP SIGNED MESSAGE----- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRJUxYACgkQfTP/nQJGQG2eNwCdGAIzkYTGHFohi2PVWKIKYmmq bvoAnAulTmcNMMLlXi1+Nmtt5SGyZIL8 =0QtW -----END PGP SIGNATURE-----