I'm evaluating node.js as an application platform choice for a large public infrastructure project. One thing that concerns me is (my perception here) a lack of public hardening of the server that's yet to come. I've been around long enough to see that effect on PHP, Django, Rails, etc.
We'll continue our evaluation but it's encouraging to know that issues like these are being discovered and addressed.
(This is also very handy for people writing HTTP servers and clients in other languages, since it's independent of node, and really fast and feature-complete.)
"Based on src/http/ngx_http_parse.c from NGINX copyright Igor Sysoev"
That's not to say that Node doesn't need to fix this (and it seems like Bert from the core team is) but it's not a Node specific issue.
Thus you could say that V8 is "secure" on the client side but "insecure" on the server side because of the different risk assessments. It is poor security practice to take software designed for one security environment and assume it will be secure in other environments. If Node.js wants to have a secure system they will need to take these security issues into consideration and harden their system appropriately.
(The headline is misleading because the issue affects several major language runtimes, V8 included – yet only Node.js is mentioned.)
There is even a cluster module built in now to remove the need for an extra external tool to manage the processes: http://nodejs.org/docs/latest/api/cluster.html (there are more fuller featured options available as extra modules, I'm not sure how they compare efficiency-wise with the in-built one). I'm guessing this isn't the way to go if the processes need to communicate, but I've not looked into it overly deeply yet (my experiments with node not having grown to the point of needing to take advantage of more than one core).
>> Yep. Hang tight. v0.6.7 is coming up soon.
This affect all languages using hashtables with non-randomized hash functions to store POST arguments, it's been discussed on Python's mailing list for instance. It's also been noted on the Erlang list, but all erlang frameworks apparently use proplists for POST mappings, so none of them is affected.
To be pedantic, there are hardcore limits on stuff, that we can not improve upon. We cannot sort a list of n items in less than O(n) for example.
NOTE TO DOWNVOTERS: You shouldn't downvote a technical suggestion, no matter how strange, unless you are certain that it won't work.