[MIR] libostree-1-1

Missing team subscription: can you ensure desktop-packages is subscribed before analyzing the MIR please?

Setting as incomplete until getting more information, feel free to reassign once ready.

Robert, you didn’t get desktop-packages subscribed again, mind doing so before resetting to NEW and assigning? Thanks!

I've subscribed the right team now

[Summary]
MIR team ACK under the condition that:
- https://bugs.launchpad.net/ubuntu/+source/libselinux/+bug/1892455 question is answered (for me as well, this component is already in main).
- Which binary package will be needed to be promoted (the minimum set)? It seems only that libflatpak0 is only depending on libostree-1-1. Can you confirm this is the expected one to be promoted and only this one?
- Will need a security review (already assigning, even if the questions needs to be answered in parallel)

TODOs:
- answer the 2 questions above
- one suggestion below for running more tests on non s390x.
- have the security team +1

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
no other Dependencies to MIR due to this if limited to libostree-1

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

[Security]
OK:
- history of CVEs does not look concerning (see comment in description)
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- 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 (only for tests)
- does not deal with system authentication (eg, pam), etc)

Problems:
ostree-boot has a some code executing as root (systemd generator and systemd system service) and interacts with selinux. It’s not part of what is supposed to be promoted. However, as we have the rule "if the source is in main, you can get other binary packages part of this source promoted without a MIR", it will need to be checked this cycle.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider in that regard

[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
- Debian is on the current release, we are one release behind due to sync freeze.
- promoting this does not seem to cause issues for MOTUs that so far for who maintained the package
- no massive Lintian warnings (overrides are well explained)
- d/rules is rather clean
- Does not have Built-Using

Note: the package is very well maintained, and any override, changes in rules, that needs explanation are commented.
One flaky test is skipped, with a long description which demonstrates that this has been thought about (but not reported upstream maybe?).

TODO:
- it may be interesting to set OSTREE_TEST_ALLOW_RANDOM on non s390x from the description in package build and autopkgtests. Mind checking that with Debian?

[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 use of setuid (apart ...

- libselinux is already in main, that was my mistake thinking it was in universe.
- Only the binary package libostree-1-1 is required to be in main. The reset can remain in universe.

I reviewed ostree 2020.8-2 as checked into hirsute. This shouldn't be
considered a full audit but rather a quick gauge of maintainability. I
didn't make any effort to find which portion of the sources correspond
with the exact binary package that is under discussion.

ostree is a tool to manage giant farms of hardlinks and boot configurations
with a goal of providing transactional system updates, complete with
chain-of-trust using gpg.

I did not inspect ostree from this perspective at all -- the security team
is not interested in supporting ostree as a system management tool.

- CVE History:
  None in our database
- Build-Depends?
  Includes gpg, libgpgme-dev, among others
- pre/post inst/rm scripts?
  The ostree and ostree-boot package maintainer scripts have some dracut
  and grub configuration file handling, systemd service management, and
  will update the initrams
- init scripts?
  None
- systemd units?
  Not inspected, only in ostree-boot and ostree-tests
- dbus services?
  None
- setuid binaries?
  None
- sudo fragments?
  None
- polkit files?
  None
- udev rules?
  None
- unit tests / autopkgtests?
  Some tests run during the build, not inspected
- cron jobs?
  None
- Build logs:
  A lot of doc warnings; nothing code-related stood out

- Processes spawned?
  A lot of process spawning; some using arrays, some using strings with
  quoted filenames (presumably so the user could put pipelines into EDITOR
  or VISUAL environment variables)
- Memory management?
  Stack allocation is used a lot more often than I'd like.
  Because it's C, there's necessarily a lot of memory management and some
  of it is very fiddly. I'm pretty sure I found bugs, though maybe they
  just lead to crashes and memory leaks.
- File IO?
  Extensive file IO -- some file operations rely upon umask having a
  sane value for the files to have sane permissions. File paths come
  from packages. A lot of operations are done on files as instructed by
  whatever is the equivalent of packages -- xattrs, setuid/setgid bits,
  etc. It's basically a full package manager tool. The inputs must
  be safe.
- Logging?
  Extensive logging; I did spot-checks and didn't find errors.
- Environment variable usage?
  Moderate use, some are validated and some are used as-is without any
  verification at all. Probably fine.
- Use of privileged functions?
  Extensive. ostree is a general system management tool. Spot checks of
  calls looked careful but I did not do full call hierarchy checks to see
  if all inputs to privileged functions were properly sanitized.
- Use of cryptography / random number sources etc?
  Uses an embedded soup to do some https validation. It wasn't obvious
  that it's correct but it did go to effort to pass the system CA store,
  so someone at least tried.
- Use of temp files?
  I'm slightly worried about the random number use for XXXXXX files; it is
  using non-cryptographic tool. It's probably fine and I'm a worry-wart.
- Use of networking?
  Yes, some, I didn't closely inspect it. What I did see looked primarily
  client-oriented rather than server-oriented
- Use of WebKit?
  None
- Use of PolicyKit?
  None

- Any significant cppcheck results?
  None
- Any si...