[MIR] libflatpak0

Bug #1812456 reported by Jeremy Bicha on 2019-01-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
flatpak (Ubuntu)
Ubuntu Security Team

Bug Description

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)

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

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

This will need a Security review.


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


tests are run as build tests (with dh_auto_test) and installed autopkgtests on Debian and Ubuntu.

UI Standards

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

Standards Compliance
Package uses standards version 4.5.0.

- Actively developed upstream

- 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 Bicha (jbicha) on 2019-01-18
Changed in flatpak (Ubuntu):
status: New → Incomplete
description: updated
description: updated
Will Cooke (willcooke) on 2019-01-22
summary: - [MIR} libflatpak
+ [MIR] libflatpak
Revision history for this message
Jeremy Bicha (jbicha) wrote : Re: [MIR] libflatpak

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.

Jeremy Bicha (jbicha) on 2019-02-12
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in flatpak (Ubuntu):
status: Incomplete → Expired
Changed in flatpak (Ubuntu):
importance: Undecided → Medium
status: Expired → Triaged
status: Triaged → Confirmed
Revision history for this message
Robert Ancell (robert-ancell) wrote :

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.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

Asked on the Flatpak project for ideas on this:

Revision history for this message
Robert Ancell (robert-ancell) wrote :

Discussion about libflatpak dependency in gnome-control-center:

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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.

Changed in flatpak (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
Robert Ancell (robert-ancell) wrote :

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

Changed in flatpak (Ubuntu):
status: Won't Fix → Triaged
status: Triaged → New
description: updated
summary: - [MIR] libflatpak
+ [MIR] libflatpak0
description: updated
description: updated
description: updated
Didier Roche (didrocks) on 2020-08-25
Changed in flatpak (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
Revision history for this message
Didier Roche (didrocks) wrote :

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

Revision history for this message
Didier Roche (didrocks) wrote :

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

Changed in flatpak (Ubuntu):
status: New → Incomplete
assignee: Didier Roche (didrocks) → nobody
Revision history for this message
Sebastien Bacher (seb128) wrote :

The right team is subscribed now

Changed in flatpak (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
status: Incomplete → New
Revision history for this message
Didier Roche (didrocks) wrote :

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

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

- 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

- 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)

- 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]
- 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]
- 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]
- 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

Changed in flatpak (Ubuntu):
assignee: Didier Roche (didrocks) → Ubuntu Security Team (ubuntu-security)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.