Re: Resolving the kernel debug symbols vs signing problem

Path	csiph.com!news.redatomik.org!aioe.org!bofh.it!news.nic.it!robomod
From	Niels Thykier <niels@thykier.net>
Newsgroups	linux.debian.kernel, linux.debian.devel.release
Subject	Re: Resolving the kernel debug symbols vs signing problem
Date	Thu, 13 Apr 2017 11:20:03 +0200
Message-ID	<tvJ51-Rx-25@gated-at.bofh.it> (permalink)
References	<ttHAl-3g5-5@gated-at.bofh.it> <tvlm2-1MB-19@gated-at.bofh.it> <tvtCW-6Qp-17@gated-at.bofh.it>
X-Mailbox-Line	From debian-kernel-request@lists.debian.org Thu Apr 13 09:17:32 2017
Old-Return-Path	<niels@thykier.net>
X-Amavis-Spam-Status	No, score=-12.12 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LDO_WHITELIST=-5, PGPSIGNATURE=-5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Dkim-Signature	v=1; a=rsa-sha256; c=simple/simple; d=thykier.net; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=FPWLyojebiDDYXcmbOV5GPWrZ02pd4DmJYzRXdQmr5o=; b=Ry0Au9euvRBCaPeFStf3jW1qfBic/zosZQleiZr7bEGxCUSSGzRMY74cdy4mzqujzh4xiqti3m4yo WXfbfgWdN+MpW13Cp/AuzSdPgaA57ROGjZJJoCH44soyajnxMQz2FFU2KIHp+QKBiHyY0ZKEKrCxtF ZkbMZr6q1zyPhYNk=
X-Halone-Cookie	53bbba865a1a5536a18b8d150c84bfe875d69b11
X-Halone-ID	fc0b2323-2029-11e7-bc04-b82a72d03b9b
MIME-Version	1.0
Content-Type	multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D4xQ42BM7jlGt5xGXtbnGf4F0mA8tArE7"
X-Mailing-List	<debian-kernel@lists.debian.org> archive/latest/112347
List-ID	<debian-kernel.lists.debian.org>
List-URL	<https://lists.debian.org/debian-kernel/>
List-Archive	https://lists.debian.org/msgid-search/ded820cb-7fba-33a5-d074-9915f180694a@thykier.net
Approved	robomod@news.nic.it
Lines	110
Organization	linux.* mail to news gateway
Sender	robomod@news.nic.it
X-Original-Cc	Debian release team <debian-release@lists.debian.org>, ftpmaster@debian.org
X-Original-Date	Thu, 13 Apr 2017 09:15:00 +0000
X-Original-Message-ID	<ded820cb-7fba-33a5-d074-9915f180694a@thykier.net>
X-Original-References	<1491592637.2409.37.camel@decadent.org.uk> <6ecbe947-0fcc-5e90-3f83-cac5f499b9ef@thykier.net> <1492015431.2409.81.camel@decadent.org.uk>
Xref	csiph.com linux.debian.kernel:57537 linux.debian.devel.release:71035

Cross-posted to 2 groups.

Show key headers only | View raw

[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

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