chore(deps): ws@8.21.0 (fixes DoS vulnerability)

[AviVahl]

change ws requests to carets, as package respects semver

https://github.com/websockets/ws/releases/tag/8.21.0

@darrachequesne since this is the third time I'm updating this one, I've also changed it to carets so that any future vulnerability fixes are automatically targeted.

The kind of change this PR does introduce

• a bug fix
• a new feature
• an update to the documentation
• a code change that improves performance
• other

[darrachequesne]

@AviVahl thanks for your pull request. However, we have had breaking changes from dependencies affecting users in the past, hence the current ~ usage. Could you please update your PR?

[AviVahl]

@darrachequesne done, even though I think the approach of locking it partially has its own downsides.

[AviVahl]

Alright, I've rebased so that all pacakges/* use tilda, and the docs/examples still use the carets.
Consistent with what's currently in main.

[AviVahl]

heya @darrachequesne
any chance this can be released as a patch version? npm started giving alerts for this vulnerability today.

[chadlwilson]

@darrachequesne it really would be appreciated if you could re-evaluate this policy.

It’s rather a waste of time for every security-conscious user to have to either put an override in place or wait for a socketio release in order to get a patch for the latest transitive issue in one of the thousands of dependencies in the average project. With the explosion of vulnerabilities right now, I don’t think this is a defensible position compared to the alternative, and ws don’t seem likely to start back porting fixes to minor versions.

You always have your lock file for your own tests without having to constrain all users?

[darrachequesne]

@AviVahl here you go:

• engine.io@6.6.9
• engine.io-client@6.6.6
• socket.io-adapter@2.5.8

[darrachequesne]

@chadlwilson I understand your concern. However, even with SemVer, minor releases may introduce new behavior, new protocol interactions, or dependency graph changes. Since the Socket.IO packages are tightly coupled and interoperability between server/client/parser/engine packages matters, we prefer to adopt minor updates explicitly after validating them in the monorepo.

Using ~ gives us patch-level fixes by default while keeping minor upgrades under maintainer control. Security fixes that require a minor bump can still be handled explicitly, but we feel that they should not be pulled in implicitly for every consumer through a ^ range.

[chadlwilson]

I understand the theory - but I think this is a poor trade-off to decide on behalf of your users. To save them potential theoretical time in case something is broken by a new ws feature, it imposes a separate guaranteed amount of manual effort for nearly every security release (given nearly monthly minor bumps to ws which socket.io doesn't keep up with)

Even with ^, conservative users will still be locking their transitives themselves and won't automatically upgrade within the range anyway to be affected by some change. However more aggressive users may choose to upgrade their transitives (via dependabot/renovate or whatnot) but that's not the default and it's at their risk. Meanwhile everyone would get automated dependabot PRs without being blocked and needing to chase (or override).

By locking like this you're making the decision on behalf of your users and working against the systems designed to keep people safe at low cost - automation. I'd encourage you to think about what this would mean for productivity in the ecosystem if every package within the ecosystem took this approach. All users would be would be dealing with forced overrides everywhere at all times and getting nothing done.

Anyway, it's your project and you can do what you think is best. But please consider the tax you are imposing and whether you want your users to groan every time socket.io is indirectly responsible for yet another vulnerability they have to spend time manually digging into and ending up digging around unreleased PRs like this rather than just patching and getting back to delivering value. I only commented because this is the 2nd or 3rd time within as many months I've had to manually review a stuck vuln patch, and when managing OSS projects with thousands of dependencies - its rather obvious that socket.io is an outlier.

[AviVahl]

@AviVahl here you go:

* [engine.io@6.6.9](https://github.com/socketio/socket.io/releases/tag/engine.io%406.6.9)

* [engine.io-client@6.6.6](https://github.com/socketio/socket.io/releases/tag/engine.io-client%406.6.6)

* [socket.io-adapter@2.5.8](https://github.com/socketio/socket.io/releases/tag/socket.io-adapter%402.5.8)

Thank you. Works from our end.

Needless to say that I agree with @chadlwilson
I can give over 10 examples from just the past month where I had to ask different projects (netlify, openapi, monaco, etc) to bump locked versions for security fixes. This is quite hard to track, and I can imagine most developers won't even bother doing any of that.
We aim to have a 0 known vulnerabilities in all our projects... quite a feat in an ecosystem where different publishers have different preferences over how/when updates should be applied.

Anyhow, I appreciate this project and all your work. ❤️