Hi, On Tue, 14 Mar 2023 at 22:52, Vishwanath Pai <v...@akamai.com> wrote: > > Hi All, > > I noticed that with the latest update to grub2-unsigned, one of the build > dependencies is gcc-10. > But gcc-10 is not available on bionic. We build ubuntu packages in our build > system from source but > unfortunately we have no way to build the new grub2-unsigned package in our > bionic build > environment. > > Also another dependent package: libfuse3-dev is similarly not available on > bionic. How is > grub2-unsigned being built for the official ubuntu repositories?
src:grub2 provided in a given suite is currently buildable in a given suite. It was changed to exclude building EFI platform code, which is now built by src:grub2-unsigned, once on one series with one toolchain, and reused in all ubuntu releases. Due to multiple recent EFI only vulnerabilties, to reduce security review and maintenance and debugging/compatiblity checking costs, it was decided to split src:grub2 into src:grub2 (with all the unsigned platforms) and src:grub2-unsigned which only contain EFI platform bootloader without any userspace binaries or dependencies. If you observe the builds on launchpad, you will notice that src:grub2-unsigned is built once, and is packaged to ensure that it is a free standing package without any hard runtime dependencies on the host system. I.e. open pad.lv/u/grub2-unsigned, click on a desired version and observe the build https://launchpad.net/ubuntu/+source/grub2-unsigned/2.06-2ubuntu14.1 you will see that it was compiled in Kineitc once, and published in all the suites identically bionic; focal; jammy; kinetic. The build log for each architecture, clearly states that kinetic build-shcroot was used, and that produced binaries can be published and install in both older, same and newer series, due to unique engineering we did in the build process of only that pacakge. The result of that is signed by Canonical Secureboot keys, and published from src:grub2-signed package which in turn has per-series runtime dependencies and versions, but vendors the same identical build of the signed EFI package. It is on our plans to provide a gcc-10 toolchain backport, such that each suite can rebuild the binary package again. However, this will not reproduce the same result, and may introduce security vulnerabilities that rely on the toolchain features provided during build. To reproduce what we have done in the Ubuntu archive, imho it best to redo what we did - stand up Kinetic builder, build the source package in Kinetic chroot, sign it with your own keys, rebuild grub2-signed from scratch pointng at your signed binaries. Note, rebuilding grub2-unsigned alone is not very useful, as it is not used on installed systems at all. As the binaries it produces in the signing tarball, have to be signed (for example we use Launchpad Signing Service provided in the PPA and Archive builders), and then revendored back inside grub2-signed. I am assuming you have your own secureboot signatures, and you rebuild -signed packages yourself with your own signatures. If you do not rebuild signed binaries, and do not resign them with your own secureboot keys, and instead rely on industry wide CA certificates and using Canonical signed secureboot signatures - then you probably already skip rebuilding packages such shim / shim-signed, grub2 / grub2-signed, linux / linux-signed' and thus should also skip grub2-unsigned. Please note, this is the same thing we have been doing with shim / shim-signed packages previously. So please check what you have been internally doing with shim / shim-signed packages. If you do not use Secureboot at all, and the split of platform code that is built by src:grub2 & src:grub2-unsigned of different version is not useful to you, you could patch those to either use a stock toolchain, or revert to making src:grub2 package to generate all bootloader platforms. Depending on what you do, this might be a reasonable approach, however that will not include fixes for all publically known vulnerabilities affecting EFI builds. Please let me know publicly or privately, if this helps, or if you have any further questions. -- okurrr, Dimitri -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
