Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.security > #5561 > unrolled thread
| Started by | Steve McIntyre <steve@einval.com> |
|---|---|
| First post | 2019-03-04 00:40 +0100 |
| Last post | 2019-03-06 11:40 +0100 |
| Articles | 7 — 5 participants |
Back to article view | Back to linux.debian.security
Problems with shim and shim-signed in unstable, and proposed solutions to unblock us Steve McIntyre <steve@einval.com> - 2019-03-04 00:40 +0100
Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us Georg Faerber <georg@riseup.net> - 2019-03-04 02:10 +0100
Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us Steve McIntyre <steve@einval.com> - 2019-03-04 17:40 +0100
Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us Cyril Brulebois <kibi@debian.org> - 2019-03-04 17:50 +0100
Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us Steve McIntyre <steve@einval.com> - 2019-03-06 23:50 +0100
Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us Wade A <wadeamesbury@gmail.com> - 2019-03-07 04:10 +0100
Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us Julien Cristau <jcristau@debian.org> - 2019-03-06 11:40 +0100
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2019-03-04 00:40 +0100 |
| Subject | Problems with shim and shim-signed in unstable, and proposed solutions to unblock us |
| Message-ID | <xxIS5-2dt-1@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
[ Note CCs to multiple lists - we know multiple groups of people have
an interest in this... ]
Hi folks,
We have issues with the setup of the shim and shim-signed packages in
unstable at the moment, which is quite awkward to fix. See #922179 for
the original bug report.
shim and shim-signed have an ... awkward relationship, which causes us
multiple problems at the moment.
1. shim is the primary source package, building one binary package
which included several EFI binaries - the shimx64.efi binary
itself, plus two helpers (fbx64.efi.signed and
mmx64.efi.signed)
2. shimx64.efi is the EFI binary that is submitted to Microsoft
for signing - it's the core of our Secure Boot implementation
(like all Linux distros)
2b. The MS-signed binary (shimx64.efi.signed) is shipped in the
shim-signed source package and passed through to the
shim-signed binary package
2c. The shim-signed source package validates that the binary
matches what we built in shim, and checks the signature
applies..
3. For $reasons, the existing shim-signed binary package has a
strict versioned dependency on the shim binary package to pull
in the helper binaries for installation. We are very much
planning on fixing this, but this is the historical setup.
4. As requested, Steve Langasek uploaded a new upstream version of
shim to unstable (15+1533136590.3beb971-2, which is there right
now).
5. Until we get an MS signature on a new shim binary, we will
*not* have a matching shim-signed binary package, so for now we
still have the *old* (1.28+nmu1+0.9+1474479173.6c180c6-1)
shim-signed binary and source in unstable.
6. Everything works OK right now in buster, but...
7. Right now, shim-signed is not installable in sid, which means that:
7a. People can't test SB in unstable
7b. (Worse) as shim-signed is a build-dep for d-i on amd64 (to be
able to make SB-compatible installer images) we currently
can't build d-i
8. We don't have an ETA for a new signature from MS which would
unblock us. At *best*, we're expecting a few weeks. It's out of
our control.
FTAOD: this dependency problem has been here as a time bomb ever since
day 1 of shim in Debian. We just haven't ever noticed as nobody was
using these packages until very recently. Apologies for not spotting
the problem before we uploaded newer versions and triggered
this. AFAIK Ubuntu have got away with a very similar configuration due
to a different archive setup.
We're planning on redoing the packaging to get away from these
problems ASAP so this problem will not recur. However, fixing things
cleanly now is not easy:
1. We can't simply re-upload a new shim source package to get a
new shim binary with the same version number as the old one
2. The old version of the shim binary package is encoded in the
dependencies of the shim-signed binary package
3. We cannot reproduce the shimx64.efi EFI binary if we rebuild
it today (Cyril has tried multiple ways), so we *cannot*
simply upload a new shim source package and hope...
So, we're looking at three hacky options options here to work our way
out of this hole. In (probably?) descending order of hackitude:
1. Ask the nice ftpmaster people to bodge the archive by hand:
1a. Remove the current shim source and binary packages from
unstable (version 15+1533136590.3beb971-2)
1b. Copy the older source and binary from buster back into
unstable for us.
1c. We're not even sure if this is *possible*, let alone a nice
thing to do - thoughts?
1d. Expecting that this might break all kinds of tools inside and
outside of the archive maybe?
OR
2. Upload new bodged versions of shim and shim-signed to get us
back to working with the previously-signed shimx64.efi.signed
binary
2a. Create new shim and shim-signed source packages, along with
matching binary packages.
2b. These binary packages will contain the *exact* same EFI
binaries as we have in buster but with a higher version number
in the packaging.
2c. As we cannot *exactly* reproduce the binaries sensibly, we
will have to hand-hack the contents of the binary packages.
2d. We *know* this is grotty too, but we can at least make this
work entirely at a package level.
2e. Already tested and working: Cyril has built packages like this
and I have tested the results successfully on my test SB
system here.
Current versions in buster:
- shim:
- source: 0.9+1474479173.6c180c6-1
- binary: 0.9+1474479173.6c180c6-1
- shim-signed:
- source: 1.28+nmu1
- binary: 1.28+nmu1+0.9+1474479173.6c180c6-1
Possible versions targetting sid:
- shim:
- source: 16+1474479173.6c180c6-1 (bumped “epoch-like” N+
prefix, but same contents as 0.9+1474479173.6c180c6-1)
- binary: 16+1474479173.6c180c6-1
- shim-signed:
- source: 1.28+nmu2 (new upload to adjust the Depends)
- binary: 1.28+nmu2+16+1474479173.6c180c6-1
OR
3. Upload new version of the shim-signed source package and a
(lightly) bodged binary package
3a. Use versions:
- source: 1.28+nmu2
- binary: 1.28+nmu2+0.9+1474479173.6c180c6-1
3b. Needs as build-deps an old version of sbsigntool (0.6-3.2) and
specifically version 0.9+1474479173.6c180c6-1 of shim in the
build chroot
3c. Then upload source+amd64
3d. New shim-signed binary package changes in a few ways:
* new version of the binary now include fbx64.efi.signed and
mmx64.efi.signed (copied across from the shim binary package)
* add Replaces: shim (= 0.9+1474479173.6c180c6-1) so we don't
conflict on those binaries
* remove Depends: shim (the whole point!)
* change Build-Depends to list the specific versions used for
shim and sbsigntool
3e. Already tested and working. I built this (source and binary
debdiffs attached) and tested OK on SB system
3f. This package is instantly RC-buggy due to the unavailable
build-deps. We know...
I'm deliberately notifying a number of likely interested teams here
about this problem and our three suggested solutions, so we can get
feedback and work out the best way forwards. If somebody else can
think of a better solution than any of our three suggestions, we'd
love to hear it!
As I said, we'll be uploading new packages with a better relationship
to fix this problem for future versions. That will become even more
important as we extend SB support to more than simply amd64
systems. shim is now designed to build reproducibly, which will also
help us to avoid/work around any similar issues in future. We will
also be integrating support for Debian's new signing service (to sign
the helper binaries in a better manner).
So, please - what do you think?
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
[toc] | [next] | [standalone]
| From | Georg Faerber <georg@riseup.net> |
|---|---|
| Date | 2019-03-04 02:10 +0100 |
| Message-ID | <xxKhc-3cb-3@gated-at.bofh.it> |
| In reply to | #5561 |
[Multipart message — attachments visible in raw view] — view raw
Hi all, On 19-03-03 23:35:45, Steve McIntyre wrote: > [ Note CCs to multiple lists - we know multiple groups of people have > an interest in this... ] Wouldn't this be also of interest to -devel? Besides, more people looking at this "interesting", maybe not every day, problem, might yield better discussions and / or results? Thanks for your work, highly appreciated! Cheers, Georg
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2019-03-04 17:40 +0100 |
| Message-ID | <xxYNb-3JQ-3@gated-at.bofh.it> |
| In reply to | #5561 |
[Multipart message — attachments visible in raw view] — view raw
I've had a reply from Mark (ftpteam) in IRC: On Sun, Mar 03, 2019 at 11:35:45PM +0000, Steve McIntyre wrote: ... >So, we're looking at three hacky options options here to work our way >out of this hole. In (probably?) descending order of hackitude: > > 1. Ask the nice ftpmaster people to bodge the archive by hand: > 1a. Remove the current shim source and binary packages from > unstable (version 15+1533136590.3beb971-2) > 1b. Copy the older source and binary from buster back into > unstable for us. > 1c. We're not even sure if this is *possible*, let alone a nice > thing to do - thoughts? > 1d. Expecting that this might break all kinds of tools inside and > outside of the archive maybe? And Mark says: "we don't want to go rewinding version numbers in unstable; that could lead to all sorts of unforeseeable breakage. much as we'd expected. Any more feedback please? Cyril prefers approach #2 below, I prefer #3. > OR > > 2. Upload new bodged versions of shim and shim-signed to get us > back to working with the previously-signed shimx64.efi.signed > binary > 2a. Create new shim and shim-signed source packages, along with > matching binary packages. > 2b. These binary packages will contain the *exact* same EFI > binaries as we have in buster but with a higher version number > in the packaging. > 2c. As we cannot *exactly* reproduce the binaries sensibly, we > will have to hand-hack the contents of the binary packages. > 2d. We *know* this is grotty too, but we can at least make this > work entirely at a package level. > 2e. Already tested and working: Cyril has built packages like this > and I have tested the results successfully on my test SB > system here. > > Current versions in buster: > - shim: > - source: 0.9+1474479173.6c180c6-1 > - binary: 0.9+1474479173.6c180c6-1 > - shim-signed: > - source: 1.28+nmu1 > - binary: 1.28+nmu1+0.9+1474479173.6c180c6-1 > > Possible versions targetting sid: > - shim: > - source: 16+1474479173.6c180c6-1 (bumped “epoch-like” N+ > prefix, but same contents as 0.9+1474479173.6c180c6-1) > - binary: 16+1474479173.6c180c6-1 > - shim-signed: > - source: 1.28+nmu2 (new upload to adjust the Depends) > - binary: 1.28+nmu2+16+1474479173.6c180c6-1 > > OR > > 3. Upload new version of the shim-signed source package and a > (lightly) bodged binary package > 3a. Use versions: > - source: 1.28+nmu2 > - binary: 1.28+nmu2+0.9+1474479173.6c180c6-1 > 3b. Needs as build-deps an old version of sbsigntool (0.6-3.2) and > specifically version 0.9+1474479173.6c180c6-1 of shim in the > build chroot > 3c. Then upload source+amd64 > 3d. New shim-signed binary package changes in a few ways: > * new version of the binary now include fbx64.efi.signed and > mmx64.efi.signed (copied across from the shim binary package) > * add Replaces: shim (= 0.9+1474479173.6c180c6-1) so we don't > conflict on those binaries > * remove Depends: shim (the whole point!) > * change Build-Depends to list the specific versions used for > shim and sbsigntool > 3e. Already tested and working. I built this (source and binary > debdiffs attached) and tested OK on SB system > 3f. This package is instantly RC-buggy due to the unavailable > build-deps. We know... -- Steve McIntyre, Cambridge, UK. steve@einval.com Is there anybody out there?
[toc] | [prev] | [next] | [standalone]
| From | Cyril Brulebois <kibi@debian.org> |
|---|---|
| Date | 2019-03-04 17:50 +0100 |
| Message-ID | <xxYWR-3Nl-1@gated-at.bofh.it> |
| In reply to | #5564 |
[Multipart message — attachments visible in raw view] — view raw
Steve McIntyre <steve@einval.com> (2019-03-04): > And Mark says: > > "we don't want to go rewinding version numbers in unstable; that could > lead to all sorts of unforeseeable breakage. > > much as we'd expected. Any more feedback please? Cyril prefers > approach #2 below, I prefer #3. To clarify: #2 was my preferred approach when we first tried to get #3 to work, seeing how many things could need tweaking; #2 is mostly about re-uploading packages that we know were working (albeit with different version numbers), which looked more reassuring. Given the amount of research we've done since then, it seems that we've ironed out what could be an issue (mostly the fact we moved files from one binary package to another one), and we didn't spot other packages having relationships to either binary packages, that could have an issue with the new layout. Building a binary package for real, even if in a chroot with some specific versions also looks cleaner to me than repacking and re-uploading old binaries. Long story short: #3 looks good to me. Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2019-03-06 23:50 +0100 |
| Message-ID | <xyNwl-1WN-7@gated-at.bofh.it> |
| In reply to | #5564 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Mar 04, 2019 at 04:30:46PM +0000, Steve McIntyre wrote: >> >> 3. Upload new version of the shim-signed source package and a >> (lightly) bodged binary package >> 3a. Use versions: >> - source: 1.28+nmu2 >> - binary: 1.28+nmu2+0.9+1474479173.6c180c6-1 >> 3b. Needs as build-deps an old version of sbsigntool (0.6-3.2) and >> specifically version 0.9+1474479173.6c180c6-1 of shim in the >> build chroot >> 3c. Then upload source+amd64 >> 3d. New shim-signed binary package changes in a few ways: >> * new version of the binary now include fbx64.efi.signed and >> mmx64.efi.signed (copied across from the shim binary package) >> * add Replaces: shim (= 0.9+1474479173.6c180c6-1) so we don't >> conflict on those binaries >> * remove Depends: shim (the whole point!) >> * change Build-Depends to list the specific versions used for >> shim and sbsigntool >> 3e. Already tested and working. I built this (source and binary >> debdiffs attached) and tested OK on SB system >> 3f. This package is instantly RC-buggy due to the unavailable >> build-deps. We know... I've just uploaded #3 to unstable this evening. -- Steve McIntyre, Cambridge, UK. steve@einval.com "You can't barbecue lettuce!" -- Ellie Crane
[toc] | [prev] | [next] | [standalone]
| From | Wade A <wadeamesbury@gmail.com> |
|---|---|
| Date | 2019-03-07 04:10 +0100 |
| Message-ID | <xyRzY-4BQ-1@gated-at.bofh.it> |
| In reply to | #5567 |
[Multipart message — attachments visible in raw view] — view raw
I've certainly bbqed lettuce before. I don't know anything about cooking tho. And sorry to allow for more off topic banter on this thread. Thank you. On Wed, Mar 6, 2019, 2:47 PM Steve McIntyre <steve@einval.com> wrote: > On Mon, Mar 04, 2019 at 04:30:46PM +0000, Steve McIntyre wrote: > >> > >> 3. Upload new version of the shim-signed source package and a > >> (lightly) bodged binary package > >> 3a. Use versions: > >> - source: 1.28+nmu2 > >> - binary: 1.28+nmu2+0.9+1474479173.6c180c6-1 > >> 3b. Needs as build-deps an old version of sbsigntool (0.6-3.2) and > >> specifically version 0.9+1474479173.6c180c6-1 of shim in the > >> build chroot > >> 3c. Then upload source+amd64 > >> 3d. New shim-signed binary package changes in a few ways: > >> * new version of the binary now include fbx64.efi.signed and > >> mmx64.efi.signed (copied across from the shim binary package) > >> * add Replaces: shim (= 0.9+1474479173.6c180c6-1) so we don't > >> conflict on those binaries > >> * remove Depends: shim (the whole point!) > >> * change Build-Depends to list the specific versions used for > >> shim and sbsigntool > >> 3e. Already tested and working. I built this (source and binary > >> debdiffs attached) and tested OK on SB system > >> 3f. This package is instantly RC-buggy due to the unavailable > >> build-deps. We know... > > I've just uploaded #3 to unstable this evening. > > -- > Steve McIntyre, Cambridge, UK. > steve@einval.com > "You can't barbecue lettuce!" -- Ellie Crane >
[toc] | [prev] | [next] | [standalone]
| From | Julien Cristau <jcristau@debian.org> |
|---|---|
| Date | 2019-03-06 11:40 +0100 |
| Message-ID | <xyC7T-3eW-5@gated-at.bofh.it> |
| In reply to | #5561 |
On Sun, Mar 3, 2019 at 23:35:45 +0000, Steve McIntyre wrote: > So, we're looking at three hacky options options here to work our way > out of this hole. In (probably?) descending order of hackitude: > > 1. Ask the nice ftpmaster people to bodge the archive by hand: [...] > > OR > > 2. Upload new bodged versions of shim and shim-signed to get us > back to working with the previously-signed shimx64.efi.signed > binary [...] > > OR > > 3. Upload new version of the shim-signed source package and a > (lightly) bodged binary package [...] > > So, please - what do you think? > FWIW I also don't think 1 is reasonable, but whichever of 2 or 3 the people doing the work want to run with will be fine. Cheers, Julien
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.security
csiph-web