node blog

Version 0.6.18 (stable)

Posted on 2012/05/15 by Isaac Schlueter

2012.05.15 Version 0.6.18 (stable)

windows: skip GetFileAttributes call when opening a file (Bert Belder)
crypto: add PKCS12/PFX support (Sambasiva Suda)
#3240: child_process: delete NODE_CHANNEL_FD from env in spawn (Ben Noordhuis)
windows: add test for path.normalize with UNC paths (Bert Belder)
windows: make path.normalize convert all slashes to backslashes (Bert Belder)
fs: Automatically close FSWatcher on error (Bert Belder)
#3258: fs.ReadStream.pause() emits duplicate data event (koichik)
pipe_wrap: don't assert() on pipe accept errors (Ben Noordhuis)
Better exception output for module load and process.nextTick (Felix Geisendörfer)
zlib: fix error reporting (Ben Noordhuis)
http: Don't destroy on timeout (isaacs)
#3231: http: Don't try to emit error on a null'ed req object (isaacs)
#3236: http: Refactor ClientRequest.onSocket (isaacs)

Source Code: http://nodejs.org/dist/v0.6.18/node-v0.6.18.tar.gz

Windows Installer: http://nodejs.org/dist/v0.6.18/node-v0.6.18.msi

Windows x64 Files: http://nodejs.org/dist/v0.6.18/x64/

Macintosh Installer (Universal): http://nodejs.org/dist/v0.6.18/node-v0.6.18.pkg

Other release files: http://nodejs.org/dist/v0.6.18/

Website: http://nodejs.org/docs/v0.6.18/

Documentation: http://nodejs.org/docs/v0.6.18/api/

Posted in release | Leave a comment

Bryan Cantrill: Instrumenting the Real Time Web

Posted on 2012/05/08 by Isaac Schlueter

Bryan Cantrill, VP of Engineering at Joyent, describes the challenges of instrumenting a distributed, dynamic, highly virtualized system — and what their experiences taught them about the problem, the technologies used to tackle it, and promising approaches.

This talk was given at Velocity Conf in 2011.

Instrumenting the real-time web

Posted in video | 3 Comments

HTTP Server Security Vulnerability: Please upgrade to 0.6.17

Posted on 2012/05/07 by Isaac Schlueter

tl;dr

A carefully crafted attack request can cause the contents of the HTTP parser’s buffer to be appended to the attacking request’s header, making it appear to come from the attacker. Since it is generally safe to echo back contents of a request, this can allow an attacker to get an otherwise correctly designed server to divulge information about other requests. It is theoretically possible that it could enable header-spoofing attacks, though such an attack has not been demonstrated.
Versions affected: All versions of the 0.5/0.6 branch prior to 0.6.17, and all versions of the 0.7 branch prior to 0.7.8. Versions in the 0.4 branch are not affected.
Fix: Upgrade to v0.6.17, or apply the fix in c9a231d to your system.

Details

A few weeks ago, Matthew Daley found a security vulnerability in Node's HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite well, so I’ll quote him here:

There is a vulnerability in node's http_parser binding which allows information disclosure to a remote attacker:

In node::StringPtr::Update, an attempt is made at an optimization on certain inputs (node_http_parser.cc, line 151). The intent is that if the current string pointer plus the current string size is equal to the incoming string pointer, the current string size is just increased to match, as the incoming string lies just beyond the current string pointer. However, the check to see whether or not this can be done is incorrect; "size" is used whereas "size_" should be used. Therefore, an attacker can call Update with a string of certain length and cause the current string to have other data appended to it. In the case of HTTP being parsed out of incoming socket data, this can be incoming data from other sockets.

Normally node::StringPtr::Save, which is called after each execution of http_parser, would stop this from being exploitable as it converts strings to non-optimizable heap-based strings. However, this is not done to 0-length strings. An attacker can therefore exploit the mistake by making Update set a 0-length string, and then Update past its boundary, so long as it is done in one http_parser execution. This can be done with an HTTP header with empty value, followed by a continuation with a value of certain length.

The attached files demonstrate the issue:
$ ./node ~/stringptr-update-poc-server.js &
[1] 11801
$ ~/stringptr-update-poc-client.py
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Wed, 18 Apr 2012 00:05:11 GMT
Connection: close
Transfer-Encoding: chunked

64
X header:
 This is private data, perhaps an HTTP request with a Cookie in it.
0

The fix landed on 7b3fb22 and c9a231d, for master and v0.6, respectively. The innocuous commit message does not give away the security implications, precisely because we wanted to get a fix out before making a big deal about it.

The first releases with the fix are v0.7.8 and 0.6.17. So now is a good time to make a big deal about it.

If you are using node version 0.6 in production, please upgrade to at least v0.6.17, or at least apply the fix in c9a231d to your system. (Version 0.6.17 also fixes some other important bugs, and is without doubt the most stable release of Node 0.6 to date, so it's a good idea to upgrade anyway.)

I'm extremely grateful that Matthew took the time to report the problem to us with such an elegant explanation, and in such a way that we had a reasonable amount of time to fix the issue before making it public.

Posted in vulnerability | 11 Comments

Version 0.6.17 (stable)

Posted on 2012/05/04 by Isaac Schlueter

2012.05.04 Version 0.6.17 (stable)

Upgrade npm to 1.1.21
uv: Add support for EROFS errors (Ben Noordhuis, Maciej Małecki)
uv: Add support for EIO and ENOSPC errors (Fedor Indutny)
windows: Add support for EXDEV errors (Bert Belder)
http: Fix client memory leaks (isaacs, Vincent Voyer)
fs: fix file descriptor leak in sync functions (Ben Noordhuis)
fs: fix ReadStream / WriteStream double close bug (Ben Noordhuis)

Source Code: http://nodejs.org/dist/v0.6.17/node-v0.6.17.tar.gz

Windows Installer: http://nodejs.org/dist/v0.6.17/node-v0.6.17.msi

Windows x64 Files: http://nodejs.org/dist/v0.6.17/x64/

Macintosh Installer (Universal): http://nodejs.org/dist/v0.6.17/node-v0.6.17.pkg

Other release files: http://nodejs.org/dist/v0.6.17/

Website: http://nodejs.org/docs/v0.6.17/

Documentation: http://nodejs.org/docs/v0.6.17/api/

Posted in release | 3 Comments

multi-server continuous deployment with fleet

Posted on 2012/05/02 by Isaac Schlueter

This is a guest post by James “SubStack” Halliday, originally posted on his blog, and reposted here with permission.

Writing applications as a sequence of tiny services that all talk to each other over the network has many upsides, but it can be annoyingly tedious to get all the subsystems up and running.

Running a seaport can help with getting all the services to talk to each other, but running the processes is another matter, especially when you have new code to push into production.

fleet aims to make it really easy for anyone on your team to push new code from git to an armada of servers and manage all the processes in your stack.

To start using fleet, just install the fleet command with npm:

$ npm install -g fleet

Then on one of your servers, start a fleet hub. From a fresh directory, give it a passphrase and a port to listen on:

$ fleet hub --port=7000 --secret=beepboop

Now fleet is listening on :7000 for commands and has started a git server on :7001 over http. There’s no ssh keys or post commit hooks to configure, just run that command and you’re ready to go!

Next set up some worker drones to run your processes. You can have as many workers as you like on a single server but each worker should be run from a separate directory. Just do:

$ fleet drone --hub=x.x.x.x:7000 --secret=beepboop

where x.x.x.x is the address where the fleet hub is running. Spin up a few of these drones.

Now navigate to the directory of the app you want to deploy. First set a remote so you don’t need to type –hub and –secret all the time.

$ fleet remote add default --hub=x.x.x.x:7000 --secret=beepboop

Fleet just created a fleet.json file for you to save your settings.

From the same app directory, to deploy your code just do:

$ fleet deploy

The deploy command does a git push to the fleet hub’s git http server and then the hub instructs all the drones to pull from it. Your code gets checked out into a new directory on all the fleet drones every time you deploy.

Because fleet is designed specifically for managing applications with lots of tiny services, the deploy command isn’t tied to running any processes. Starting processes is up to the programmer but it’s super simple. Just use the fleet spawn command:

$ fleet spawn -- node server.js 8080

By default fleet picks a drone at random to run the process on. You can specify which drone you want to run a particular process on with the –drone switch if it matters.

Start a few processes across all your worker drones and then show what is running with the fleet ps command:

$ fleet ps
drone#3dfe17b8
├─┬ pid#1e99f4
│ ├── status:   running
│ ├── commit:   webapp/1b8050fcaf8f1b02b9175fcb422644cb67dc8cc5
│ └── command:  node server.js 8888
└─┬ pid#d7048a
  ├── status:   running
  ├── commit:   webapp/1b8050fcaf8f1b02b9175fcb422644cb67dc8cc5
  └── command:  node server.js 8889

Now suppose that you have new code to push out into production. By default, fleet lets you spin up new services without disturbing your existing services. If you fleet deploy again after checking in some new changes to git, the next time you fleet spawn a new process, that process will be spun up in a completely new directory based on the git commit hash. To stop a process, just use fleet stop.

This approach lets you verify that the new services work before bringing down the old services. You can even start experimenting with heterogeneous and incremental deployment by hooking into a custom http proxy!

Even better, if you use a service registry like seaport for managing the host/port tables, you can spin up new ad-hoc staging clusters all the time without disrupting the normal operation of your site before rolling out new code to users.

Fleet has many more commands that you can learn about with its git-style manpage-based help system! Just do fleet help to get a list of all the commands you can run.

$ fleet help
Usage: fleet <command> [<args>]

The commands are:
  deploy   Push code to drones.
  drone    Connect to a hub as a worker.
  exec     Run commands on drones.
  hub      Create a hub for drones to connect.
  monitor  Show service events system-wide.
  ps       List the running processes on the drones.
  remote   Manage the set of remote hubs.
  spawn    Run services on drones.
  stop     Stop processes running on drones.

For help about a command, try `fleet help `.

npm install -g fleet and check out the code on github!

Posted in module | Leave a comment

Version 0.6.16 (stable)

Posted on 2012/04/30 by Isaac Schlueter

2012.04.30 Version 0.6.16 (stable)

Upgrade V8 to 3.6.6.25
Upgrade npm to 1.1.18
Windows: add mappings for UV_ENOENT (Bert Belder)
linux: add IN_MOVE_SELF to inotify event mask (Ben Noordhuis)
unix: call pipe handle connection cb on accept() error (Ben Noordhuis)
unix: handle EWOULDBLOCK (Ben Noordhuis)
map EWOULDBLOCK to UV_EAGAIN (Ben Noordhuis)
Map ENOMEM to UV_ENOMEM (isaacs)
Child process: support the gid and uid options (Bert Belder)
test: cluster: add worker death event test (Ben Noordhuis)
typo in node_http_parser (isaacs)
http_parser: Eat CRLF between requests, even on connection:close. (Ben Noordhuis)
don't check return value of unsetenv (Ben Noordhuis)

Source Code: http://nodejs.org/dist/v0.6.16/node-v0.6.16.tar.gz

Windows Installer: http://nodejs.org/dist/v0.6.16/node-v0.6.16.msi

Windows x64 Files: http://nodejs.org/dist/v0.6.16/x64/

Macintosh Installer (Universal): http://nodejs.org/dist/v0.6.16/node-v0.6.16.pkg

Other release files: http://nodejs.org/dist/v0.6.16/

Website: http://nodejs.org/docs/v0.6.16/

Documentation: http://nodejs.org/docs/v0.6.16/api/

Posted in release | Leave a comment

Profiling Node.js

Posted on 2012/04/25 by Dave Pacheco

It’s incredibly easy to visualize where your Node program spends its time using DTrace and node-stackvis (a Node port of Brendan Gregg’s FlameGraph tool):

Run your Node.js program as usual.
In another terminal, run:
```
$ dtrace -o stacks.out -n 'profile-97/execname == "node" && arg1/{
    @[jstack(100, 8000)] = count(); } tick-60s { exit(0); }'
```
This will sample about 100 times per second for 60 seconds and emit results to stacks.out. Note that this will sample all running programs called “node”. If you want a specific process, replace execname == "node" with pid == 12345 (the process id).
Use the “stackvis” tool to transform this directly into a flame graph. First, install it:
```
$ npm install -g stackvis
```
then use stackvis to convert the DTrace output to a flamegraph:
```
$ stackvis dtrace flamegraph-svg < stacks.out > stacks.svg
```
Open stacks.svg in your favorite browser.

You’ll be looking at something like this:

This is a visualization of all of the profiled call stacks. This example is from the “hello world” HTTP server on the Node.js home page under load. Start at the bottom, where you have “main”, which is present in most Node stacks because Node spends most on-CPU time in the main thread. Above each row, you have the functions called by the frame beneath it. As you move up, you’ll see actual JavaScript function names. The boxes in each row are not in chronological order, but their width indicates how much time was spent there. When you hover over each box, you can see exactly what percentage of time is spent in each function. This lets you see at a glance where your program spends its time.

That’s the summary. There are a few prerequisites:

You must gather data on a system that supports DTrace with the Node.js ustack helper. For now, this pretty much means illumos-based systems like SmartOS, including the Joyent Cloud. MacOS users: OS X supports DTrace, but not ustack helpers. The way to get this changed is to contact your Apple developer liason (if you’re lucky enough to have one) or file a bug report at bugreport.apple.com. I’d suggest referencing existing bugs 5273057 and 11206497. More bugs filed (even if closed as dups) show more interest and make it more likely Apple will choose to fix this.
You must be on 32-bit Node.js 0.6.7 or later, built --with-dtrace. The helper doesn’t work with 64-bit Node yet. On illumos (including SmartOS), development releases (the 0.7.x train) include DTrace support by default.

There are a few other notes:

You can absolutely profile apps in production, not just development, since compiling with DTrace support has very minimal overhead. You can start and stop profiling without restarting your program.
You may want to run the stacks.out output through c++filt to demangle C++ symbols. Be sure to use the c++filt that came with the compiler you used to build Node. For example:
```
c++filt < stacks.out > demangled.out
```
then you can use demangled.out to create the flamegraph.
If you want, you can filter stacks containing a particular function. The best way to do this is to first collapse the original DTrace output, then grep out what you want:
```
$ stackvis dtrace collapsed < stacks.out | grep SomeFunction > collapsed.out
$ stackvis collapsed flamegraph-svg < collapsed.out > stacks.svg
```
If you’ve used Brendan’s FlameGraph tools, you’ll notice the coloring is a little different in the above flamegraph. I ported his tools to Node first so I could incorporate it more easily into other Node programs, but I’ve also been playing with different coloring options. The current default uses hue to denote stack depth and saturation to indicate time spent. (These are also indicated by position and size.) Other ideas include coloring by module (so V8, JavaScript, libc, etc. show up as different colors.)

For more on the underlying pieces, see my previous post on Node.js profiling and Brendan’s post on Flame Graphs.

Dave Pacheco blogs at dtrace.org

Posted in Uncategorized | 8 Comments

Version 0.7.8 (unstable)

Posted on 2012/04/18 by Isaac Schlueter

2012.04.18, Version 0.7.8, (unstable)

Upgrade V8 to 3.9.24.9
Upgrade OpenSSL to 1.0.0f
Upgrade npm to 1.1.18
Show licenses in Binary installers
Domains (isaacs)
readline: rename "end" to "close" (Nathan Rajlich)
tcp: make getsockname() return address family as string (Shigeki Ohtsu)
http, https: fix .setTimeout() (ssuda)
os: add cross platform EOL character (Mustansir Golawala)
typed arrays: unexport SizeOfArrayElementForType() (Aaron Jacobs)
net: honor 'enable' flag in .setNoDelay() (Ben Noordhuis)
child_process: emit error when .kill fails (Andreas Madsen)
gyp: fix 'argument list too long' build error (Ben Noordhuis)
fs.WriteStream: Handle modifications to fs.open (isaacs)
repl, readline: Handle newlines better (Nathan Rajlich, Nathan Friedly)
build: target OSX 10.5 when building on darwin (Nathan Rajlich)
Fix #3052 Handle errors properly in zlib (isaacs)
build: add support for DTrace and postmortem (Dave Pacheco)
core: add reusable Slab allocator (Ben Noordhuis)

Source Code: http://nodejs.org/dist/v0.7.8/node-v0.7.8.tar.gz

Windows Installer: http://nodejs.org/dist/v0.7.8/node-v0.7.8.msi

Windows x64 Files: http://nodejs.org/dist/v0.7.8/x64/

Macintosh Installer (Universal): http://nodejs.org/dist/v0.7.8/node-v0.7.8.pkg

Other release files: http://nodejs.org/dist/v0.7.8/

Website: http://nodejs.org/docs/v0.7.8/

Documentation: http://nodejs.org/docs/v0.7.8/api/

Posted in release | Leave a comment

Version 0.6.15 (stable)

Posted on 2012/04/09 by Isaac Schlueter

2012.04.09 Version 0.6.15 (stable)

Update npm to 1.1.16
Show licenses in binary installers.
unix: add uv_fs_read64, uv_fs_write64 and uv_fs_ftruncate64 (Ben Noordhuis)
add 64bit offset fs functions (Igor Zinkovsky)
windows: don't report ENOTSOCK when attempting to bind an udp handle twice (Bert Belder)
windows: backport pipe-connect-to-file fixes from master (Bert Belder)
windows: never call fs event callbacks after closing the watcher (Bert Belder)
fs.readFile: don't make the callback before the fd is closed (Bert Belder)
windows: use 64bit offsets for uv_fs apis (Igor Zinkovsky)
Fix #2061: segmentation fault on OS X due to stat size mismatch (Ben Noordhuis)

Source Code: http://nodejs.org/dist/v0.6.15/node-v0.6.15.tar.gz

Windows Installer: http://nodejs.org/dist/v0.6.15/node-v0.6.15.msi

Windows x64 Files: http://nodejs.org/dist/v0.6.15/x64/

Macintosh Installer (Universal): http://nodejs.org/dist/v0.6.15/node-v0.6.15.pkg

Other release files: http://nodejs.org/dist/v0.6.15/

Website: http://nodejs.org/docs/v0.6.15/

Documentation: http://nodejs.org/docs/v0.6.15/api/

Posted in release | 2 Comments

Version 0.7.7 (unstable)

Posted on 2012/03/30 by Isaac Schlueter

2012.03.30, Version 0.7.7 (unstable)

Upgrade V8 to 3.9.24.7
Upgrade npm to 1.1.15
Handle Emoji characters properly (Erik Corry, Bert Belder)
readline: migrate ansi/vt100 logic from tty to readline (Nathan Rajlich)
readline: Fix multiline handling (Alex Kocharin)
add a -i/–interactive flag to force the REPL (Nathan Rajlich)
debugger: add breakOnException command (Fedor Indutny)
cluster: kill workers when master dies (Andreas Madsen)
cluster: add graceful disconnect support (Andreas Madsen)
child_process: Separate 'close' event from 'exit' (Charlie McConnell)
typed arrays: add Uint8ClampedArray (Mikael Bourges-Sevenier)
buffer: Fix byte alignment issues (Ben Noordhuis, Erik Lundin)
tls: fix CryptoStream.setKeepAlive() (Shigeki Ohtsu)
Expose http parse error codes (Felix Geisendörfer)
events: don't delete the listeners array (Ben Noordhuis, Nathan Rajlich)
process: add process.config to view node's ./configure settings (Nathan Rajlich)
process: process.execArgv to see node's arguments (Micheil Smith)
process: fix process.title setter (Ben Noordhuis)
timers: handle negative or non-numeric timeout values (Ben Noordhuis)