Calling `this.pair.encrypted._internallyPendingBytes()` before
handling/resetting error will result in assertion failure:

../src/node_crypto.cc:962: void node::crypto::Connection::ClearError():
Assertion `handle_->Get(String::New("error"))->BooleanValue() == false'
failed.

see #5058

Microsoft's IIS doesn't support it, and is not replying with ServerHello
after receiving ClientHello which contains it.

The good way might be allowing to opt-out this at runtime from
javascript-land, but unfortunately OpenSSL doesn't support it right now.

see #5119

Since _tickCallback and _tickDomainCallback were both called from
MakeCallback, it was possible for a callback to be called that required
a domain directly to _tickCallback.

The fix was to implement process.usingDomains(). This will set all
applicable functions to their domain counterparts, and set a flag in cc
to let MakeCallback know domain callbacks always need to be checked.

Added test in own file. It's important that the test remains isolated.

Fixes #5130.

Fixes #5135.

When a test requires node to have parameters passed (--expose-gc) the
test name will be the last element in the command array, not the second.

It's possible to read multiple messages off the parent/child channel.
When that happens, make sure that recvHandle is cleared after emitting
the first message so it doesn't get emitted twice.

Commit f53441ab added crypto.getCiphers() as a function that returns the
names of SSL ciphers.

Commit 14a6c4ef then added crypto.getHashes(), which returns the names of
digest algorithms, but that creates a subtle inconsistency: the return
values of crypto.getHashes() are valid arguments to crypto.createHash()
but that is not true for crypto.getCiphers() - the returned values are
only valid for SSL/TLS functions.

Rectify that by adding tls.getCiphers() and making crypto.getCiphers()
return proper cipher names.

In process#send() and child_process.ChildProcess#send(), use 'utf8' as
the encoding instead of 'ascii' because 'ascii' mutilates non-ASCII
input. Correctly handle partial character sequences by introducing
a StringDecoder.

Sending over UTF-8 no longer works in v0.10 because the high bit of
each byte is now cleared when converting a Buffer to ASCII. See
commit 96a314b6 for details.

Fixes #4999 and #5011.

Commit 8632af38 ("tools: update gyp to r1601") broke the Windows build.

Older versions of GYP link to kernel32.lib, user32.lib, etc. but that
was changed in r1584. See https://codereview.chromium.org/12256017

Fix the build by explicitly linking to the required libraries.

Doing this causes problems:

    z.write(Buffer(0));
    z.end();

Fix by not ending Writable streams while they're still in the process of
writing something.

Among other things, this should make it easier for people to build
node.js on openbsd.

* Latest stable is v0.10 now.
* Add example of what the first line of the commit log should look like.

Fix #5103

The EncIn, EncOut, ClearIn & ClearOut functions are victims of some code
copy + pasting. A common line copied to all of them is:

`if (off >= buffer_length) { ...`

448e0f43 corrected ClearIn's check from `>=` to `>`, but left the others
unchanged (with an incorrect bounds check). However, if you look down at
the next very next bounds check you'll see:

`if (off + len > buffer_length) { ...`

So the check is actually obviated by the next line, and should be
removed.

This fixes an issue where writing a zero-length buffer to an encrypted
pair's *encrypted* stream you would get a crash.

Increase the number of bits by 1 by making Flags unsigned.

BUG=chromium:211741

Review URL: https://chromiumcodereview.appspot.com/12886008

This is a back-port of commits 13964 and 13988 addressing CVE-2013-2632.

Throw a TypeError if size > 0x3fffffff. Avoids the following V8 fatal
error:

  FATAL ERROR: v8::Object::SetIndexedPropertiesToExternalArrayData()
  length exceeds max acceptable value

Fixes #5126.

The stall is exposed in the test, though the test itself asserts before
it stalls.

The test is constructed to replicate the stalling state of a complex
Passthrough usecase since I was not able to reliable trigger the stall.

Some of the preconditions for triggering the stall are:
  * rs.length >= rs.highWaterMark
  * !rs.needReadable
  * _transform() handler that can return empty transforms
  * multiple sync write() calls

Combined this can trigger a case where rs.reading is not cleared when
further progress requires this. The fix is to always clear rs.reading.

Before this patch calling `socket.setTimeout(0xffffffff)` will result in
signed int32 overflow in C++ which resulted in assertion error:

    Assertion failed: (timeout >= -1), function uv__io_poll, file
    ../deps/uv/src/unix/kqueue.c, line 121.

see #5101

* npm: upgrade to 1.2.15

* crypto: Improve performance of non-stream APIs (Fedor Indutny)

* tls: always reset this.ssl.error after handling (Fedor Indutny)

* tls: Prevent mid-stream hangs (Fedor Indutny, isaacs)

* net: improve arbitrary tcp socket support (Ben Noordhuis)

* net: handle 'finish' event only after 'connect' (Fedor Indutny)

* http: Don't hot-path end() for large buffers (isaacs)

* fs: Missing cb errors are deprecated, not a throw (isaacs)

* fs: make write/appendFileSync correctly set file mode (Raymond Feng)

* stream: Return self from readable.wrap (isaacs)

* stream: Never call decoder.end() multiple times (Gil Pedersen)

* windows: enable watching signals with process.on('SIGXYZ') (Bert Belder)

* node: revert removal of MakeCallback (Trevor Norris)

* node: Unwrap without aborting in handle fd getter (isaacs)

This is not a great fix, and it's a bug that's very tricky to reproduce.

Occasionally, while downloading a file, especially on Linux for some
reason, the pause/resume timing will be just right such that the
CryptoStream is in a 'reading' state, but actually has no data, so it
ought to pull more in.  Because there's no reads happening, it just sits
there, and the process will exit

This is, fundamentally, a factor of how the HTTP implementation sits
atop CryptoStreams and TCP Socket objects, which is utterly horrible,
and needs to be rewritten.  However, in the meantime, npm downloads are
prematurely exiting, causing hard-to-debug "cb() never called!" errors.

The benchmark compare would drop the last run of the binary pairs. So
when they were only run once an error would arise because no data was
generated for the second binary.

Otherwise assertion may happen:

    src/node_crypto.cc:962: void node::crypto::Connection::ClearError():
    Assertion `handle_->Get(String::New("error"))->BooleanValue() == false'
    failed.

See #5058

A non-existing variable `b` was used to queue data for reading.

This reverts commit ea1cba62.

The offending commit was intended to land on the v0.8 branch only, but
it accidentally got merged at some point.

Closes #5054.

The blog lives at blog.nodejs.org while the main website lives at
nodejs.org. Ergo, use absolute URLs for links to the main website.

Fixes #5062.

Fix stucked CryptoStream behaviour, happening when one of the sides
locks-up in queued state.

fix #5023