I'm a bit worried that you're going to use an xz library from 2017 (!!).
It seems like https://github.com/ulikunitz/xz is more recommended... (it's even recommended on the README.md of the above library)

Actually this is the library we've been using under the hood from mholt archiver, and is a lighter weight version of ulikunitz/xz when we only need decompression. The README suggests to use ulikunitz/xz when compression is needed, which we can get away without.

This should help us avoid any issues on migration as like decompression algorithm won't have changed, and avoid having to track any of the CVEs which keep cropping up in mholt/archiver. Happy to assess this moving forward if this one crops up in any vulnerability scans or there are issues but it appears to have been a pretty rock solid library for that long!

Please note that we don't use the xz capabilities (as since my last PR, we're setting binariesPath manually), so - whatever I say here is not going to affect our usage at all.

With that said, I feel like this library is completely abandoned. It's old (as noted), and doesn't even use go.mod (it doesn't have any dependencies, but still).

I understand that a "heavier" package, which also supports compression might be more exposed to potential vulnerabilities, but with ulikunitz/xz, I at least feel like - if there will be one - it'll get fixed (e.g. ulikunitz/xz@69c6093).

As noted above - your decision here will not affect me in any way - so - make sure it makes sense to what you're going to use it for...

Thanks!

If a library hasn't been updated in a while it can also be a good thing - it can mean the API is stable/feature complete and there are no bugs.