Release Artifacts: Sync with axtloss for new Flatpak builds #38

Activity

1. yveszoundi

   added this to the 0.3.1 milestone on Jan 7, 2023
2. yveszoundi commented on Jan 7, 2023

   

   yveszoundi

   on Jan 7, 2023

   MemberAuthor

   More actions

   @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.
3. axtloss commented on Jan 7, 2023

   

   axtloss

   on Jan 7, 2023

   More actions

   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.
4. yveszoundi commented on Jan 7, 2023

   

   yveszoundi

   on Jan 7, 2023

   MemberAuthor

   More actions

   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).
5. axtloss commented on Jan 11, 2023

   

   axtloss

   on Jan 11, 2023

   Last edited by axtloss

   More actions

   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
6. yveszoundi commented on Jan 11, 2023

   

   yveszoundi

   on Jan 11, 2023

   Last edited by yveszoundi

   MemberAuthor

   More actions

   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).
7. axtloss commented on Jan 12, 2023

   

   axtloss

   on Jan 12, 2023

   More actions

   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?
8. yveszoundi commented on Jan 12, 2023

   

   yveszoundi

   on Jan 12, 2023

   MemberAuthor

   More actions

   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.)
9. axtloss commented on Jan 12, 2023

   

   axtloss

   on Jan 12, 2023

   More actions

   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.
10. rimerosolutions

    locked and limited conversation to collaborators on Jan 16, 2023
11. yveszoundi

    converted this issue into a discussion #42 on Jan 16, 2023