I reviewed glusterfs 10.1-1 as checked into jammy. This
shouldn't be considered a full audit but rather a quick gauge
of maintainability.

GlusterFS is a clustered network file-system.

- CVE History: 27 CVEs, though the most recent are from
  2018. Issue resolution looks okay. One or two of the later
  CVEs were incomplete fixes for earlier issues.
- Build-Depends on openssl, libtirpc, libxml2, rdma libs.
- Several pre/post inst/rm scripts, dedicated to managing the
  systemd services, adding/removing a dedicated gluster user,
  ensuring an initial config file is created, and dealing with
  compiled python files. Most are generated by debhelper tools
  and look okay.
- No init scripts.
- The glusterfs-server package includes to systemd units, to
  manage the primary GlusterFS daemon and the gluster events
  notifier service. The GlusterFS daemon does depend on rpcbind
  services being enabled/started.

  (The upstream source includes a couple more systemd unit
  files that are not included in any of the binary packages.)
- No dbus services.
- No setuid binaries; however, see Andreas' discussion on the
  fusermount-glusterfs binary. In general, the security team
  would STRONGLY prefer to not have another setuid binary,
  especially for what upstream considers a non-standard use
  case and for one that is a modified version of an existing
  binary that has had its own history of security problems.
- There are several binaries in PATH, mostly as one would
  expect (the service daemon itself, mount utilities, the
  events daemon, and some other specialized utilities.
- No sudo fragments.
- No polkit files.
- No udev rules.
- Tests:
  - it has one basic autopkgtest, a smoke test that creates
    and writes to a mountpoint.
  - As Andreas noted, there is an unused semblance of
    unittest infrastructure. There is a wholly unused tests/
    subdirectory. It's great that upstream gates on tests
    passing, but does nothing for us for testing updates/patches
    we might apply. That's not great.
- No cron jobs.
- As noted, build logs contain some warnings, some of
  them somewhat concerning highlighting where string copy
  operations are performed with a bounds limiter based on the
  length of the source of the copy rather than the size of the
  target. Cursory looks indicate that they may not be an issue,
  and there has been some effort to fix these sorts of things
  in the upstream github.

  There's a couple of warnings about not checking the result
  of calls to setreuid() in contrib/fuse-lib/mount-common.c:59
  which just emphasizes again that it would be best to not
  make the fusermount-glusterfs setuid.

  Nothing concerning in the lintian warnings, though that the
  warning of a lack of symbols tracking in the libraries has
  been silenced is not a great look. (The upstream libraries
  export a defined set of symbols, but don't make use of symbol
  versioning, either.)

- Processes are spawned in a few locations, but look to be
  handled safely (outside of testcases).
- Lots of fiddly memory management happening, memcpys,
  strcpys, etc.
- File IO is okay.
- Logging is complex but okay.
- Minimal use of environment variables, mostly for
  geo-replication, and is okay.
- Privileged function use oustide of fuse is okay.
- RPC can use tls via libssl, looks okay.
- Use of temp files looks to be safe, though TMPDIR is not
  honored.
- As one would expect, significant Use of networking; in
  general looks okay.
- No use of WebKit.
- No use of PolicyKit.

- No significant cppcheck issues that were not likely false
  positives.
- Coverity reported around 500 issues, but spot checking a few,
  they appeared to be false positives or things like failing to
  deallocate memory in a command line tool. Upstream appears
  to be making fixes based on the public Coverity scanner,
  so that's good.
- shellcheck found some issues, including in
  xlators/mount/fuse/utils/mount.glusterfs.in which gets
  installed as /sbin/mount.glusterfs. Not a direct security
  concern and there is at least some effort to address
  shellcheck issues upstream.
- No significant bandit results.

Close to 500 TODO/FIXME type comments which is not a great sign.

I investigated the lintian override for the fortify hardening
check, and it does appear to be a false positive that is being
silenced, and thus okay.

In talking with Andreas, I understand the difficulty with trying
to get the upstream tests (in particular those driven by the
run-tests.sh script) working, but I think it still would be
something that would give us far more confidence when performing
updates, security or otherwise. It would also be good to clarify
explicitly why (debian) symbol versioning is not done, or get
it in place. Neither are blockers for acceptance.

Overall, there seems to be a marked improvement focusing on
quality versus the last time this package was submitted for
an MIR.

Security team ACK for promoting glusterfs to main.