CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

Further comments on this fix:

• Currently xmlhttprequest-ssl is at version 1.5.5 in our codebase
• These are the commits between that and the version with the security fix (1.6.2):

Of those, only 4 appear to be potentially functional:
mjwwit/node-XMLHttpRequest#6
mjwwit/node-XMLHttpRequest@bf53329
mjwwit/node-XMLHttpRequest@6a0a91d
mjwwit/node-XMLHttpRequest@ee1e81f

I think all of these will be non-breaking for engine-io.client:

• mjwwit/node-XMLHttpRequest@ee1e81f is the security fix, which should be non-functional for any use case that matters
• mjwwit/node-XMLHttpRequest@6a0a91d will be non-functional for uses cases possibly relevant to us
• Fixed abort/error/loadend event firing, statusCode on error, exceptions mjwwit/node-XMLHttpRequest#6 would only be breaking if the user of the library was (as explained in a comment by the maintainer) "relying on the specific error type or 503 status code being returned", but engine-io.client is not
• mjwwit/node-XMLHttpRequest@bf53329 won't effect engine-io.client as that library is just passing options from its caller on through to XMLHttpRequest, and in any effect, it just defaults to stronger security

Even if my read of all of those is incorrect, I am 99% sure that 3box's use of ipfs does not rely on libp2p-webrtc-star. 3box creates an ipfs instance, which in turn instantiates libp2p-webrtc-star. However, 3box only uses the following properties/methods on these ipfs instances:
ipfs.swarm
ipfs.id
ipfs.dag
ipfs.stop
ipfs.pubsub
ipfs.on
ipfs.add

And none of these rely on libp2p-webrtc-star

It also seems safe for eth-trezor-keyring, which only relies on the build-tx module of hd-wallet, which does not rely on socket.io-client (but that gets imported because the whole of hd-wallet is imported)