Fix GHSA-mp2f-45pm-3cg9 by migrating to @xhmikosr/decompress

[vavsab]

Fixes #29 — GHSA-mp2f-45pm-3cg9.

• decompress@^4.2.1 → @xhmikosr/decompress@^11.1.3
• decompress-tar@^4.1.1 → @xhmikosr/decompress-tar@^9.0.1
• decompress-unzip@^4.0.1 → @xhmikosr/decompress-unzip@^8.1.1
• engines.node >=16 → >=20 (required by @xhmikosr/decompress@11; can drop to >=18 with the ^10.2.1 line if preferred)

Call site unchanged (same default-export API). Verified locally with weval's exact decompress(buf, dir, { strip: 1, plugins: [unzip(), tar()], filter }) call against a real tar.

[vavsab]

Friendly ping @cfallin @andreiltd @vados-cosmonic — would you be able to merge and cut a release when you get a chance? This is the only remaining source of the critical decompress CVE for downstreams. Thanks!

[cfallin]

I am currently on PTO (monitoring email) this week and traveling next week. I can take a closer look after that. On first pass, randomly-named fork plus pressure to merge sets off some yellow flags for me (see xz supply-chain attack), and the decompressor is used only to unpack GitHub release artifacts which are trusted, so I want to be cautious here. I'll ping some others in Bytecode Alliance to make them aware as well.

[tschneidereit]

I agree with Chris: we definitely can't take a dependency on a fork with very little usage and almost no dependents for such a core piece of functionality. That'd be true even if our use of decompress was of potentially untrusted contents, but since that's additionally not the case, I don't see reason for particular urgency in fixing things here.

@vavsab if you do need a fix, you could look at updating the code to make use of something like tar or minizlib instead.

[vavsab]

@tschneidereit Do you mean that I am welcome to contribute here to replace decompress with tar?

[tschneidereit]

@vavsab absolutely, yes. At a quick glance that should be a pretty straightforward change that I'd be happy to sign off on.