[Summary] 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. I'll need to discuss and co-ack with other MIR Team members and also need security to have a word.
For now call it "ok enough to get security review", but there are enough todos listed for you to start right away - for that I'll also mark it incomplete. Set it back to new once the mentioned TODOs are done for re-evaluation. This does need a security review, so I'll assign ubuntu-security List specific binary packages to be promoted to main: rpi-eeprom Info: In this cases this isn't from Debian but from Raspbian and the upstream is https://github.com/raspberrypi/rpi-eeprom Required TODOs: - Get Foundations-bug subscribed to the package(s) - 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: Unpacking rpi-eeprom (7.8-0ubuntu2) ... Setting up linux-firmware-raspi2 (1.20200601+arm64-0ubuntu3) ... Error: missing /boot/firmware, did you forget to mount it? dpkg: error processing package linux-firmware-raspi2 (--configure): installed linux-firmware-raspi2 package post-installation script subprocess returned error exit status 1 Setting up binutils-common:arm64 (2.35-3ubuntu1) ... Setting up libctf-nobfd0:arm64 (2.35-3ubuntu1) ... Setting up libraspberrypi0 (0~20200520+git2fe4ca3-0ubuntu2) ... dpkg: dependency problems prevent configuration of rpi-eeprom: rpi-eeprom depends on linux-firmware-raspi2 (>= 1.20190819); however: Package linux-firmware-raspi2 is not configured yet. dpkg: error processing package rpi-eeprom (--configure): - 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? - 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. Recommended TODOs: - Please investigate if it makes sense to be arch:all since it depends on arm only packages: rpi-eeprom : Depends: libraspberrypi-bin but it is not installable Depends: linux-firmware-raspi2 (>= 1.20190819) but it is not installable - Please clarify the Focal situation, the same version is stuck in proposed there as well. - Any chance to add some tests verifying the functional integrity of the package to run at build or autopkgtest time? - Please consider updating to a newer version before you SRU things to >=Focal [Duplication] OK: We don't have this package or a similar function. Also The Internet is full of people asking for it - so it is important nad not otherwise available. There is no other package in main providing the same functionality. [Dependencies] OK: - no other Dependencies to MIR due to this Only libraspberrypi-bin out of raspberrypi-userland which is part of this MIR - no -dev/-debug/-doc packages that need exclusion [Embedded sources and static linking] OK: - no embedded source present - no static linking (well roms, but nothing that this rule tried to avoid) Problems: - The ROMs are all prebuilt. Usually this is a "hard no" as Debian packages shall be servicable and buildable from source so one knows what is in there. OTOH packges of similar scope like intel-microcode behave no different :-/ Functional maintenance will be your job so you only can make your own job harder by not having sources, but this needs a security review to make sure they consider this serviceable. [Security] OK: - history of CVEs does not look concerning - does not run a daemon as root - 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 - does not deal with system authentication (eg, pam), etc) Problems: - changes SW stacks below the control of the latter Linux system. This needs a security evaluation. [Common blockers] OK: - does not FTBFS currently - 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 int hat regard Problems: - does not have a test suite that runs at build time - does not have a test suite that runs as autopkgtest These are common issues with such low level things, but how would a drive by contributor test anything. Is there a chance to get the file test/test-rpi-eeprom-config working in a virtual environment and add some guidance (or even an autopkgtest) to do that? [Packaging red flags] OK: - Ubuntu does carry a delta, but it is reasonable and maintenance under control - symbols tracking not applicable for this kind of code. - d/watch is present and looks ok - Upstream update history is ok - Debian update history is non existant, since it is only in raspian - but ok there. - Ubuntu update history is too new to decide - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings - d/rules is rather clean (for a rom build) - Does not have Built-Using Problems: - the current release is not packaged, recently they bumped from 7.8 (what we have to 7.14 and from there quickly to 9.0). It seems ok to stabilize it at the current stage and update afterwards. - 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? Examples: drop rpi-eeprom-images dependency, add flashrom suggest, debian/patches/python3.patch, ... and add reasons for those things please. - The VCS is unpopulated, please update and push changes there [Upstream red flags] OK: - no Errors/warnings during the build - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH - no use of user nobody - no use of setuid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - not part of the UI for extra checks Problems: - no incautious use of malloc/sprintf, well I can't know Since these are blobs to me :-/ - no embedded source copies (but embedded binaries) ** Changed in: rpi-eeprom (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team (ubuntu-security) ** Changed in: rpi-eeprom (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895137 Title: [MIR] rpi-eeprom To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
