> iSH has nothing stopping you, the user, from wgetting arbitrary scripts or binaries and running them in the VM[0] "Nothing stopping you" in the same sense th

> iSH has nothing stopping you, the user, from wgetting arbitrary scripts or binaries and running them in the VM[0] "Nothing stopping you" in the same sense that there's nothing stopping someone from using a sequence of specific gamepad button-presses to turn Super Mario World into Flappy Bird. In vulnerability-exploitation terms, sure, the attack surface is there. But in "would anyone actually spend time doing this" terms: no. The advantages don't outweigh the labor costs. (Especially if you're doing this for work, in anger, and you want to install an app to let you solve a problem right now by popping open a Linux terminal, and installing all the packages you need — including some arbitrary non-packaged SDKs that depend on dev-dependencies from specific known Linux flavors.) Mind you, in theory, someone could make it easier for everyone else to do this, by writing a bootstrap script that wgets a bunch of stuff and effectively turns your iSH environment into e.g. Debian. But nobody has done this. Why? I can't say for sure, but I suspect it's precisely because the iSH "sandbox" isn't actually a VM containing a Linux kernel, but rather an older technique — I think involving a userland of binaries compiled to use Darwin libraries; or maybe more likely, a userland linked to some Linux-on-XNU virtualization layer (custom libc, libresolv, etc.) And that's just not a "flavor" of Linux that you can find Debian packages for, or even third-party APKs for. Even if you built up your own apt base-packages repo to allow debootstrap to work, that wouldn't magically enable you to then find install deb packages from arbitrary apt repos that weren't compiled for the iSH "arch". And I think that iSH continuing to exist on iPadOS, but persisting in doing this complex kind of virtualization rather than switching over to being "just VM software hard-coded to use a specific Linux VM", is perhaps on purpose. I'm guessing that Apple wouldn't allow "just a Linux VM" on the App Store any more than they allow UTM — again, precisely because it would unlock the capability to efficiently utilize arbitrary third-party packages, and thereby to actually use the iPad "in anger" for software-development business productivity. It would be "enough" of a development environment that some businesses might consider buying their employees iPads instead of Macs. And Apple really wants to avoid that. > Also, iSH does have a package manager. It used to actually be modified to pull packages from the App Store but now they use a separate server. I don't remember if it's the Alpine Linux package repo or a custom thing for iSH. It's a semi-custom thing for iSH, in that it's a custom "arch", with all the packages containing binaries compiled for the iSH virtualization layer. So you can't switch over/add on any third party repo; binaries from ordinary arm64 APKs wouldn't run. Third parties would need to create an iSH-arch release of their package specifically. And AFAIK there's no published infrastructure to enable third parties to do that. In essence, though, the packages in this repo are still a "part of" the app. Despite being hosted on a third-party server, those packages still have to be signed — and I have a strong feeling that Apple, not the iSH dev, holds those signing keys. So Apple, not the iSH dev, gets final say over what APKs end up available in the iSH userland. (And that's why those APKs haven't been updated in a while — the iSH dev likely has to go back-and-forth with Apple when pushing out updates to their own repo — just as if they were publishing a new version of the app.)