[MIR] libflatpak0

[Jeremy Bícha]

Many applications have Flatpak integration using libflatpak. The Ubuntu desktop team would like libflatpak0 in main so we can easily build such applications. It takes a lot of work to make these dependencies optional and sometimes that is not possible. We don't need the Flatpak functionality to work by default and do not expect any other Flatpak packages to be installed by default.

Default packages that have flatpak integration:
- gnome-control-center (application panel).
- malcontent (parental controls)

Availability
============
In Universe, builds for all architectures and in sync with Debian.

Rationale
=========
Multiple default packages have libflatpak as a dependency, including malcontent (LP: #1892456).

Security
========
This will need a Security review.

https://security-tracker.debian.org/tracker/source-package/flatpak

There have been two CVEs, both have been fixed in all supported Ubuntu releases.

More recently, there is LP: #1815528

Quality Assurance
=================
Bug subscriber: should be Ubuntu Desktop Bugs

https://bugs.launchpad.net/ubuntu/+source/flatpak
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=flatpak
https://github.com/flatpak/flatpak/issues

tests are run as build tests (with dh_auto_test) and installed autopkgtests on Debian and Ubuntu.
https://ci.debian.net/packages/f/flatpak
http://autopkgtest.ubuntu.com/packages/f/flatpak

UI Standards
============
N/A

Dependencies
============
All in main except for libostree-1-1 (LP: #1892454)

Standards Compliance
====================
Package uses standards version 4.5.0.

Maintenance
===========
- Actively developed upstream
https://github.com/flatpak/flatpak

- Maintained in Debian by the pkg-utopia team but more specifically, it is maintained by Simon McVittie (smcv) who maintains Flatpak, ostree, xdg-dbus-proxy, xdg-desktop-portal and xdg-desktop-portal-gtk.

short dh7 style rules, dh compat 10

[Jeremy Bícha (jbicha)]

This is incomplete because it's missing an ostree MIR. Also, we're looking into adjusting xdg-desktop-portal to not require libflatpak.

If it's not a problem for the MIR Team, we'd like to keep it as Incomplete because the Desktop Team may reconsider whether we want libflatpak in main later and it's nicer if we don't have to redo this paperwork.

[Launchpad Janitor (janitor)]

[Expired for flatpak (Ubuntu) because there has been no activity for 60 days.]

[Robert Ancell (robert-ancell)]

Re-opening this as this is something that we think will be necessary for Ubuntu desktop. It's better for everyone that gnome-control-center uses libflatpak and not some binary wrapper. Binary wrappers are just API that's really easy to break :)

The main difficulty is how to handle OSTree, as putting libostree in main is effectively fully supporting OSTree, which is not something we want to do as it's not a technology used in default Ubuntu. libflatpak is fine, as it's mostly just glue code that does nothing without the flatpak daemon installed. So we need some ideas on what to do with ostree.

[Robert Ancell (robert-ancell)]

Asked on the Flatpak project for ideas on this:
https://github.com/flatpak/flatpak/issues/3091

[Robert Ancell (robert-ancell)]

Discussion about libflatpak dependency in gnome-control-center:
https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/429

[Robert Ancell (robert-ancell)]

We discussed this at a sprint and decided that due to the difficultly in bringing flatpak/ostree/selinux into main we'll use dlopen for packages in main that use libflatpak. This will require us to carry patches for this. We can re-open this if those turn out not to be a suitable long term solution.

[Robert Ancell (robert-ancell)]

Re-opening this. We want to get malcontent into main, which depends on libflatpak.

[Didier Roche-Tolomelli (didrocks)]

Missing team subscription: can you ensure desktop-packages is subscribed before analyzing the MIR please?

[Didier Roche-Tolomelli (didrocks)]

Setting as incomplete until getting more information, feel free to reassign once ready.

[Sebastien Bacher (seb128)]

The right team is subscribed now

[Didier Roche-Tolomelli (didrocks)]

[Summary]
ACK from the MIR team.
This does need a security review, so I'll assign ubuntu-security list specific binary packages to be promoted to main

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
- no other Dependencies to MIR due to this apart from ostree which is listed above

[Embedded sources and static linking]
- no embedded source present
- no static linking

[Security]
- history of CVEs does not look concerning
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop (apart in tests)
- does not deal with system authentication (eg, pam), etc)

Problems:
- it does run a daemon as root and interacts with cgroups. This isn’t part of the binary package we are promoting, however, as we have the rule "if the source in is main, we can promote any other binary package without a new MIR", this will need to be checked right now with the security team.

[Common blockers]
OP:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest. Some tests are marked as flaky
- The package has a team bug subscriber
- translation presents?
- not a python/go package, no extra constraints to consider int hat regard
- no new python2 dependency

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks

[Seth Arnold (seth-arnold)]

There's something from the polkit rules that worries me. I don't think we want the rules to be this open. Could someone more conversant with polkit rules give them a read and report back if this is something we really want?

Something that specifically worried me:

          - Normal users need admin authentication to install software
            system-wide.
          - Note that we install polkit rules that allow local users
            in the wheel group to install without authenticating.

Thanks

[Seth Arnold (seth-arnold)]

I reviewed flatpak 1.10.2-1ubuntu1 as checked into hirsute. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

flatpak is an application packaging and sandbox tool.

- CVE History:
  we have six cves in our database, they appear to have been handled well,
  quickly, and even proactively when a snapd issue was found they went
  looking for the same flaw family.

  The coverity discoveries I reported to them were handled pretty well
  considering it was a bit of a firehose; they said they were going to set
  up the free coverity scan instance to keep a handle on issues going
  forward.
- Build-Depends?
  enough that listing them all feels useless; uses gnupg, fuse, dbus,
  bubblewrap, malcontent, polkit, libxml2, ostree -- complicated code with
  tendrils.
- pre/post inst/rm scripts?
  mostly automatically added contents; creates _flatpak user; populates
  the catalog during install; seems safe
- init scripts?
  none
- systemd units?
  system flatpak-system-helper.service
  user flatpak-oci-authenticator.service
  user flatpak-portal.service
  user flatpak-session-helper.service
- dbus services?
  several, start the system helper service, portal service, oci
  authenticator service, session helper service
- setuid binaries?
  none
- binaries in PATH?
  in flatpak, flatpak
  in libflatpak-dev flatpak-bisect, flatpak-coredumpctl
- sudo fragments?
  only in documentation
- polkit files?
  extensive polkit rules, someone else giving them a double-check would be
  wonderful. I'm not sure I like this:

          - Normal users need admin authentication to install software
            system-wide.
          - Note that we install polkit rules that allow local users
            in the wheel group to install without authenticating.

- udev rules?
  none
- unit tests / autopkgtests?
  A huge and uncertain number of tests are run during the build. There's a
  flatpak-tests binary package, I have no idea what it does, but it might
  also come in handy.
- cron jobs?
  none
- Build logs:
  A fair number of things, but for the size of the project a pretty
  reasonable ratio.

- Processes spawned?
  Significant spawning other processes; I'm concerned about parsing the
  .desktop files but didn't find any issues in my simple tests.
  Historically glib-based programs have done a decent job in this area.
- Memory management?
  Significant use of autofree tooling. Coverity reported some memory
  leaks, but they were all small and temporary, and upstream fixed them
  the 'right' way very quickly and enthusiastically.
- File IO?
  skipped
- Logging?
  spot checks look fine
- Environment variable usage?
  OSTREE_DEBUG_HTTP environment variable asks soup to log http bodies
  FLATPAK_GL_DRIVERS looks like it can give alternative paths to drivers
  FLATPAK_BWRAP looks like it can replace bubblewrap
  FLATPAK_SYSTEM_CACHE_DIR is used to create mode 755 directory
  FLATPAK_SYSTEM_HELPER_ON_SESSION switches between system and session dbus
  FLATPAK_TRIGGERSDIR indicates a directory of 'triggers' to run
  FLATPAK_REVOKEFS_FUSE selects an executable to use when revoking a fuse mount
  SSH_AUTH_SOCK appears to be copied to applications
  ...

[Andrew Hayzen (ahayzen)]

tl;dr; Flatpak currently considers remotes as trusted, so after you have added one with a password at system level, you don't need a password to install apps for that remote.

I don't about how polkit rules work, but this is just a comment describing what happens from a user perspective with flatpak. If you want to tighten it, I suggest discussing with upstream to ensure docs or any other assumptions etc are correct (please also ensure any changes make it into Debian, generally we have been able to avoid diffs with Debian so far - we do have a diff right now as Debian is in freeze).

- Flatpak has two locations that you can add remotes and install apps to, user level and system level. System level ones are available to all users, user level ones are available to just that user
- Adding a flatpak remote or installing an app at *user* level does not require any password

So far I think this all makes sense, the interesting part up for debate is the next part.

- When a remote is added to flatpak at *system* level, it asks for a password to verify the remote
- When an app is installed at *system* level for this trusted remote, it installs without needing a password (as stated in previous comments, assuming the user is in the wheel group)

To try this out you can do the following commands, the remote-add and remote-delete will need a password, the install and uninstall won't.

$ flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
$ flatpak install kdeapps org.kde.kate
$ flatpak uninstall org.kde.kate
$ flatpak remote-delete kdeapps

[Christian Ehrhardt  (paelzer)]

There has been not further update for too long, for now we consider it invalid.
Feel free to re-open if there is effort backing it up and motivation to bring it to main.