Ubuntu
u-boot package

  1. Bug #1869792
  2. Comment #4

Comment 4 for bug 1869792

Revision history for this message
Seth Arnold (seth-arnold) wrote :

This is an awkward case, I'm not sure we've got a perfect plan here.

u-boot has been in main for a while; a previous release did need to go through -security but it appears it wasn't for security reasons:

https://launchpad.net/ubuntu/+source/u-boot/2016.01+dfsg1-2ubuntu3

The rpi family does not have any secure boot mechanism. Most of these machines are hobbiest machines, quite often the storage is accessible without even undoing any screws, so it's easy to say the boot process is unlikely to be a security boundary.

So, with that in mind, I looked at only what's new, here:

$ tar tf data.tar.xz
./
./usr/
./usr/lib/
./usr/lib/u-boot/
./usr/lib/u-boot/rpi_3/
./usr/lib/u-boot/rpi_3/u-boot.bin
./usr/lib/u-boot/rpi_3/uboot.elf
./usr/lib/u-boot/rpi_4/
./usr/lib/u-boot/rpi_4/u-boot.bin
./usr/lib/u-boot/rpi_4/uboot.elf
./usr/share/
./usr/share/doc/
./usr/share/doc/u-boot-rpi/
./usr/share/doc/u-boot-rpi/README.Debian
./usr/share/doc/u-boot-rpi/changelog.Debian.gz
./usr/share/doc/u-boot-rpi/configs/
./usr/share/doc/u-boot-rpi/configs/config.rpi_3.gz
./usr/share/doc/u-boot-rpi/configs/config.rpi_4.gz
./usr/share/doc/u-boot-rpi/copyright
./usr/share/lintian/
./usr/share/lintian/overrides/
./usr/share/lintian/overrides/u-boot-rpi
./usr/share/u-boot/
./usr/share/u-boot/rpi-config-migration

$ tar tf control.tar.xz
./
./control
./md5sums
./postinst

The .bin and .elf files are probably safe to treat as binary blobs from rpi and not worry about their maintenance.

The postinst and rpi-config-migration are a bit interesting. I don't understand why they are split apart. I'd feel better if the rpi-config-migration were run rather than sourced, just out of a sense of trying to reduce coupling between parts that are not obviously connected.

There's no shbang line for rpi-config-migration, no set -e directly in that file, and since it uses pipelines heavily, set -o pipefail would probably also be useful.

Security team ACK for promoting u-boot-rpi.

If u-boot deserves a deeper look from the security team, we can arrange that. Giving it a deeper look before 20.04 release feels infeasible, and anyway this has been de-facto 'main' in all but process for a while anyway, right?

Thanks