crypto: check key type in GetPeerCertificate()

Works around the following exception:

  Error: 140463203215168:error:0607907F:digital envelope
  routines:EVP_PKEY_get1_RSA:expecting an rsa key:
  ../deps/openssl/openssl/crypto/evp/p_lib.c:288:
    at CleartextStream._pusher (tls.js:656:24)
    at SlabBuffer.use (tls.js:199:18)
    at CleartextStream.CryptoStream._push (tls.js:483:33)
    at SecurePair.cycle (tls.js:880:20)
    <snip>

The issue has been solved properly in v0.10 and the master branch as of
commit c6e2db2 ("crypto: clear error stack"). This is the "back-port"
to v0.8.

For some (rather unquantifiable) reason the original fix only works for
the tls module in v0.8 but not the https module unless OpenSSL is
downgraded to 0.9.8. Upgrading OpenSSL does *not* fix it, however.

The https module doesn't appear to be at fault; upgrading it to v0.10
doesn't fix the issue. That leaves either the tls or the http module
(that https derives from) but the changes to those modules are too
massive to back-port as-is.

`git bisect` over the v0.8 -> v0.10 commits didn't show up anything
useful, it pinpoints c6e2db2 as the commit that fixes things.

I've spent several hours on this now and seeing that v0.8 is in
maintenance mode, this cheap hack will have to do.

Fixes #4771.
child_process: fix sending utf-8 to child process

In process#send() and child_process.ChildProcess#send(), use 'utf8' as
the encoding and correctly handle partial character sequences by
introducing a StringDecoder. Before this commit, it used 'ascii' and
partial sequences were dropped or corrupted.

This is a back-port of commit 44843a6 from the v0.10 branch.

Fixes #4999 and #5011.
tls: Re-enable check of CN-ID in cert verification

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.
http: Avoid EE warning on ECONNREFUSED handling

This is a back-port of the same fix in
deb1dc279d49463e13af44feed45c79ae0f379f9, for v0.8.
npm: Upgrade to v1.2.18
2013.04.09, Version 0.8.23 (maintenance)

* npm: Upgrade to v1.2.18

* http: Avoid EE warning on ECONNREFUSED handling (isaacs)

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

* child_process: fix sending utf-8 to child process (Ben Noordhuis)

* crypto: check key type in GetPeerCertificate() (Ben Noordhuis)

* win/openssl: mark assembled object files as seh safe (Bert Belder)

* windows/msi: fix msi build issue with WiX 3.7/3.8 (Raymond Feng)
Merge branch 'v0.8.23-release' into v0.8
Now working on 0.8.24
handle_wrap: fix NULL pointer dereference

Fix a NULL pointer dereference in src/handle_wrap.cc which is really a
use-after-close bug.

The test checks that unref() after close() works on process.stdout but
this bug affects everything that derives from HandleWrap. I discovered
it because child processes would sometimes quit for no reason (that is,
no reason until I turned on core dumps.)

This is a back-port of commit ccd3722 from the v0.10 branch.
test: make stdout-close-unref work in test runner

process.stdout isn't fully initialized yet by the time the test starts
when invoked with `python tools/test.py`. Use process.stdin instead and
force initialization with process.stdin.resume().

This is a back-port of commit 2e70dda from the v0.10 branch.
http: Don't try to destroy nonexistent sockets

Fixes #3740

In the case of pipelined requests, you can have a situation where
the socket gets destroyed via one req/res object, but then trying
to destroy *another* req/res on the same socket will cause it to
call undefined.destroy(), since it was already removed from that
message.

Add a guard to OutgoingMessage.destroy and IncomingMessage.destroy
to prevent this error.
url: Properly parse certain oddly formed urls

In cases where there are multiple @-chars in a url, Node currently
parses the hostname and auth sections differently than web browsers.

This part of the bug is serious, and should be landed in v0.10, and
also ported to v0.8, and releases made as soon as possible.

The less serious issue is that there are many other sorts of malformed
urls which Node either accepts when it should reject, or interprets
differently than web browsers.  For example, `http://a.com*foo` is
interpreted by Node like `http://a.com/*foo` when web browsers treat
this as `http://a.com%3Bfoo/`.

In general, *only* the `hostEndingChars` should be the characters that
delimit the host portion of the URL.  Most of the current `nonHostChars`
that appear in the hostname should be escaped, but some of them (such as
`;` and `%` when it does not introduce a hex pair) should raise an
error.

We need to have a broader discussion about whether it's best to throw in
these cases, and potentially break extant programs, or return an object
that has every field set to `null` so that any attempt to read the
hostname/auth/etc. will appear to be empty.
npm: Upgrade to 1.2.24
2013.06.04, Version 0.8.24 (maintenance)

* npm: Upgrade to v1.2.24

* url: Properly parse certain oddly formed urls (isaacs)

* http: Don't try to destroy nonexistent sockets (isaacs)

* handle_wrap: fix NULL pointer dereference (Ben Noordhuis)
Merge branch 'v0.8.24-release' into v0.8
Now working on v0.8.25
npm: Upgrade to 1.2.27
child_process: fix handle delivery

node.js and libuv depend on the fact that none of the supported systems
ever emit more than one SCM_RIGHTS message from a recvmsg() syscall.

SCM_RIGHTS messages are never coalesced. SCM_RIGHTS and normal messages
however _are_ coalesced. That is, recvmsg() might return this:

  recvmsg();  // { "message-with-fd", "message", "message" }

The operating system implicitly breaks pending messages along
SCM_RIGHTS boundaries. Most Unices break before such messages but Linux
also breaks _after_ them.  When the sender looks like this:

  sendmsg("message");
  sendmsg("message-with-fd");
  sendmsg("message");

Then on most Unices the receiver sees messages arriving like this:

  recvmsg();  // { "message" }
  recvmsg();  // { "message-with-fd", "message" }

The bug fix in commit 9352c19 assumes this behavior. On Linux however,
those messages can also come in like this:

  recvmsg();  // { "message", "message-with-fd" }
  recvmsg();  // { "message" }

In other words, it's incorrect to assume that the file descriptor is
always attached to the first message. This commit makes node wise up.

This is a back-port of commit 21bd456 from the v0.10 branch. The test
has been dropped as it's not compatible with the v0.8 process model.

Fixes #5330.

Conflicts:
	lib/child_process.js
npm: Upgrade to 1.2.30
2013.06.13, Version 0.8.25 (maintenance)

* npm: Upgrade to 1.2.30

* child_process: fix handle delivery (Ben Noordhuis)