The 1.3.19 release had a critical bug: any packages published with it
could not be installed, because the shasum would be incorrect.
Thankfully, 1.3.19 was published using 1.3.19, so could not be installed
by any users! However, if it goes out as part of a Node.js release,
then obviously that would be a problem.
Quoting CVE-2013-6639:
The DehoistArrayIndex function in hydrogen-dehoist.cc in Google V8
before 3.22.24.7, as used in Google Chrome before 31.0.1650.63,
allows remote attackers to cause a denial of service (out-of-bounds
write) or possibly have unspecified other impact via JavaScript code
that sets the value of an array element with a crafted index.
Quoting CVE-2013-6640:
The DehoistArrayIndex function in hydrogen-dehoist.cc in Google V8
before 3.22.24.7, as used in Google Chrome before 31.0.1650.63,
allows remote attackers to cause a denial of service (out-of-bounds
read) via JavaScript code that sets a variable to the value of an
array element with a crafted index.
Like 6b92a7, this is unlikely to affect node.js because it only runs
local, trusted code. However, if there exists some module somewhere
that populates an array index with remotely provided data this could
very well be used to crash a remote server running node. Defense in
depth and all.
This is a backport of upstream commit r17801. Original commit log:
Limit size of dehoistable array indices
LOG=Y
BUG=chromium:319835,chromium:319860
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/74113002
When `symlink`, `link` or `rename` report EEXIST, ENOTEMPTY or EPERM -
the destination file name should be included in the error message,
instead of source file name.
fix#6510
NOTE: Also removed `.receivedShutdown` method of `Connection` it wasn't
documented anywhere, and was rewritten with `true` after receiving
`close_notify`.
fix#6638
gyp by default now tries to process gyp files in parallel by using
python's multiprocessing module, but it has problems on oddball
platforms. We don't have many files or complex dependency chains that
would benefit from parallel processing so disable by deafult
fixes#6640
When calling `encOut` in loop, `maybeInitFinished()` may invoke
`clearOut`'s loop, leading to the writing of interleaved data
(encrypted and cleartext) into the one shared pool.
Move `maybeInitFinished()` out of the loop and add assertion for
future.
The null signal test existed, but only tested the case where the target
process existed, not when it did not exist.
Also clarified that SIGUSR1 is reserved by Node.js only for receiveing,
its not at all reserved when sending a signal with kill().
kill(pid, 'O_RDWR'), or any other node constant, "worked". I fixed this
by also checking for 'SIG'. The same as done in the isSignal() function.
Now the signal names supported by process.kill() are the same as those
supported by process.on().
Previously we were building the symbols, but the linker was garbage
collecting the symbols because they weren't used. Inform the linker
that we want to keep all symbols from v8 around.
Replace call to Number::New() with a call to Integer::NewFromUnsigned().
Profiling a Real World(TM) application with perf(1) suggests that the
conversion of its argument from integer to double is disproportionally
costly: over 60% of CPU cycles accountable to WriteStringImpl() are
attributable to the conversion.
After changing it to Integer::NewFromUnsigned(), WriteStringImpl()
has dropped from the 'most costly functions' top ten altogether.
Check that `listeners` is actually an array before trying to manipulate it
because it won't be if no regular event listeners have been registered yet
but there are 'removeListener' event listeners.
v8's `messages.js` file's `CallSiteGetMethodName` is running through all
object properties and getter to figure out method name of function that
appears in stack trace. This run-through will also read `fd` property of
`UDPWrap` instance's javascript object, making `UNWRAP()` fail.
As a simple alternative to the test case above, one could just keep
reference to the dgram handle and try accessing `handle.fd` after it has
been fully closed.
fix#6536
Emitting an event within a `EventEmitter#once` callback of the same
event name will cause subsequent `EventEmitter#once` listeners of the
same name to be called multiple times.
var emitter = new EventEmitter();
emitter.once('e', function() {
emitter.emit('e');
console.log(1);
});
emitter.once('e', function() {
console.log(2);
});
emitter.emit('e');
// Output
// 2
// 1
// 2
Fix the issue, by calling the listener method only if it was not
already called.
Timothy J Fontaine
isaacs
jkummerow@chromium.org
Wyatt Preul
Nicolas Kaiser
Mathias Bynens
Gabriel Farrell
Fedor Indutny
Yazhong Liu
Kai Groner
Gabriel Falkenberg
Sam Roberts
Michael Ridgway
Nikolai Vavilov
Ben Noordhuis
Linus Unnebäck
Jeremy Martin
Tim Wood