Hi Steve,
Moritz Mühlenhoff <jmm@inutil.org> (2019-02-26):
> On Fri, Feb 15, 2019 at 07:28:57PM +0100, Cyril Brulebois wrote:
> > Right, this also breaks the build of the debian-installer source package
> > on amd64 since its build dependencies cannot be satisfied.
>
> Is there an ETA for a fix?
We're getting deeper and deeper into the freeze, and we seem to be
lacking a reasonable timeline regarding Secure Boot for Buster.
The problems we're seeing are:
1. the hard shim/shim-signed dependency means the shim-signed package
isn't installable in sid;
2. src:debian-installer therefore cannot be built because of
unsatisfiable build-dependencies;
3. shim cannot migrate to testing.
We don't know how long it will take to get the new shim signed by
Microsoft; until that happens these problems will continue to block
development (and potentially the release).
Apologies for not spotting these as potential problems earlier, before
asking you to upload the new version of shim into unstable. :-(
If our understanding is correct, it seems that re-uploading the contents
of the previous shim package (either with an over-long “+really”-like
version, with an epoch, or with the trick detailed below), and adjusting
the versioned dependency in shim-signed to match, would make both
packages installable again. It wouldn't change anything regarding the
actual signatures: they would be validated as previously.
The “old” shim/shim-signed couple is already able to chainload
GRUB/Linux/etc. signed by either the Debian test key (as we've been
testing recently) or the embedded Debian production key. This would be a
quick fix for the next D-I Alpha/RC, but could also serve as a last
resort solution for buster itself if we don't get an updated shim-signed
package in time. In the meantime, we could upload the new shim
source/binary package to experimental for people to work with.
The main drawbacks (compared to actually getting an updated shim-signed
package) would be:
1. lacking the newer shim code that upstream EFI people would like us
to be using;
2. only having support for amd64.
Until an updated shim-signed package is available, it seems to us that
the re-upload suggested above would fix all issues we're seeing, without
having any negative impact. That's why we're considering doing so in the
next few days.
Looking at the version numbers we have:
- 0.9+1474479173.6c180c6-1 in testing
- 15+1533136590.3beb971-2 in sid
so we could re-upload with 16+1474479173.6c180c6-1, which would sort
higher than the version in sid, but also lower than
16+1533136590.3beb971-*, that can be used to re-upload the new shim when
the matching shim-signed is ready.
How does that sound to you please?
Finally: we don't want to steal too much of your time for shim. It seems
like now would be a really good time to move maintenance formally to the
debian-efi team?
Cheers,
Cyril Brulebois & Steve McIntyre for the D-I / EFI teams
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature