Comment 1 for bug 1934510

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