Update dependency ws to v8.18.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
ws	8.16.0 -> 8.18.0
@types/ws (source)	8.5.10 -> 8.5.11

---

Release Notes

websockets/ws (ws)

v8.18.0

Compare Source

Features

• Added support for Blob (#​2229).

v8.17.1

Compare Source

Bug fixes

• Fixed a DoS vulnerability (#​2231).

A request with a number of headers exceeding the[server.maxHeadersCount][server.maxHeadersCount]
threshold could be used to crash a ws server.

const http = require('http');
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 0 }, function () {
  const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
  const headers = {};
  let count = 0;

  for (let i = 0; i < chars.length; i++) {
    if (count === 2000) break;

    for (let j = 0; j < chars.length; j++) {
      const key = chars[i] + chars[j];
      headers[key] = 'x';

      if (++count === 2000) break;
    }
  }

  headers.Connection = 'Upgrade';
  headers.Upgrade = 'websocket';
  headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
  headers['Sec-WebSocket-Version'] = '13';

  const request = http.request({
    headers: headers,
    host: '127.0.0.1',
    port: wss.address().port
  });

  request.end();
});

The vulnerability was reported by Ryan LaPointe in https://github.com/websockets/ws/issues/2230.

In vulnerable versions of ws, the issue can be mitigated in the following ways:

1. Reduce the maximum allowed length of the request headers using the
   [--max-http-header-size=size][--max-http-header-size=size] and/or the [maxHeaderSize][maxHeaderSize] options so
   that no more headers than the server.maxHeadersCount limit can be sent.
2. Set server.maxHeadersCount to 0 so that no limit is applied.

v8.17.0

Compare Source

Features

• The WebSocket constructor now accepts the createConnection option (#​2219).

Other notable changes

• The default value of the allowSynchronousEvents option has been changed to
  true (#​2221).

This is a breaking change in a patch release. The assumption is that the option
is not widely used.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[G-Rath]

@pubkey would it be possible to get this landed? I expect this is just failed on a flakey test so a rerun of CI should unblock it 🙏

[pubkey]

@G-Rath I restarted the CI several times but this seems to constantly fail.

[G-Rath]

@pubkey hmm that is weird, given that this is a patch update to address a security update - I cant see why the test is failing 🤔

[pubkey]

Maybe this: websockets/ws#2239
I will stop this PR to not trigger the CI on all master changes.

[pubkey]

Related: #6106

[renovate]

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update (8.18.0). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

[G-Rath]

@pubkey I'm not sure why you think websockets/ws#2239 is possibly the issue, as the error I'm seeing in CI is a specific test timing out and it looks like that was happening in #6072 which is before the underlying feature that issue is about was released (and ironically 8.17.1 is the version with the security patch)