Hey. I am trying to get Atuin Desktop packaged as Flatpak. That is, if I can iron out the issues with the sandbox, i.e., escaping the sandbox for the commands run by the integrated terminals. Would that be something you would be interested in?
Escaping the sandbox means running `host-spawn` ( GitHub - 1player/host-spawn: Run commands on your host from inside your toolbox or flatpak sandbox ) for every integrated terminal/script invocation to spawn a host shell. Manually putting host-spawnin front of every integrated terminal/script works great. Ideally then, the upstream app would recognize that it is running as a flatpak (flatpak env variables are set) and prepend each shell invocation with host-spawnto spawn a host shell, and only in the host shell input the user command.
If I manage to do it, would you prefer I submit the package to FlatHub as an unofficial distribution (“unverified”), or an official one (“verified”) under your reverse-DNS URI, like `sh.atuin.atuin-desktop`), notifying the users that the package is distributed and endorsed by its developers.
I am willing to maintain the package for the foreseeable future if you do not want to take over (when submitted, I can give you access to the repository to manage the package, updates can be fully automated (with/without manual merge approval on each update)).
Happy to make it an official build, if you’re still good to maintain that? Would definitely appreciate access to the repo in that case.
How difficult is the sandbox? We’re likely to be doing a whole bunch more shell + terminal in the future, and I’d rather not ship something that keeps breaking with every update. I’m sure it can be worked around or disabled?
Fully understand the concerns. If this proves to be unreliable, I would definitely not suggest marking it as official.
It remains to be seen how it would work. From what I have seen, there are two main approaches to spawning a host shell. One is using host-spawn described above. Every terminal block invocation will spawn a new host shell using host-spawn, and re-running the same terminal block will just keep the previously spawned shell. This already works in the current build when run manually as a part of the command to be run. We would need support in the upstream for when in the Flatpak sandbox, run host-spawnfor each first invocation of a terminal block. By terminal block, I mean terminal, script, etc. blocks.
The second is manually handling terminal process group, PIDs etc. E.g., KDE terminal app Konsole upstream code does this: detects being run inside a sandbox, and handles the shell invocation differently. Basically opening a {t,p}ty on host, redirecting it to the sandbox, and maintaining the connection. Another terminal app. Similar to what Atuin Desktop is already doing with Ptystructs, but with one more layer of indirection.
Upon some very basic experimentation, it seems that host-spawn would be sufficient for Atuin Desktop use cases, but maybe I am wrong. Completely disabling the sandbox is not really an option in Flatpak (notably, to directly run commands on host as if unsandboxed; allowing access to anything should not be a problem). Hence, the sandbox escape paths above.
Script blocks are basically a “execute every line as a separate host-spawn <command>“, which seamlessly handles passing input and output from the sandbox and back. Env var propagation works with host-spawn nicely, too. Getting an output of a script block, etc. Other blocks should hopefully also work somewhat seamlessly.
I am looking at the code now. Hard to tell what will happen. `host-spawn` can allocate its own pty, or can work without allocating a new pty. That might be worth trying out. If the --no-pty version works, it will be actually much easier to implement, I think. Even the base vesion with pty however already works. It only needs handling for properly initializing the shell for the first time, and not trying to initialize the shell in subsequent re-runs which should not spawn a new shell.
Hmm, quick test shows the no-pty version not doing what I wanted. There might be some interference with the current build handling of pty. As of now, there should be two separate ptys when using the pty version of `host-spawn`. You manage the pty for the sandbox shell where host-spawn will run, and host-spawn will allocate a new pty for the host shell. Ideally, the pty you manage would already be the host’s. Not sure how viable that is. Alternatively, there will just be two levels of indirection, with the data being sent back and forth. (Very non-authorative guesses. I have not studied this topic enough to understand what is actually happening.)
Hey, sorry for the delay. The last two weeks have been absolutely hectic for me. But a new academic paper is successfully submitted, and I can finally have a look to see how many changes to the source code would be necessary for seamless integration of Atuin Desktop with the Flatpak sandbox.