Please fix security issues

[waynebrantley]

This project has several vulnerabilities in the dependencies are reported by npm audit.

package - node-http-signature

The biggest is caused by this project's dependency on node-http-signature which depends on several items with vulnerabilities.

• sshpk has a high vulnerability (denial of service).

This was reported an a PR requested (but not merged) several months ago. Appears to be no maintainer.

TritonDataCenter/node-http-signature#70
https://nodesecurity.io/advisories?search=sshpk&version=1.13.1

• stringstream is medium (out of bounds read)
  https://nodesecurity.io/advisories?search=stringstream&version=0.0.5

Would request you replace the dependency or fork to resolve.

package - request

Another vulnerability is on hoek which is used by used by hawk, which is used by request.
If you update request - they removed the dependency on hawk, which will fix this.
https://nodesecurity.io/advisories?search=hoek&version=4.2.0

Additionally, would it be possibly to make npm audit part of the deployment/release process of this repository so future vulnerabilities can be mitigated sooner?

[funkyboy]

@waynebrantley thanks for reporting this. I merged this PR but I still see occurrences of hoek. Will get back to this.

[waynebrantley]

@funkyboy Thanks for getting on this.
What about sshpk and stringstream?
Also, can you able to make npm audit part of your release process?

[funkyboy]

@waynebrantley will chip them away one at a time. I will update this issue as I progress.

[mattheworiordan]

Also, can you able to make npm audit part of your release process?

@waynebrantley please create a separate issue for this. We will certainly consider it in future.

@waynebrantley in addition:

sshpk has a high vulnerability (denial of service).

None of our code paths rely on this. So yes this should be fixed, but in browsers this is not used, and in Node versions of this lib, this vulnerability doe not impact any of our users as far as I can tell.

Another vulnerability is on hoek which is used by used by hawk, which is used by request.

Sure, but this is an authentication scheme we do not support. So unless someone explicitly uses the request module by hacking into the privates of our library, this too is not a security issue that can effect our users at present.

@funkyboy it would be good to upgrade these dependencies for hygiene reasons, but this is a low priority issue it seems.

[SimonWoolf]

Thanks for getting on this. What about sshpk and stringstream?

All of the audit failures currently reported against ably-js are with dev dependencies. That is, code that is only used as part of our development or testing infrastructure, not that is actually used when running ably-js.

For example, ably-js currently depends on two versions of the request module; 2.87.0 for production use, and 2.79.0 which is required by a dev dependency. Only the latter depends on hawk and stringstream; the version actually used by ably-js does not.

Eliminating security issues in dev/test code, while it would be nice, is often not practical: our testing stuff needs to work on very old platforms (we support back to IE8), and updating to newer versions would in some cases conflict with this. But again, that has absolutely no effect on the security of ably-js as used.

Also, can you able to make npm audit part of your release process?

Sure, pending npm/npm#20564 to avoid these sort of false positives. #551