[Bug 1895137] Re: [MIR] rpi-eeprom

[Dave Jones]

> This one is hard to decide as it has binary blobs in the form of
> the RPI firmware. Usually for normal package that would be a denial
> reason, but other microcode delivering packages work the same way.

Just a quick note on this one, in case it changes anything: as rpi-
eeprom is currently intended to migrate to multiverse I assumed it would
be MIR'd to restricted rather than main (as you note: it primarily
consists of the binary blobs for the second stage bootloader).

In contrast, libraspberrypi{-bin,0} contains no binary blobs and should
indeed be targetted to main.

> - Get Foundations-bug subscribed to the package(s)

Now done for both rpi-eeprom and raspberrypi-userland

> - Even not being used there avoid packages to totally fail on install
>  and breaking apt thereby. Please get it to be gracefully-unusable there.
>  Raspbian only publishes for Pi, we do have more arm* models to support.
>  On non Pi arm* HW this is on install:
[snip]

Just to clarify, is this suggesting it should install cleanly on non-pi
arm hardware, but *then* refuse to work (with some appropriate error
message) or should it refuse to install at all e.g. at dependency
resolution time. I'd love to implement the latter but I've no idea how
(is there such a thing as a package that's only available to pi
images?). The former is rather more complex as it means fixing how
linux-firmware-raspi2 installs its boot firmware (which is something
that's been sat on my TODO list for yonks, but it means some rather
invasive flash-kernel changes where we're already carrying a huge
delta).

> - The Diff from 7.5-1 to our 7.8-0 can't be explained by the changelog.
>   It seems we have much more than just the new version.
>   Could you please ensure that the changelog clearly indicates what our Delta
>   over Raspbian is?

Will do (as you've probably guessed this all started out with 7.5 and I
must've bungled the migration of the changelog while dealing with 7.7
then 7.8 (3 days later!).

> - You refer to an empty VCS, having the changes commit-by-commit in this or
>   another one (depending where you push) woud be great. Please fix the VCS
>   entry to point at such a valid repo.

Ah, I was under the misapprehension that the launchpad repo would be
populated by the git-ubuntu import (in other words the Vcs-Browser entry
was "pre-emptive"). As I'm not an uploader for this (or any) package,
would it be more correct to just remove that for now?

> - Please investigate if it makes sense to be arch:all since it depends on
>  arm only packages:

Yup, that's definitely an issue - in fact that's the reason rpi-eeprom's
stuck in proposed because the dependency (libraspberrypi-bin) is
armhf/arm64 only. I've already fixed that in an upload for 8.0 to my PPA
(https://launchpad.net/~waveform/+archive/ubuntu/eeprom), but of course
that's now been superseded by 9.0!

> - Please clarify the Focal situation, the same version is stuck in proposed
>  there as well.

rpi-eeprom on Focal is currently awaiting the SRU of
libraspberrypi{-bin,0} to Focal (LP: #1883111), but as mentioned above
there's also the Arch: all issue. Still the intention is indeed to have
this in the current LTS and Groovy (possibly Bionic as well given the Pi
4 is supported there, but additional bumps to the linux-firmware-raspi2
package may be needed there).

> - Any chance to add some tests verifying the functional integrity of the package
>  to run at build or autopkgtest time?

It should be possible to add their test script for autopkgtest usage
(although it only exercises rpi-eeprom-config that's about as much as we
could safely do). I'll get on with that.

> - Please consider updating to a newer version before you SRU things to
>=Focal

Is it best at this point to fix the existing 7.8 upload, or reject that
and fix all this in a new 9.0 upload? Happy to do whichever is easier
from the MIR/security team's perspective.

> [Dependencies]
> OK:
> - no other Dependencies to MIR due to this
>   Only libraspberrypi-bin out of raspberrypi-userland which is part of this MIR

I think libraspberrypi0 is needed from raspberrypi-userland too as
that's a dependency of libraspberrypi-bin

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to raspberrypi-userland in Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

Status in raspberrypi-userland package in Ubuntu:
  New
Status in rpi-eeprom package in Ubuntu:
  Incomplete

Bug description:
  [Availability]
  The package is in proposed, pending a correction to Architecture to permit it to migrate to multiverse (LP: #1884748).

  [Rationale]
  The package is required for updating the boot EEPROM on the Raspberry Pi 4.

  [Security]
  I am not aware of any open CVEs against the tools in rpi-eeprom.

  [Quality assurance]
  The package is extensively used upstream on Raspbian, and is obviously actively maintained there. There is no meaningful test suite included in the package, but the contents of the package are regularly exercised in image testing (and boot EEPROM testing).

  [UI standards]
  Manual pages are included for both utilties included in the package (rpi-eeprom-config and rpi-eeprom-update), but localization is missing from both utilities at present. However, most users will never use these utilities directly. Rather, they are typically launched by a systemd service on boot which automatically applies new versions of the boot EEPROM.

  [Dependencies]
  The package depends on binutils, python3, and pciutils, all of which are already in main. It also depends on linux-firmware-raspi2 and libraspberrypi-bin which are the subject of other MIRs (LP: #1867813, LP: #1895133).

  [Standards compliance]
  The package installs its scripts under /usr/bin.

  [Maintenance]
  The package is maintained by the Ubuntu Foundations team.

  [Background information]
  As this is a dependency for keeping the boot EEPROM on the Raspberry Pi 4 up to date, the intention is to install this by default in all pi-related images going forward.

  
  ---

  
  [Availability]
  The package is already in universe.

  [Rationale]
  The package is depended upon by the new raspi-common seed, for inclusion in all pi related images. The reason for its inclusion in the seed is that the libraspberrypi-bin package provides the vcgencmd and dtoverlay utilities which are both required by rpi-eeprom (the subject of a separate MIR, LP: #1895137) for updating the boot EEPROM on the Raspberry Pi 4.

  The libraspberrypi0 package is a dependency of libraspberrypi-bin and
  both are built from the raspberrypi-userland source package.

  [Security]
  I am not aware of any open CVEs against the tools in libraspberrypi-bin or the libraries in libraspberrypi0.

  It may be worth noting that the -bin package installs a udev rule (in
  /lib/udev/10-local-rpi.rules) permitting members of the "video" group
  access to /dev/vchiq, which is required for all the VC related
  utilities (including vcgencmd, raspivid, and raspistill) to be
  operated without root privileges.

  [Quality assurance]
  The package is extensively used upstream on Raspbian, and is obviously actively maintained there. There is no meaningful test suite included in the package, but the contents of the package are regularly exercised in image testing (and boot EEPROM testing).

  [UI standards]
  I've added manual pages for all the utilities I'm able to, but localization is missing from all utilities at present. However, most users will never use these utilities directly (bar, perhaps, the raspivid and raspistill utilities for the camera module). Instead the most common scenario is that the utilities will be used (invisibly) by other scripts (e.g. rpi-eeprom-update) for maintenance purposes like manipulating the boot EEPROM.

  [Dependencies]
  As noted above, libraspberrypi-bin depends on libraspberrypi0. It also depends on device-tree-compiler and libc6, both of which are already in main. libraspberrypi0 in turn merely depends on libc6.

  [Standards compliance]
  The package installs its binaries under /usr/bin, and its libraries under /usr/lib. Upstream does not version their API, so the libraries are unversioned.

  [Maintenance]
  The package is maintained by the Ubuntu Foundations team.

  [Background information]
  As noted above, the package is a dependency of the recently added raspi-common seed (https://lists.ubuntu.com/archives/ubuntu-release/2020-September/005086.html). As it is a dependency for keeping the boot EEPROM on the Raspberry Pi 4 up to date, the intention is to install this by default in all pi-related images going forward.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions