Hi,
npm is saying that boardgame.io's dependencies have vulnerabilities. Most of the dependencies look like updating them will fix the vulnerabilities.
Looks like the vulnerable dependencies come from koa-socket (which bundles an outdated version of socket.io). We might have to remove that dependency altogether given that the package looks unmaintained.
We could
koa-socket and fix it, socket.io directly, orsocket.io version via npm (see here).If we use socket.io directly, what are thoughts around optionally injecting/ exposing an instance of socket.io?
Use case: I (hypothetically) have other realtime activity happening around my application, outside the jurisdiction of this framework that require a socket connection. Instead of spinning up another instance I could share one?
I think forcing a specific version by editing package-lock is a viable solution for apps, but not libraries.
About forking vs. using socket.io directly, I'm leaning toward the latter. Perhaps we'll end up implementing a subset of koa-socket along the way, but that's ok.
I'm also in favor of allowing the user to inject their own socket.io instance so that only one instance is created. However, note that we're actually in the process of decoupling the network layer from the rest of the framework (#246). socket.io is just an internal implementation detail, and you cannot rely on the fact that the framework will always use it beneath the hood (it may use a different websocket implementation in some cases, or even not use sockets at all).
Wouldn't it be better to just remove one extra abstraction layer and use socket.io directly? koa-socket does not seem to add that much value, specially given that it is unmaintained and has security risks...
Alternative approach can also be to look for a maintained version of koa-socket.
https://github.com/mattstyles/koa-socket/network
There is a maintained forked version of koa-socket it seems. Hopefully the API hasn't been broken.
https://www.npmjs.com/package/koa-socket-2
@bliu13 Thanks for finding this, I will give it a try to migrate it to koa-socket-2.
Released in 0.25.5.
There should be no vulnerabilities (as reported by npm audit) in this version. Please re-open if there are any.
Most helpful comment
I think forcing a specific version by editing package-lock is a viable solution for apps, but not libraries.
About forking vs. using socket.io directly, I'm leaning toward the latter. Perhaps we'll end up implementing a subset of koa-socket along the way, but that's ok.
I'm also in favor of allowing the user to inject their own socket.io instance so that only one instance is created. However, note that we're actually in the process of decoupling the network layer from the rest of the framework (#246). socket.io is just an internal implementation detail, and you cannot rely on the fact that the framework will always use it beneath the hood (it may use a different websocket implementation in some cases, or even not use sockets at all).