On Mon, Mar 30, 2026 at 09:32:48PM +0100, Steve McIntyre wrote: >... > So what *exactly* do you mean by a "vendored compiler"? I don't > *think* we need a special particular build/version of the compiler to > build shim. What we *do* need is to be able to rely on building > consistently reproducible (byte-identical) binaries in > unstable/testing for a short(-ish) period. That period is typically a > few weeks (but potentially up to a few months), depending on how long > it takes for people to reproduce and review our builds during the shim > review process: >...
Do people have to reproduce the build in unstable, or would snapshot work? > Building with the default compiler in unstable is likely to be prone > to changes that will break this reproducibility, and that's why I've > been picking older versions of gcc that won't change in the period we > need. Obviously, building updates for oldstable, stable, etc. is not > likely to be affected here - this is just a worry with a moving-target > compiler like the default we get in *unstable*. Matthias is uploading new versions of old compilers to unstable all the time, like we had two updates of gcc-11 this month. > Shim is also quite special compared to other packages in Debian in > that we're very unlikely to produce new shim packages more than 2 or 3 > times per stable release; that's typically just in a small window when > we bump to a new upstream version then perform one or two cycles of > tweaks and bugfixes on that. Once we've done the review and submitted > to Microsoft for signing, the base shim source package doesn't > change. People *can* rebuild that package later, but it's basically > pointless - the entire point for shim is to have a stable signed > *binary* including Debian's Secure Boot CA key to act as a trusted > base for our other SB packages. >... IMHO signed packages for secure boot should move to non-free-firmware, since the private key is part of the source for a signature. cu Adrian
