There should be at least 2 SVG images, one PNG, and a site .ico.

https://www.npmjs.com/package/gitbook-plugin-ga explains configuration.

Specified in book.json

Something I have seen several times is a condition were the process hits the limit of the available file descriptors, and it results in a server that accepts the TCP sockets, but then it waits in allocating a file descriptor for them (until it's free).

This is typically due to:

stream.pipe(res)  // where res is an http response

If stream errors, res is not closed automatically, leaving a file descriptor behind.

To mitigate this:

stream.pipe(res)

stream.on('error', (err) => {
  // sample implementation
  res.writeHead(500)
  res.end()
})

or

const pump = require('pump')

pump(stream, res)

While this is not a security vulnerability by itself, it could be exploited.

See Edit button top right of the code tab.

https://stackoverflow.com/questions/7757751/how-do-you-change-a-repository-description-on-github

Seeing an unhandledRejection in the output of a Node.js process is a code smell that a bug and a potential security vulnerability are within the codebase. It can trigger a very similar behavior of #28.
I have seen this happening, mainly because a lot of promise users thinks the error model of Node.js is similar to the one of the browser, and a missing error path will not cause problems down the road. This is very different in Node.js itself, because an error that is not handled properly can disrupt thousands of users.

A full example is available at https://github.com/mcollina/make-promises-safe#the-problem.

My solution is to always attach an unhandledRejection  handler which crashes the process.
This is very debated topic in the Node.js ecosystem, because it prevents a very common pattern of Promises, i.e. "fire and forget".

This is my opinion, and I added this issue because I think we should discuss about it.

cc @MylesBorins

Currently you have to dig down to the errata. It might be nice to have a something more prominent, I'll submit a PR with an option soon

First of all, A+ on this. Love it.

Some feedback.

• In https://github.com/google/node-sec-roadmap/blob/master/chapter-1/threat-CRY.md, it would make sense to at least briefly cover the possibility of attacks based on the intersection of Crypto and Compression that make even strong crypto algorithms vulnerable. This is particularly relevant in Node.js when using transfer compression over TLS connections.

• I'm surprised that Denial of Service attacks are not specifically called out, especially given the focus on HTTP in Node.js. It is surprisingly easy to get in to trouble on this.

In "Keep your dependency close", this guide is missing the most adopted practice to solve most but not all of the threat listed: using a private NPM registry (artifactory, npm enterprise or verdaccio/sinopia).
While the proposed yarn approach is free, it significantly complicates the development and deployment workflow. Adopting a private NPM registry is completely transparent and it does not disrupt the development workflow, however those are mostly paid services (https://www.npmjs.com/package/verdaccio being a free alternative).

The only point that is not addressed by using a private NPM registry is the danger of installation scripts. I would classify that as a completely different threat, mainly because "running the install scripts on a separate machine" is something very few do as highly impractical. Moreover, the majority of Node.js binary addons would be hindered by that approach as it would require a single environment for development and production, while a significant portion of the community use Windows or Mac OS X to develop.
These problems should be highlighted in the text as well.

To recap I recommend to split the discussion around registry.npmjs.org issues and the installation scripts. For the first, the guide should also recommend using a private NPM registry. For the latter, the current solution has several disadvantages which should be noted.

See Makefile target check.

This needs to happen after #9

there are so good documentations.
I would like to translate this docs to Japanesea for Japanese Noders.
We think gitlocalize is very helpful for this type docs. https://gitlocalize.com/
If you are fine for translations, we will change this folder organizations.

Tried accessing the website hosting the gitbook and returned 404 error code.

Just wanted to ask/highlight that the website is currently down.

after public release

I rewrote most of the external links to have the form "description ([docs](URL))" but there are still some:

$ find gitbook_out/ -name \*.html | xargs egrep '(^|[^(])<a href="http' | grep -v www.gitbook.com

Then audit the variants of docs, blog, code to the left of the URL in the markdown and canonicalize where applicable.