Package: vboot-utils Version: 0~R106-15054.B-1 Severity: serious Tags: upstream Justification: 1. DFSG-freeness X-Debbugs-Cc: gnu...@cyberdimension.org
Dear Maintainer, The vboot source code has nonfree software in tests/futility/data. If I take bios_link_mp.bin for instance, it's an image meant to be flashed on the boot flash (on the first Chromebook Pixel). So if I do ifdtool -x bios_link_mp.bin it extracts the Management Engine partition which in flashregion_2_intel_me.bin which is not empty: $ ifdtool -x bios_link_mp.bin File bios_link_mp.bin is 8388608 bytes Flash Region 0 (Flash Descriptor): 00000000 - 00000fff Flash Region 1 (BIOS): 00200000 - 007fffff Flash Region 2 (Intel ME): 00001000 - 001fffff Flash Region 3 (GbE): 00fff000 - 00000fff (unused) Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused) The Management Engine firmware is then in flashregion_2_intel_me.bin We can go furthurer with Coreboot source code to verify that it contains nonfree code: $ git clone https://git.review.coreboot.org/p/coreboot.git $ sudo apt install python3-minimal $ python3 coreboot/util/me_cleaner/me_cleaner.py -c flashregion_2_intel_me.bin ME/TXE image detected Found FPT header at 0x10 Found 15 partition(s) Found FTPR header: FTPR partition spans from 0x93000 to 0x108000 ME/TXE firmware version 8.0.20.1513 Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x Checking the FTPR RSA signature... VALID So here we see that the signature is valid, so it contains nonfree code signed by Intel. ifdtool also extracts flashregion_1_bios.bin, and that kind of image should also have nonfree binaries like microcode updates, MRC / FSP binaries, etc inside the "BIOS" partition though I'm unsure how to verify that easily as I'm more used to more recent Coreboot images compatible with cbfstool (here it uses fmap). Though we can at least verify that it contains nonfree microcode quite easily: $ git clone https://review.coreboot.org/p/bios_extract.git $ sudo apt install guix $ guix shell python2 -- python2 ./bios_extract/microcode_extract.py flashregion_1_bios.bin [...] And we then see nonfree microcode: $ ls mcode_upd_0050* mcode_upd_005004F8.bin mcode_upd_005048F8.bin mcode_upd_005090F8.bin mcode_upd_0050D0F8.bin mcode_upd_005028F8.bin mcode_upd_00506CF8.bin mcode_upd_0050A8F8.bin There is more files than just bios_link_mp.bin in this directory, there are even kernel images which lack complete and corresponding source code and that may or may not contain nonfree firmwares. One option here could be to just remove all the files in that directory reguardless of the vboot version. This way if upstream keeps adding more files, they will also not be shipped. Now just removing the tests files might break compilation as the Makefile uses these files, but it might be possible to just disable the tests using files that contain code by patching the Makefile. Also note that I didn't report the bug to upstream (maybe I should have) as they don't have the same policy than Debian. Google may already have the right to redistribute these images (I've no idea what kind of agreement they have with the providers of nonfree software like Intel) as they already redistributed them inside the chromebook themselves, and if they didn't have the right to redistribute them through some other means, they might not have added it in the first place in their source code repository. Though it's also possible that it's also a bug upstream but we have no way to know without bugreporting first. I also started bugreporting that bug inside other distributions like Trisquel which is a downstream of Debian. Since these utilities are widespread maybe we need to coordinate with all the distributions that have policies that require not to ship nonfree software in certain repositories. Guix is also affected (I didn't bugreport yet), Fedora might be affected as well, etc. I'm also not sure if other distros that don't have rules like the DFSG, FSDG, etc would be interested or not as I'm unsure if they have the right to redistribute these binaries or not (it might depend on the jurisdiction they operate in) or if they would even care. -- System Information: Debian Release: 12.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vboot-utils depends on: ii flashrom 1.3.0-2.1 ii libc6 2.36-9+deb12u8 ii libssl3 3.0.14-1~deb12u2 ii vboot-kernel-utils 0~R106-15054.B-1 Versions of packages vboot-utils recommends: ii cgpt 0~R106-15054.B-1 ii coreboot-utils 4.15~dfsg-3 vboot-utils suggests no packages. -- no debconf information
