Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Wade A]

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  wrote:

> On Mon, Mar 04, 2019 at 04:30:46PM +, 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.
> st...@einval.com
> "You can't barbecue lettuce!" -- Ellie Crane
>

Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Steve McIntyre]

On Mon, Mar 04, 2019 at 04:30:46PM +, 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.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


signature.asc
Description: PGP signature

Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Julien Cristau]

On Sun, Mar  3, 2019 at 23:35:45 +, 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

Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Cyril Brulebois]

Steve McIntyre  (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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Steve McIntyre]

I've had a reply from Mark (ftpteam) in IRC:

On Sun, Mar 03, 2019 at 11:35:45PM +, 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.st...@einval.com
Is there anybody out there?


signature.asc
Description: PGP signature

Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Georg Faerber]

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


signature.asc
Description: Digital signature

Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Steve McIntyre]

[ 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: