Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #57527

Re: Resolving the kernel debug symbols vs signing problem

Cross-posted to 2 groups.

Show all headers | View raw

Ben Hutchings:
> When implementing signed kernel packages, I wanted to make the signed
> image packages (built from linux-signed) take un-suffixed names so that
> existing procedures to install specific kernel versions would pick the
> signed packages, and users would be discouraged from installing
> unsigned packages.
> 

Hi,

That makes sense to me. :)  I particularly liked that part of the design
choice. :)

> This has interacted poorly with dak's handling of 'auto-built' debug
> symbol packages, as those are built by src:linux but don't include the
> '-unsigned' suffix in their names.  The debug symbol packages are added
> to the overrides file but are later automatically pruned, so that
> uploads that don't add new binary packages may still require NEW
> processing.

It almost certainly does.  The original plan for auto-built debug
packages were that they came from the same source.  This split between a
signed and unsigned package very much violates that basic assumption
that we had when we implemented dbgsym packages.

> I think this has to be solved before the stable release.
> 

I am probably missing something here, but wouldn't it be possible to go
back to the original -dbg (as a "worst case" option) and defer these
changes to buster?  Not saying I like it, I just want to know whether I
missed something.

> Therefore I intend to rename the binary packages as follows with the
> next uploads to unstable:
> 
> - src:linux builds linux-image packages without a name suffix
> - src:linux-signed builds linux-image packages with a '-signed' suffix
> - src:linux-latest builds linux-image meta-packages that depend on the
>   '-signed' package where available
> 

This would undo the very nice property of the image packages being
signed "by default", wouldn't it?

> One alternative could be to build duplicate debug symbol packages in
> src:linux and src:linux-signed, but that's a big waste of archive space
> and requires a maintainer to upload the debug symbol packages for one
> architecture (over 500 MiB per flavour) whenever there's an ABI bump.
> 
> Please let me know if you have a preference or an alternate solution.
> 

To be honest, at first glance I think I would prefer going back to -dbg
packages for stretch if it meant that the signed packages had no suffix.
 That said, ...

> (Also, if dak will not be signing packages in time for stretch,
> src:linux-signed must be removed from testing and the other packages
> changed accordingly.  I *will* *not* personally sign kernels for a
> stable release.)
> 
> Ben.
> 

Ok - I wouldn't want that responsibility either.  If the signed ones are
easy to re-implement, perhaps just switch now and add a blocker bug to
#820036 filed against linux.  That way, testing is closer to an
release-ready state, which is generally what we want right now.

Thanks,
~Niels

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Resolving the kernel debug symbols vs signing problem Ben Hutchings <ben@decadent.org.uk> - 2017-04-07 21:20 +0200
  Re: Resolving the kernel debug symbols vs signing problem Niels Thykier <niels@thykier.net> - 2017-04-12 10:00 +0200
    Re: Resolving the kernel debug symbols vs signing problem Ben Hutchings <ben@decadent.org.uk> - 2017-04-12 18:50 +0200
      Re: Resolving the kernel debug symbols vs signing problem Niels Thykier <niels@thykier.net> - 2017-04-13 11:20 +0200
        Re: Resolving the kernel debug symbols vs signing problem Ben Hutchings <ben@decadent.org.uk> - 2017-04-16 20:40 +0200

csiph-web