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