[MIR] fuse3 as a dependency of qemu 6.0 and GNOME apps

Bug #1934510 reported by Paride Legovini
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
fuse3 (Ubuntu)
Undecided
Unassigned

Bug Description

Please promote the following binary packages built from src:fuse3 to main:

  - libfuse3-3
  - libfuse3-dev

[Availability]

The inclusion of fuse3 in Ubuntu is fairly recent, first being imported in Focal as a sync from Debian, however its predecessor src:fuse from the same upstream (libfuse [1]) has been packaged in Debian since 2002, it's already in main and has been in Ubuntu forever.

The upstream project is "the reference implementation of the Linux FUSE (Filesystem in Userspace) interface" [1] , and can be fully trusted to keep maintaining the package in the foreseeable future.

fuse3 is currently a sync from Debian in Focal, Groovy, Hirsute and Impish.

[Rationale]

QEMU 6.0 added support for FUSE block exports, which allow mounting the guest view of any QEMU block device node as a host file. Debian enabled this feature in src:qemu 1:6.0+dfsg-1~exp0 [3], currently in experimental, by adding a new build-dep on libfuse3-dev [4]. We want to bring this support to Ubuntu when merging qemu 6.0 from Debian, and therefore we need to MIR bin:libfuse3-dev and its runtime counterpart bin:libfuse3-3.

[Security]

The package is a library and won't add daemons, setuid binaries, or anything requiring authentication. (This is contrast with the bin:fuse3 package which ships a setuid binary, but which is not part of this MIR.)

The upstream README.md at [1] has a "Security implications" section which only deals with fuse3, no warning is raised regarding the library.

Given the popularity of the project we can assume that Linus' law applies [5].

[Quality assurance]

There are 0 open bugs in Ubuntu against src:fuse3.

In Debian there are a few bugs against bin:fuse3, including a Serious (=> RC) bug, currently tagged "bullseye-ignore", but considered valid. The bin:fuse3 package is not part of this MIR. (It is likely that we'll want to also MIR bin:fuse3 at some point, and I considered doing so as part of this MIR, but it is more sensible to wait for that RC bug to be fixed before proceeding.)

There are no noteworthy Debian bugs against src:fuse3 or any bin: package part of this MIR.

[Dependencies]

libfuse3-3: libc6 [ok]
libfuse3-dev: libfuse3-3, libselinux-dev [ok]
fuse3: libc6, libfuse3-3, adduser, mount, sed, lsb-base [ok]

[Standards compliance]

$ lintian fuse3_3.10.3-2.dsc
N: 2 hints overridden (2 errors)

The two overridden errors are "source-is-missing" errors for Javascript files which are not used or installed by any binary package:

source-is-missing doc/html/jquery.js line length is 32401 characters (>512)
source-is-missing doc/html/menu.js line length is 695 characters (>512)

The second source-is-missing error looks like a false positive to me (the JS is not minimized). Avoiding the override on jquery would require a +dfsg repacked source, with the extra maintenance it requires. I agree with the overrides in this case.

[Maintenance]
=============

The Foundations Team maintains fuse (v2) so far and we are looking to them if they plan to transition to and own v3 at some point.

--

[1] https://github.com/libfuse/libfuse
[2] https://wiki.qemu.org/ChangeLog/6.0
[3] https://metadata.ftp-master.debian.org/changelogs//main/q/qemu/qemu_6.0+dfsg-1~exp0_changelog
[4] https://salsa.debian.org/qemu-team/qemu/-/commit/9fdcf4181e1c8120e6b7c9059209656469bf499b
[5] https://en.wikipedia.org/wiki/Linus%27s_law
[6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918984

----

From some later work on the Dependencies, here a list of related bugs/issues that need to be resolved to make this happen:

From:
https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041530.html

- https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1934510
- https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1935659
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1935665
- https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1935666
- https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1935667
- https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1935668
- https://github.com/libfuse/libfuse/blob/master/ChangeLog.rst#libfuse-300-2016-12-08
- https://github.com/ceph/ceph/commit/cb0a600acfca76c5b4653e4c6f34c1712a2da9de
- https://gitlab.gnome.org/GNOME/gvfs/-/commit/7a0a06186b6fef07b8fce2360c04fd075fc84ed1
- https://github.com/OpenMandrivaAssociation/grub2/blob/master/grub-2.02-fuse3.patch

Paride Legovini (paride)
Changed in fuse3 (Ubuntu):
assignee: nobody → Paride Legovini (paride)
description: updated
Paride Legovini (paride)
Changed in fuse3 (Ubuntu):
assignee: Paride Legovini (paride) → nobody
description: updated
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (4.0 KiB)

[Summary]
This could be a somewhat straight forward case for the source itself.
It is a bit light on tests, but otherwise fine as it was pre-reviewed
in the former version being src:fuse.

The biggest problem is that we generally don't want duplication if we can avoid it.
In this case I tried but qemu (as the first to pull it into main) would not be able to work with fuse2 as an alternative.

MIR Team NACK until we can transition to fuse3 as a whole under the lead of foundations.
Or at least consider v3 important enough to have it in main concurrently to v2.
I'll give them a call if this is on their radar at all yet.

List of specific binary packages to be promoted to main: libfuse3-3, libfuse3-dev

Recommended TODO:
- tests should be added/improved before this is later on promoted to main
- security will have to do a re-evaluation, but that likely is rather quick
  based on fuse(2) being already in main.

[Duplication]
There is the predecessor in main (same project same source older version).
It was decided in Debian to have both packaged separately - probably for
the many dependencies that still are on the old version.

$ reverse-depends --release impish src:fuse |& grep '^\*' -c
161
$ reverse-depends --release impish src:fuse3 |& grep '^\*' -c
7

There are various use cases for fuse, and the server Team is only touching
very few of them. I wonder if we should wait until fuse3 is more adopted
and then let foundations (who own fuse2) own this one as well.
They have the experience to deal with it from fuse2 already.

Note: I have tried to enable fuse(2) with the qemu build, as it first seems
that it would need 3.8 only for the hole support. But it needs fuse3 in all cases.
Therefore we can not provide the feature as-is with fuse2.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

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

[Security]
OK:
- history of CVEs does not look concerning
        Not that there would be none, but they are identical to "fuse" which
        is in main.
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- 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
- does not deal with system authentication (eg, pam), etc)

Problems:
- does parse data formats - as this is the very nature of what a filesystem
  does.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider in that regard
- no new python2 dependency

Problems:
- does have a test suite that runs at build time
  - But this test suite foes not fail the build upon error.
- does not have a test suite that runs as autopkgtest
- The package has no team bug subscriber (yet)

[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 ...

Read more...

description: updated
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I've updated the bug itself to reflect that this might be foundations territory.

Changed in fuse3 (Ubuntu):
status: New → Incomplete
Revision history for this message
Sebastien Bacher (seb128) wrote :

Desktop would be interested to transition as well, we currently carry GNOME delta over Debian to use the old fuse version.

Revision history for this message
Rik Mills (rikmills) wrote :

Kubuntu would also like to see a transition to fuse3. At the moment fuse2 being apparently mandated on the ISOs due to platform live-common seed (See analysis by vorlon in LP: #1916390), we are blocked from including a couple of things on our ISO that require fuse3, as this then breaks the ISO build. i.e. we cannot update sshfs-fuse dependency of kdeconnect to the latest debian version requiring fuse3, and we also cannot include kio-fuse on the ISO which upstream KDE would like distros to install by default.

tags: added: fr-1486
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

There were dependent bug files to get the remaining old projects updated.
Maybe there were more but I was seeing bug 1935665 - so here as an FYI.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

As part of this we also need to ensure that - aside the lib - also the userspace binaries are properly depended on.

`fuse` and `fuse3` both provide sort of the same binaries with /bin/fusermount3 /sbin/mount.fuse3 vs /bin/fusermount / /sbin/mount.fuse.
Since those two are mutually exclusive we probably want/need an update-alternatives approach for the old name (without the 3 suffix) and have all the dependencies to depend on "fuse3 | fuse" as otherwise this will not be co-installable overall (the libs are, but since the binaries are mutually exclusive you can run into problems).

summary: - [MIR] fuse3 as a dependency of qemu 6.0
+ [MIR] fuse3 as a dependency of qemu 6.0 and GNOME apps
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in fuse3 (Ubuntu):
status: Incomplete → Expired
Paride Legovini (paride)
Changed in fuse3 (Ubuntu):
status: Expired → Incomplete
Revision history for this message
Sebastien Bacher (seb128) wrote :

why is the report incomplete?

another reason we want to see that transition from a desktop perspective, it seems the RDP desktop sharing in gnome-remote-desktop is currently disabled because of it depends on the newer version

Revision history for this message
Paride Legovini (paride) wrote :

I think it's Incomplete because while very desirable the MIR still lacks a driver/owner and a plan of action. When I first opened it I thought I could easily MIR the two packages mentioned in the bug description, but then it became clear that the MIR has a wider scope.

(I set it *back* to Incomplete because the janitor expired it.)

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Seb,
it is incomplete waiting on the many other loose ends on this.
Foundations has since then picked this up and started to clear those, see
=> https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041530.html

Once all these are resolved then fuse3 will be able to be promoted and we can have our dependencies switch over.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Marco submitted upstream PRs for the remaining components so hopefully we should be able to transition next cycle

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

One aspect that I didn't check fully, but that worries me a bit is how can preserve fuse and fuse3 to be installed together (as some out-archive components such as virtual machine additions or other pre-compiled binaries may still depend on libfuse and fusermount).

Now, this is not a problem for the library, but it is for the fuse/fuse3 packages that can't be parallel-installed, despite upstream explicitly renamed fusermount to fusermount3 so that was possible [1].

Now, I'm not sure if the fusermount (symlinked to fusermount3) tool we provide is backward compatible with the mounts that may be created using legacy libfuse, so I think is an aspect to check deeply (it may be just a false alarm, but better to check again).

[1] https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0

Graham Inggs (ginggs)
Changed in fuse3 (Ubuntu):
status: Incomplete → New
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Graham,
what (re-)evaluation do you expect at this point in time - the bugs that you so kindly identified and filed and the changes that you and Marco created are neither all completed nor landed in Ubuntu some other way so far. So without starting a deeper review I can say, this still isn't ready due to all the dependencies not being ready yet.
And since was a missing link so often (not to you but others) I'll add you link list from the mail to the description).

description: updated
Revision history for this message
Graham Inggs (ginggs) wrote :

Hi Christian
It's a bit of a catch-22, we have patches ready but cannot land them in Ubuntu until fuse3 is in main.

Revision history for this message
Paride Legovini (paride) wrote :

Hi, I had a look the list of bugs Christian added to the description. Here is my take on those.

### https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1935659

A patch exists:

https://github.com/OpenMandrivaAssociation/grub2/blob/master/grub-2.02-fuse3.patch

I couldn't spot any upstreaming effort for it. I had a look in the upstream repo, bug tracker and mailing list and apparently fuse3 isn't being considered for the moment.

The patch looks very reasonable, but better double check if it's already used in production by other distros.

As noted in the bug the src:grub2-unsigned binary packages need to be copyable back to to older releases. The packages contain only the EFI binaries, so even if the source pkg Build-Depends on libfuse, the binary packages do not.

Note: this is not the whole story:

<juliank> paride: the goal of grub2-unsigned was to be able to just binary-copy it back like shim, but then things changed because bionic needed special work

but this still seems doable to me.

Status: doable.

### https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1935665

There's an upstream PR opened by lp:~3v1n0 to address this

https://github.com/vmware/open-vm-tools/pull/544/

On 2021-10-06 upstream mentioned that they have an upstream bug report to track it, but no activity since then. The patch isn't small but it's made by several simple changes, however I would NOT feel fully confident to ship it without having it landed upstream first, especially in a LTS.

Status: waiting for upstream.

### https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1935666

There's a patch in active review, ETA difficult to estimate:

https://github.com/ibm-s390-linux/s390-tools/pull/117

I would be -1 for applying the patch as a delta in the Ubuntu package, especially given that upstream requested changed.

Status: waiting for upstream.

### https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1935667

Status: Fix Committed. \o/

### https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1935668

In Progress, effort driven by the Desktop team, fuse3 port of the package ready for review. I think this won't be a blocker.

Status: doable.

### Final thoughts

I think we have two main blockers:

 - open-vm-tools
 - s390-tools

Both have upstream PRs pending, but it's difficult to tell when they'll be merged. Grub will need patching, but maintaining that kind of patch in the Ubuntu grub package is nothing new.

I don't have much MIR experience, but the following course of action seems reasonable to me:

 - MIR fuse3, without immediately demoting fuse2 to universe
 - Move everything we can to fuse3. This will leave open-vm-tools
   and s390-tools out for now.
 - If fuse3 support for the missing packages lands upstream before
   Jammy's feature freeze, then let's proceed with the switch to fuse3
   and demotion of fuse2. This should be our aim.
 - If the above fails, we'll have to live with two fuse implementations
   in Jammy.

I hope this helps!

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thanks Paride, just the check that I needed prior to the MIR team meeting!

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Discussed in the MIR Team, agreed to promote fuse3 now to unblock all the dependency changes.
Please do them now and by that have it show up in mismatches for promotion.

To be clear the plan is to demote fuse2 before the end of the 22.04 cycle.

Changed in fuse3 (Ubuntu):
status: New → In Progress
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Please set this to "Fix Committed" once it shows up in component mismatches.

Jeremy Bicha (jbicha)
Changed in fuse3 (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

FYI, on open-vm-tools PR there have been some news:

> This pull request is being incorporated in the next open-vm-tools release; targeted for Q1 2022.

See https://github.com/vmware/open-vm-tools/pull/544/#issuecomment-972880745

Revision history for this message
Steve Langasek (vorlon) wrote :

Override component to main
fuse3 3.10.5-1 in jammy: universe/misc -> main
fuse3 3.10.5-1 in jammy amd64: universe/utils/optional/100% -> main
fuse3 3.10.5-1 in jammy arm64: universe/utils/optional/100% -> main
fuse3 3.10.5-1 in jammy armhf: universe/utils/optional/100% -> main
fuse3 3.10.5-1 in jammy i386: universe/utils/optional/100% -> main
fuse3 3.10.5-1 in jammy ppc64el: universe/utils/optional/100% -> main
fuse3 3.10.5-1 in jammy riscv64: universe/utils/optional/100% -> main
fuse3 3.10.5-1 in jammy s390x: universe/utils/optional/100% -> main
libfuse3-3 3.10.5-1 in jammy amd64: universe/libs/optional/100% -> main
libfuse3-3 3.10.5-1 in jammy arm64: universe/libs/optional/100% -> main
libfuse3-3 3.10.5-1 in jammy armhf: universe/libs/optional/100% -> main
libfuse3-3 3.10.5-1 in jammy i386: universe/libs/optional/100% -> main
libfuse3-3 3.10.5-1 in jammy ppc64el: universe/libs/optional/100% -> main
libfuse3-3 3.10.5-1 in jammy riscv64: universe/libs/optional/100% -> main
libfuse3-3 3.10.5-1 in jammy s390x: universe/libs/optional/100% -> main
libfuse3-dev 3.10.5-1 in jammy amd64: universe/libdevel/optional/100% -> main
libfuse3-dev 3.10.5-1 in jammy arm64: universe/libdevel/optional/100% -> main
libfuse3-dev 3.10.5-1 in jammy armhf: universe/libdevel/optional/100% -> main
libfuse3-dev 3.10.5-1 in jammy i386: universe/libdevel/optional/100% -> main
libfuse3-dev 3.10.5-1 in jammy ppc64el: universe/libdevel/optional/100% -> main
libfuse3-dev 3.10.5-1 in jammy riscv64: universe/libdevel/optional/100% -> main
libfuse3-dev 3.10.5-1 in jammy s390x: universe/libdevel/optional/100% -> main
22 publications overridden.

Changed in fuse3 (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote (last edit ):

Hi,
fuse3 was auto-demoted since the last update, but now open-vm-tools was changed to use fuse3, and shows the expected component mismatch.
@Archive-Admins - please promote binary "fuse3" to main in jammy.

FYI: the bug to get fuse3 into open-vm-tools is bug 1935665

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

bin:fuse3 is now in main - thanks

Revision history for this message
Thomas Bechtold (toabctl) wrote :

Looks like this broke CPC AWS image builds for Jammy. See https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1956949

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Indeed @Thomas, the question now it if everything from Ginggs initial analysis is now ready to move "with it" or if we have to turn back open-vm-tools for now until all is ready.

I have added bug tasks to the obvious ones (gvfs, unionfs-fuse) to bug 1956949.
But eventually all of the identified deps might have to change, especially if they are seeded.
That would be
- https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1935659
- https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1935666
- https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1935667
- https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1935668

I've pinged those cases to check if they all would be ready.

Revision history for this message
Thomas Bechtold (toabctl) wrote :

Reverting open-vm-tools for now would be good to get image builds for Jammy working again.

Revision history for this message
Paride Legovini (paride) wrote :
Revision history for this message
Paride Legovini (paride) wrote :

Let's do a recap:

- grub2: we have a patch, but we still need to apply/test/upload.
- s390-tools: waiting for upstream.
- snapd: I think the proposed fix isn't enough; I proposed
  a change that may do it. Bug moved back to New.
- xdg-desktop-portal: Fix Released.
- ntfs-3g: Fix Released.

Revision history for this message
Paride Legovini (paride) wrote :

snapd is now Fix Released, no movements in grub2 and s390-tools.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers