The build chain for node-gyp involves python, make and g++ (or even build-essential).
Adding these components to a runtime image for some Linux VMs seems to introduce a large number of medium severity CVE's.
This is as well as increasing image size and the surface area for attack.
I notice that the majority of nodes, where there is a need for a binary, already have pre-builds, for example node-red-node-serial-port. Less popular nodes or ones with requirements that have been deprecated by NPM do not seem to.
The use of node-pre-gyp also seems to be faster and a more reliable way of adding a binary.
So in light of this part of me s considering omitting g++ from the runtime image and having it so that if a user wants to install a node that has a prerequisite for building they would need to temporarily install g++ themselves and then remove it afterwards.
In general, the use of Node.js pretty much assumes that you will have build essentials for the platform you are using. While most modules that require compiled libraries will have pre-compiled versions for multiple platforms, that can never be guaranteed.
It is not clear what you mean by 'only include nodes in the palette that have pre-buillt binaries`. I don't think any of the core nodes need building on most platforms. If the users chooses not to install such nodes then the build applications need not be installed.
Can you give a couple of examples of that? For a debian based system it is build-essential that needs to be installed in order to build nodes.
At least some of those (from a very quick check) relate to Linux itself so I'm not sure that the risk is what you think it is. Not saying there aren't any risks but you should check, as Colin suggests, that you need to check build-essentials for issues. You cannot lay the issues of Linux against the door of node.js.
I think he is refering to packages that contain binaries in it. Instead of building docker images with those binaries you can install packages and use the binaries from $NODE_PATH/package/binary
