* Fix a buffer overflow that happens iff strlen(info.sysname) > 255.
* Check the return value of uname().

Fix #5272

The consumption of a readable stream is a dance with 3 partners.

1. The specific stream Author (A)
2. The Stream Base class (B), and
3. The Consumer of the stream (C)

When B calls the _read() method that A implements, it sets a 'reading'
flag, so that parallel calls to _read() can be avoided.  When A calls
stream.push(), B knows that it's safe to start calling _read() again.

If the consumer C is some kind of parser that wants in some cases to
pass the source stream off to some other party, but not before "putting
back" some bit of previously consumed data (as in the case of Node's
websocket http upgrade implementation).  So, stream.unshift() will
generally *never* be called by A, but *only* called by C.

Prior to this patch, stream.unshift() *also* unset the state.reading
flag, meaning that C could indicate the end of a read, and B would
dutifully fire off another _read() call to A.  This is inappropriate.
In the case of fs streams, and other variably-laggy streams that don't
tolerate overlapped _read() calls, this causes big problems.

Also, calling stream.shift() after the 'end' event did not raise any
kind of error, but would cause very strange behavior indeed.  Calling it
after the EOF chunk was seen, but before the 'end' event was fired would
also cause weird behavior, and could lead to data being lost, since it
would not emit another 'readable' event.

This change makes it so that:

1. stream.unshift() does *not* set state.reading = false
2. stream.unshift() is allowed up until the 'end' event.
3. unshifting onto a EOF-encountered and zero-length (but not yet
end-emitted) stream will defer the 'end' event until the new data is
consumed.
4. pushing onto a EOF-encountered stream is now an error.

So, if you read(), you have that single tick to safely unshift() data
back into the stream, even if the null chunk was pushed, and the length
was 0.

* uv: Upgrade to 0.10.4

* npm: Upgrade to 1.2.18

* v8: Avoid excessive memory growth in JSON.parse (Fedor Indutny)

* child_process, cluster: fix O(n*m) scan of cmd string (Ben Noordhuis)

* net: fix socket.bytesWritten Buffers support (Fedor Indutny)

* buffer: fix offset checks (Łukasz Walukiewicz)

* stream: call write cb before finish event (isaacs)

* http: Support write(data, 'hex') (isaacs)

* crypto: dh secret should be left-padded (Fedor Indutny)

* process: expose NODE_MODULE_VERSION in process.versions (Rod Vagg)

* crypto: fix constructor call in crypto streams (Andreas Madsen)

* net: account for encoding in .byteLength (Fedor Indutny)

* net: fix buffer iteration in bytesWritten (Fedor Indutny)

* crypto: zero is not an error if writing 0 bytes (Fedor Indutny)

* tls: Re-enable check of CN-ID in cert verification (Tobias Müllerleile)

Don't scan the whole string for a "NODE_" substring, just check that
the string starts with the expected prefix.

This is a reprise of dbbfbe74 but this time for the child_process
module.

Don't scan the whole string for a "NODE_CLUSTER_" substring, just check
that the string starts with the expected prefix. The linear scan was
causing a noticeable (but unsurprising) slowdown on messages with a
large .cmd string property.

Call SetPointerInInternalField(0, NULL) rather than
SetInternalField(0, Undefined()).

Fixes the following spurious NULL pointer dereference in debug builds:

  #0  0x03ad2821 in v8::internal::FixedArrayBase::length ()
  #1  0x03ad1dfc in v8::internal::FixedArray::get ()
  #2  0x03ae05dd in v8::internal::Context::global_object ()
  #3  0x03b6b87d in v8::internal::Context::builtins ()
  #4  0x03ae1871 in v8::internal::Isolate::js_builtins_object ()
  #5  0x03ab4fab in v8::CallV8HeapFunction ()
  #6  0x03ab4d4a in v8::Value::Equals ()
  #7  0x03b4f38b in CheckEqualsHelper ()
  #8  0x03ac0f4b in v8::Object::SetInternalField ()
  #9  0x06a99ddd in node::ObjectWrap::~ObjectWrap ()
  #10 0x06a8b051 in node::Buffer::~Buffer ()
  #11 0x06a8afbb in node::Buffer::~Buffer ()
  #12 0x06a8af5e in node::Buffer::~Buffer ()
  #13 0x06a9e569 in node::ObjectWrap::WeakCallback ()

This change shouldn't have landed in the stable branch. It's a feature,
not a bug fix.

This reverts commit 58f93ffc.
This reverts commit 8c8ebe49.
This reverts commit ba0f7b80.
This reverts commit 21f3c5c3.

Buffer.byteLength() works only for string inputs. Thus, when connection
has pending Buffer to write, it should just use it's length instead of
throwing exception.

Fixed offset checks in Buffer.readInt32LE() and Buffer.readInt32BE()
functions.

Since 049903e3, an end callback could be called before a write
callback if end() is called before the write is done. This patch
resolves the issue.

In collaboration with @gne

Fixes felixge/node-formidable#209
Fixes #5215

We were assuming that any string can be concatenated safely to
CRLF.  However, for hex, base64, or binary encoded writes, this
is not the case, and results in sending the incorrect response.

An unusual edge case, but certainly a bug.

DH_compute_secret() may return key that is smaller than input buffer,
in such cases key should be left-padded because it is a BN (big number).

fix #5239

We should go to next buffer if *current* one is full, not the next one.
Otherwise we may hop through buffers and written data will become
interleaved, which will lead to failure.

Stop changing arguments, use local variables for things that change.

When using some stream method on a lazy crypto stream, the transform
constructor wasn't called. This caused the internal state object to
be undefined.

On Linux, positional writes don't work when the file is opened in
append mode. The kernel ignores the position argument and always
appends the data to the end of the file.

To quote the man page:

  POSIX requires that opening a file with the O_APPEND flag should have
  no affect on the location at which pwrite() writes data.  However, on
  Linux, if a file is opened with O_APPEND, pwrite() appends data to the
  end of the file, regardless of the value of offset.

fix #5128

RFC 6125 explicitly states that a client "MUST NOT seek a match
for a reference identifier of CN-ID if the presented identifiers
include a DNS-ID, SRV-ID, URI-ID, or any application-specific
identifier types supported by the client", but it MAY do so if
none of the mentioned identifier types (but others) are present.

Quote from commit message:

    Create a new HandleScope for each JSON-parsed object to avoid
    excessive growth.

* npm: Upgrade to 1.2.17

* child_process: acknowledge sent handles (Fedor Indutny)

* etw: update prototypes to match dtrace provider (Timothy J Fontaine)

* dtrace: pass more arguments to probes (Dave Pacheco)

* build: allow building with dtrace on osx (Dave Pacheco)

* http: Remove legacy ECONNRESET workaround code (isaacs)

* http: Ensure socket cleanup on client response end (isaacs)

* tls: Destroy socket when encrypted side closes (isaacs)

* repl: isSyntaxError() catches "strict mode" errors (Nathan Rajlich)

* crypto: Pass options to ctor calls (isaacs)

* src: tie process.versions.uv to uv_version_string() (Ben Noordhuis)