Release Artifacts: Sync with axtloss for new Flatpak builds

[yveszoundi]

Background

axtloss found creative ways to package Entrusted 0.2.4 as Flakpak (based on the Live CD ISO image).

A lot has changed since 0.2.4, and there will be more improvements in 0.3.1

• Faster document processing
• Web interface visual improvements
• ISO image size optimization (~960 MB in 0.2.4, ~670 MB targeted for 0.3.1)
• Several security hardening options (kernel, services sandboxing, more secure configurations, etc.)
• gVisor implementation as container security platform on the Live CD in 0.3.1
• etc.

Request

Sync with axtloss to ensure that 0.3.1 is available as a Flatpak.

Overall changes

None anticipated so far, but there are 2 major updates in the Live CD (boot loader, custom kernel).

[yveszoundi]

@axtloss, I would definitely appreciate your help on this one.

I'm currently targeting the end of February for 0.3.1. I'm still working through couple issues that are mostly arm64 related, but I can provide a pre-release build at some point.

[axtloss]

I would be happy to help with this!
The main part that needs some ironing out currently is how to display the UI, for the current flatpak I just used nativefier to create an electron app which just displays the web ui. A big issue with this is that it doesn't use xdg-portals for the file picker, which blocks the flatak from using any files which it doesn't have explicit access to.

It would probably also make sense to submit the package to flathub so that people can install it more easily.

[yveszoundi]

Thanks a lot!

I'll educate myself a little bit as I haven't tried Flatpak myself yet (despite reading about it once in a while).

[axtloss]

A possible solution for the gui problem would be possible to make the graphical rust app(entrusted_client) communicate with the webserver instead of directly calling podman. We could ship the graphical app directly with the flatpak then.
But I'm not sure if this can be achieved by release 0.3.1

[yveszoundi]

Thanks for giving it more thought.

I've also been considering something among the same lines, that is not too intrusive or "too Flatpak specific". The 0.3.1 release timeline is not set in stones, so it's not a big deal.

What do you think about the following?

• Introduce a new "runtime solution" for a "direct-mode invocation":
  • There are currently 4 supported "runtime solutions" for the CLI or GUI interfaces: podman, docker, nerdctl and lima (via nerdctl).
  • I could introduce a new "runtime" that checks for the entrusted-container binary inside the PATH (within the Flatpak restricted environment). Not sure if entrusted-container could be an AppImage so that all its dependencies are bundled in the Flatpak easily...
• Refactor the entrusted-container component to leverage command-line arguments
  • Introduce CLI arguments (If possible remove completely dependency on environment variables)
  • Remove few hard-coded assumptions (input, output and temporary folders)
• Address remaining concerns in the CI/CD pipeline (xdg-*-portal related dependencies, etc.)
• Refactor the new gVisor support (Live CD only) to also become just "another runtime solution" . gVisor integration would be streamlined but it would still remain the CD-only feature (configuration guardrails).

[axtloss]

So if I understand it correctly, the 'entrusted-container' binary would be able to also talk to the vm and the graphical application would be using entrusted-container as a backend?

[yveszoundi]

The VM component (ISO/QEMU) would disappear in the scenario that I described.

Current State

This is how it currently works inside the VM

HTTP Request -> entrusted-webserver -> entrusted-cli -> entrusted-container (via podman)

nativefier is communicating with entrusted-webserver running inside the QEMU vm. entrusted-container is the key "sanitizer component" that is actually processing documents.

Future State

How it could work

The Desktop graphical interface (entrusted-gui) would talk directly to entrusted-container. Essentially we're removing communication layers (entrusted-webserver and podman).

• We're already in the "Flatpak sandbox": no need to have a triple-sandbox (vm + podman) IMHO.
• There's also some runtime overhead to account for (CPU and memory usage).

entrusted-gui -> entrusted-container (via shell command)

How it could be packaged

Inside the Flatpak, we would now have the following components:

• The graphical interface (entrusted-gui)
• The actual "sanitizer component" (entrusted-container), called by the graphical interface
• Some supporting libraries for the "sanitizer component" (tesseract engine, LibreOffice subset, etc.)

[axtloss]

Oh yeah that would work, we could also use flatpak-spawn(1) to create a secondary flatpak sandbox with possibly stricter permissions in which entrusted-container runs, making it more secure.

[yveszoundi]

Great, I converted the original issue into this discussion and there's a new ticket for the actual implementation (#43).

I'm planning to start the development work next week. I'll reach out once most of the key changes are in place so that it all comes together as nicely as possible.