Initial prototype of a Kate cartridge importer

[robotlolita]

The overarching idea of this importer is that you should be able to download any game for a different platform, then import it to run in the Kate sandbox — which is particularly useful for running small Windows/Linux-only games released for game jams without all of the associated risk (and without having to set up a separate throwaway machine just to play a video game).

The way it works is pretty straight-forward: given that many game engines are divided into the "engine runtime" and "game runtime", with "game runtime" often being cross-platform, the only thing that the importer needs to do is to take out the "game runtime" part of the Windows/Linux/etc distribution and put it together with a web-based runtime for the same engine. This initial PR does that for Bitsy (the engine is already web-based and embedded in the game) and Ren'Py (a separate "renpyweb" runtime is embedded in the importer) games.

Note that since the necessary runtimes are ultimately embedded in the importer cartridge (for now! I want to implement shared runtime libraries in the future), that means that the importer ends up including LGPL code as well.

Regarding the risks, it's important to note that this patch introduces 3 new dangerous capabilities:

• Ask to access a set of files/directories in the device's file system --- has some privacy and security implications, this is covered by the Device File Access design document included here. We avoid a lot of the security issues that Chrome's File Access API has by not getting or propagating write-access to any file.
• Ask to install a cartridge from a binary --- has escalation issues. There's no proper document on this yet and the only mitigation is a dialog to get active user consent on the installation (showing what will be installed and by whom).
• Ask to download a file to the device's file system --- has security implications, but this is partly mitigated by relying on the browser's existing download infrastructure (so no overwriting files, ensuring that the node gets its stream tainted with the mark of the web, etc), which avoids a few of the security issues in the Chrome's File Access API. A proper document on this is coming.

Also, to support unpacking games from ZIP archives and building the necessary data for Ren'Py cartridges the importer cartridge includes JSZip as an external dependency. The dependency isn't vetted as of now, but the importer runs in a sandboxed process and the capabilities it uses are not easily usable for direct escalation without the user knowledge.

Regarding the technical implementation, it's also important to note that in order to properly support converting an arbitrary Ren'Py PC-game to a renpyweb-based one we need to unpack all files from RPA archives. That's because the renpyweb runtime deals extremely poorly with them (understandably so as there's no point in having those if users will download them from the internet on demand). Unfortunately the RPA archives' index is stored using Python's pickle, which is very Python-specific and lacks a proper specification. Thus this patch includes an implementation of a subset of Python's pickle format in TypeScript based only on the documentation available in https://github.com/python/cpython/blob/main/Lib/pickletools.py and some clarifications on the integer storage from the CPython VM (because of course Pickle uses VM internals). This will require some more thorough testing, but it's also not critical for security — usually the worst that can happen is that the import process fails or succeeds with a file that's different from the intended (which is okay as cartridges generated by the importer have no capabilities).