[MIR] boot-managed-by-snapd

[Dominik Viererbe]

[Availability]
The package boot-managed-by-snapd is already in Ubuntu universe.
The package boot-managed-by-snapd build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64
Link to package https://launchpad.net/ubuntu/+source/boot-managed-by-snapd

[Rationale]
 - The package boot-managed-by-snapd is required in Ubuntu main for subiquity so that when the user does a hybrid install, it installs the replacement package.
 - The package boot-managed-by-snapd will generally be useful for a large part of
   our user base
 - The package boot-managed-by-snapd is a new runtime dependency of package subiquity that
   we already support
 - There is no other/better way to solve this that is already in main or
   should go universe->main instead of this.
 - There is no definitive deadline, but it would be great and useful for testing of the canary iso to have the
   package boot-managed-by-snapd in Ubuntu main (the sooner the better).

[Security]
 - Because this package new (exists since May 2023) there is
   no security history at all.
 - no `suid` or `sgid` binaries
 - no executables in `/sbin` and `/usr/sbin`
 - Package does not install services, timers or recurring jobs
 - Package does not open privileged ports (ports < 1024)
 - Package does contain extensions to security-sensitive software (bootloader)

[Quality assurance - function/usage]
 - The package works well right after install

[Quality assurance - maintenance]
 - The package is new and does not have any open bugs
   - Ubuntu https://bugs.launchpad.net/ubuntu/+source/boot-managed-by-snapd/+bug
 - The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
 - The package does not run a test at build time because it contains
   autopkgtests that test for regressions when in proposed.
 - The package runs an autopkgtest, and is currently passing for mantic amd64/arm64
   https://autopkgtest.ubuntu.com/packages/boot-managed-by-snapd
 - This package is minimal and will be tested implicitly together with the canary ISOs

[Quality assurance - packaging]
 - debian/watch is not present because it is a native package
 - debian/control defines a correct Maintainer field
 - This package does not yield massive lintian Warnings, Errors
 - Recent build logs of the package boot-managed-by-snapd
   - mantic amd64: https://launchpad.net/ubuntu/+source/boot-managed-by-snapd/1/+build/26277455
   - mantic arm64: https://launchpad.net/ubuntu/+source/boot-managed-by-snapd/1/+build/26277456
 - Lintian overrides are not present
 - This package does not rely on obsolete or about to be demoted packages.
 - This package has no python2 or GTK2 dependencies
 - The package will be installed by default, but does not ask debconf
   questions higher than medium
 - Packaging and build is easy, link to debian/rules:
   https://git.launchpad.net/ubuntu/+source/boot-managed-by-snapd/tree/debian/rules

[UI standards]
 - Application is not end-user facing (does not need translation)

[Dependencies]
 - No further depends or recommends dependencies that are not yet in main

[Standards compliance]
 - This package correctly follows FHS and Debian Policy

[Maintenance/Owner]
 - Owning Team will be Foundations
 - Team is already subscribed to the package
 - This does not use static builds
 - This does not use vendored code
 - This package is not rust based
 - The package has been built in the archive more recently than the last
   test rebuild

[Background information]
- The Package description and included README explains the package well

[Dominik Viererbe (dviererbe)]

$ lintian --pedantic boot-managed-by-snapd_1.dsc
P: boot-managed-by-snapd source: package-uses-old-debhelper-compat-version 12
P: boot-managed-by-snapd source: silent-on-rules-requiring-root [debian/control]

[Julian Andres Klode (juliank)]

The autopkgtests are skipped on the cloud because installing the package would remove shim-signed which would render the cloud VMs unbootable, but they can be run locally in a container setup (so they would also work in armhf, but oh well, no armhf version of the package or the test depends).

[Julian Andres Klode (juliank)]

I have uploaded version 2 with reworked tests that do not install the generated binary using test Depends, but from inside the script, which should hopefully make them pass now, it works locally in VMs and containers.

[Łukasz Zemczak (sil2100)]

The autopkgtest issues are known to Julian - they're apparently not really feasible to run on out autopkgtest environment. But he's investigating possibilities of working around that to still get some tests running.

In the meantime, I'll promote this package retroactively, under the circumstances that it's a Canonical-maintained (Foundations) package and used on our canary images anyway. Julian and me will be tracking this and addressing any concerns from the MIR and security teams as things go.

[Łukasz Zemczak (sil2100)]

$ change-override -S -s mantic-proposed boot-managed-by-snapd -c main
Override component to main
boot-managed-by-snapd 2 in mantic: universe/utils -> main
boot-managed-by-snapd 2 in mantic amd64: universe/utils/optional/100% -> main
boot-managed-by-snapd 2 in mantic arm64: universe/utils/optional/100% -> main
Override [y|N]? y
3 publications overridden.
$ change-override -S -s mantic boot-managed-by-snapd -c main
Override component to main
boot-managed-by-snapd 1 in mantic: universe/utils -> main
boot-managed-by-snapd 1 in mantic amd64: universe/utils/optional/100% -> main
boot-managed-by-snapd 1 in mantic arm64: universe/utils/optional/100% -> main
Override [y|N]? y
3 publications overridden.

[Julian Andres Klode (juliank)]

Tests are passing now in v2

[Julian Andres Klode (juliank)]

We do not get triggered by grub or anything like that which would have been nice, but then we would have needed to add test Depends and they might not be installable or stuff and it would be weird, but also aside from kernel, we conflict with the actual binary package so it should be ok.

[Christian Ehrhardt  (paelzer)]

Hi,
wow this is different to what I expected by just seeing the title.
This is really - as you say in the readme - essentially is a dummy package.
It has a very special purpose and a way to do that via packaging meta-data.
But it does not hold any code, aside from the apt hooks.
You already have added tests and all that I can see makes me rather confident.

There is no point in copy&pasting the usual MIR review template for this case and say "n/a" to almost every entry, hence you'll see a minimal form with just what is worth to state in this case.

Review for Package: boot-managed-by-snapd

[Summary]
- MIR team ACK
- This does not need a security review
- List of specific binary packages to be promoted to main: boot-managed-by-snapd

[Applicable checks]
- There is no other package in main providing the same functionality.
- no other Dependencies to MIR due to this
  (libjson-c5 and libc6 are in main)
- no embedded source present
- While there is no history on anything, and thereby not on CVEs I can OTOH not see the attack surface either.
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest

---

Recommended TODOs (all are really optional):

#1
The only thing I'd recommend before calling this package fully complete and ready for prime time is a clear statement of the "possibility" to do what it tries to protect one from doing.
You said this will be a dependency of subiquity for a hybrid install, I haven't heard enough of that architecture yet, but either way I'm sure the moment this is out there will be the question "but I do not want to be protected and be able to do this?".

There should be a place that clearly states either (whatever applies):
a) you really shouldn't do this, but if you insist this is how you'd do (but better prepare for damage)
b) you really shouldn't do this, and you shouldn't try as it is impossible because reason

This place wherever you'd host it should then be linked from the README file and/or set as package homepage or any such to make it easy to find (up to you).

What I mean is that it is great that you want to protect users from shooting in their feet.
But one thing I have learned is that whenever you block something, people want to try it even more.
So how about adding the answer to that question right away?

#2
The purpose of this package and the ways it operates are strange.
How would you feel about extending the Readme.md even more and putting it into docs?
Right now it only had copyright and changelog, both not helpful.
So all I have as a user with this installed is apt-cache show, which isn't too detailed.

#3
One can install this on a non-booting system. E.g. a LXD container.
Can you think of that ever becoming an issue?
If so, should we somehow prevent this to only be installed in the case a system is really managed by snapd (if we can detect that in dependencies in some way)?

[Christian Ehrhardt  (paelzer)]

Since it was promoted already, let me set the final state.
I'm adding the expected per-release tasks for promotion in older releases along bug 2020466 bringing this to jammy.

[Brian Murray (brian-murray)]

Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release.