Hi Denis, Apologies that this has caused problems for you. This is just some old test data used to confirm that the parser in the command line utility works, and I don't think anyone thought about the redistribution legality implications of putting those images into the repo. I agree that it's not a good situation and we should try to fix it.
vboot upstream is Google. I am not a lawyer but I believe that Google has a license to redistribute these firmware images in binary form, but I'm not sure about specifics for further re-redistribution. I would definitely not recommend taking this as an invitation to reverse engineer anything that you otherwise don't have the right to. There is no real reason for these binaries to be in those test fixtures — the point of the tests is just to verify parsing for vboot data structures, the actual contents of the file are not really relevant. So I think the easiest solution here is to just delete the offending contents from the images. I have opened a bug for this in Google's public tracker that you can follow here if you want: https://issuetracker.google.com/issues/374385985 . However, changing this will require some effort since the images need to be re-signed after modification and probably require some massaging to ensure the tests still work as intended afterwards, so we may need some time to find someone who has the time to take care of this (personally, I'm unfortunately a bit too busy at the moment). On Sat, Oct 12, 2024 at 8:09 AM Denis 'GNUtoo' Carikli <gnu...@cyberdimension.org> wrote: > > Hi, > > As part of my work on GNU Boot, I found nonfree software in vboot[1] in > tests/futility/data. The same binaries also probably have free software > with missing corresponding source code but I didn't take the time to > confirm that yet. > > We'll take bios_link_mp.bin as an example. As many people know, is used > in the first Chromebook pixel, and it's easy to extract things like the > Management Engine firmware (with ifdtool -x) and to verify it with > me_cleaner (though I'm unsure how to print which partitions it has and > print that they are verified). It's also possible to extract things > like the MRC binary as well with cbfstool (with cbfstool layout and > then using the BOOT_STUB region of fmap). > > Several distributions ended up using vboot source code to make some > vboot-utils packages. It includes distributions like Debian, Fedora, > Guix, Trisquel, etc. So these distributions ended up redistributing the > mrc.bin for instance when they published the source version of the > vboot-utils package. > > Since all these distributions have repositories where redistributing > nonfree software is forbidden, they automatically have a bug to solve > here so I started bug reporting to them. > > The distributions could also workaround and somehow remove the binaries > from the source they publish but this then brings a question of > maintenance over time, so this is what bring me here. > > Questions on vboot: > ------------------- > Who is the vboot upstream, is it Coreboot or is it Google? Who should > we discuss with when trying to understand if it's possible to find a > solution. > > Does anyone redistributing the vboot source code also has the right to > distribute the binaries as-is (including things like Intel Microcode)? > Since they come with no licenses there is also nothing that forbids > reverse engineering, right? > > Would it be possible to somehow remove or move the binaries somewhere > else like in a separate git repository and make them optional in the > tests? Or should we create free binaries somehow? Though I fear that > the later somehow defeat the intent of the tests. > > References: > ----------- > [1]https://review.coreboot.org/vboot.git > > Denis. > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
