[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 packaged
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using
- is not on the lto-disabled list
[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 important open bugs (crashers, etc) in Debian or Ubuntu or Upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
Problems:
- use of setuid for e.g. fusermount3 binary
This is the same for fuse(2) so I guess it is fine, but this is another +1
on needing a security review.
P.S. sorry Paride for rejecting after I did ask you to have a look at it; But
for what it is worth I can confirm the the MIR request itself was perfectly
done!
** Description changed:
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 Server Team will maintain the package.
+ 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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1934510
Title:
[MIR] fuse3 as a dependency of qemu 6.0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1934510/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
