We’re at the point where we have a .nar.xz file downloaded from the cache and saved in memory. Now we need to decompress it.
Decompressing
I really took the scenic route getting this done.
I couldn’t find any JavaScript implementations of XZ decompression. There’s a library that uses Web Assembly though, GitHub - SteveSanderson/xzwasm: XZ decompression for the browser via WebAssembly. If you generally need to get an xz-compressed file, that library is probably your best bet.
Contrary to my own advice though, I ended up trying to build my own library from the same materials: the xz-embedded implementation XZ Embedded and wasi-sdk GitHub - WebAssembly/wasi-sdk: WASI-enabled WebAssembly C/C++ toolchain.
Doing our own stunts
It seemed doable: the xzwasm project showed that it took no patching to make xz-embedded build. And I was going to settle for a simpler non-streaming workflow. Moreover, we actually know the size of the decompressed .nar file beforehand, as it’s listed in the .narinfo:
NarSize: 16058632
Unfortunately, I wasn’t able to run the prebuilt wasi-sdk release on Glitch. I think it had to do with the glibc being too old. I ended up compiling it on a different computer.
It compiled fine. I’m using the built in dlmalloc allocator, resulting in a ~28 KB .wasm file. The xzwasm project claims to be under 8 KB–notably they use a more compact walloc. Good on them.
But wouldn’t it be fun to be able to build Web Assembly programs in Glitch? At this point, without any warning, I’ll be sharing a story from five years ago.
Digging up ancient history
I’ve written about some security-related findings on Glitch before, but my first such post Root access on Glitch (already fixed) actually wasn’t about the first privilege escalation vulnerability I found on Glitch.
The very first one I found was back in 2017. I was in contact with Fog Creek Customer Service about it, in case FC3186524. A part of the discussion went as follows:
(me) Is this [privilege escalation] a security concern? If not, it would mean a lot to me if I could just install packages through the package manager.
(support) Certainly, an authenticated user should not be able to run commands as root in the project container.
(support) If there’s a package you feel is missing from the Glitch container, please let me know and we’ll make sure we install it.
That Glitch would let me have a package added to the project container image. This was before I was a big show-off on the forums, so I had never brought this up, but I’ve always thought of it as one of my most prized non-tangible sort of possessions.
I know that Fog Creek has since been on a long journey, becoming Glitch and becoming part of Fastly. And I know some of the key people from back then no longer work there (
). But I have to try. Today’s the day that I say the magic words.
Angelo, I feel that wasi-sdk is missing from the Glitch container.
Glitch, if there’s mean to be any sense of continuity, please consider this request 
In the next post, I’ll comment on the fate of the other technologies I mentioned in a post from a few days ago Community Open Thread 2 - September 16, 2022 - #11 by wh0 : web workers and the cache API.