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

Groups > linux.debian.kernel > #57478 > unrolled thread

Resolving the kernel debug symbols vs signing problem

Back to article view | Back to linux.debian.kernel

Contents

  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

#57478 — Resolving the kernel debug symbols vs signing problem

[Multipart message — attachments visible in raw view] — view raw

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.

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.  I think this has to be solved before the stable release.

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

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.

(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.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.

[toc] | [next] | [standalone]

#57527

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

[toc] | [prev] | [next] | [standalone]

#57531

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2017-04-12 at 07:50 +0000, Niels Thykier wrote:
> 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.

Sometimes it does, sometimes it doesn't.

[...]
> > 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.

We could do, but do you think it's OK to do so for all architectures? 
Previously we did not, mainly due to concern about bloating the
archive.

> > 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?

Yes, exactly.

[...]
> > (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.

I'm not sure which switch you're referring to here.

> That way, testing is closer to an
> release-ready state, which is generally what we want right now.

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.  Please don't copy me into your
sig.

[toc] | [prev] | [next] | [standalone]

#57537

[Multipart message — attachments visible in raw view] — view raw

Ben Hutchings:
> [...]
>>
>> 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.
> 
> We could do, but do you think it's OK to do so for all architectures? 
> Previously we did not, mainly due to concern about bloating the
> archive.
> 

IANAFM, but yes.

 * It is definitely better than shipping no dbg symbols at all.

 * Due to dbgsyms, we have been able to get rid of a lot of other -dbg
   packages from the main archive.  I think we can afford a temporary
   regression for Linux.

 * Finally, I am not sure dbgsym is the right solution for this case (at
   least not in its current implementation).  I would much rather that
   we sat down and carefully revised the design while looking at all the
   deficiencies - and while there is definitely room for improvement,
   now is not the time to implement this.

Again, that is my view on it.  FTP masters might disagree and then we
will take it from there.


> [...]
>>> (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.
> 
> I'm not sure which switch you're referring to here.
>


Basically, I want testing to be as close to a release as possible.  If
you don't want to ship the kernel in its current state, then I would
prefer to have it changed into a "release-ready" state.

After dak gets support for signing, we can evaluate whether we are ready
to delay the release for secure boot support.

Thanks,
~Niels

[toc] | [prev] | [next] | [standalone]

#57564

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2017-04-13 at 09:15 +0000, Niels Thykier wrote:
> Ben Hutchings:
> > [...]
> > > 
> > > 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.
> > 
> > We could do, but do you think it's OK to do so for all architectures? 
> > Previously we did not, mainly due to concern about bloating the
> > archive.
> > 
> 
> IANAFM, but yes.
> 
>  * It is definitely better than shipping no dbg symbols at all.
> 
>  * Due to dbgsyms, we have been able to get rid of a lot of other -dbg
>    packages from the main archive.  I think we can afford a temporary
>    regression for Linux.
> 
>  * Finally, I am not sure dbgsym is the right solution for this case (at
>    least not in its current implementation).  I would much rather that
>    we sat down and carefully revised the design while looking at all the
>    deficiencies - and while there is definitely room for improvement,
>    now is not the time to implement this.
> 
> Again, that is my view on it.  FTP masters might disagree and then we
> will take it from there.

This change is now pending for the next upload.  Debug symbols will be
built for all architectures and flavours and uploaded to the main
archive with a '-dbg' suffix.

> > [...]
> > > > (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.
> > 
> > I'm not sure which switch you're referring to here.
> > 
> 
> 
> Basically, I want testing to be as close to a release as possible.  If
> you don't want to ship the kernel in its current state, then I would
> prefer to have it changed into a "release-ready" state.

This change is now pending for the next upload of src:linux.  It will
build linux-image packages without any name suffix and will build
udebs.  The next upload of src:linux-latest will automatically follow
that change.

Ben.

> After dak gets support for signing, we can evaluate whether we are ready
> to delay the release for secure boot support.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web