On April 12, 2022 8:55:56 AM UTC, Arthur Heymans arthur@aheymans.xyz wrote:
Hi
Would it make sense to backport your fix to old releases and bump
those release numbers to a .1 on the end?
Some see releases as mere synchronization tags & nice PR. Some releases are also branches in gerrit but there are none affected by this (latest is 4.12 and it was introduced in 4.13).
As you may know, coreboot distributions (talking of Heads specifically here), take releases tarballs and apply patches where needed on top of it.
In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 for its supported boards. I quickly attempted to backport the relevant patches to 4.13 tarball release, unsuccessfully. The alternative would be to move all 4.13+ coreboot versions to switch to a specific commit in the middle of the current 4.16 release, which doesn't seem to be interesting from a stability perspective for users, moving production board owners to testers of 4.17 coreboot release.
The relevant patchset is on top of 4.16, where I haven't found a proper merging strategy to backport a good patchset onto 4.13. I attempted to find all patches touching the 4.13 introduced new smm2 handler, but conflicts arose when trying to cherry-pick those commits in reverse order in the attempt of creating a patch that would apply successfully on top of 4.13 extracted tarball.
I believe as well that new tarballs for 4.13.1 and newer should have the patchset backported and included and newer branches/tarballs (.1) released, so that all coreboot based distributions can easily point to those new tarballs without each of them having to suddenly point to a specific commit in between releases, 4.16 just having been released, also containing the vulnerability.
There is a precedent where 4.8 was bumped to 4.8.1 because all boards were broken.
I don't have a strong opinion on this. Do people really use the releases in production or are most using git anyway?
In the goal of coreboot release based distributions, and to properly support products/solutions, I am not aware of a lot of projects that are based on coreboot rolling release (git).
If reproducibility of coreboot distribution builds (roms) are also being a goal for those coreboot distribution projects, pointing to a git commit is only good for testing new introduced platforms, not optimal in creating stable releases for already supported platforms, which project codebase changes as well in between coreboot upstream releases.
It's a bit weird to have releases that you'd have to advertise as *don't use*, but I've seen us do that in the past (because issues are quite often just fixed in master).
In an ideal world, each of those projects would have time to test fully rolling releases. But the reality is different. Heads/Skulls/Osboot/libreboot relies on coreboot releases to build ROMs for their supported platforms and users.
Kind regards Arthur
On Tue, Apr 12, 2022 at 12:52 AM Peter Stuge peter@stuge.se wrote:
Arthur Heymans wrote:
I think this issue might affect a lot more systems than I initially
thought.
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org