[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 in tests)
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks