Comment 11 for bug 1895137

I reviewed rpi-eeprom version 9.0-1ubuntu1 as checked into groovy. This
isn't a full security audit but a very quick gauge of maintainability.

Because this is an architecture-specific review, the usual tooling doesn't
work for this case. This is a slight problem for maintenance, because the
security team may not have sufficient hardware for update preparation or
update testing. We will probably need to rely upon other teams to provide
testing facilities.

The firmwares themselves are blackboxes similar to intel-microcode or
amd64-microcode. The only recourse we have in the face of regressions is
reverting updates and the same will hold with this package as well.

I'm also concerned about the update frequency given in the
debian/changelog file or releases.md file. The security team does not
have the bandwidth to track these updates ourselves. It is unlikely
each one has security relevance, but if Canonical gets too far behind
on these packages, the Ubuntu security team may have trouble importing
new versions.

So, I would like some assurances that another team will be SRUing new
versions of the package for all supported releases on an appropriate
time-scale to manage the risks associated with high-rate-of-change
projects.

Security team ACK for promoting rpi-eeprom to restricted CONDITIONAL
on another team stating that they will provide testing resources and
periodically import updated versions as appropriate.

Thanks