FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 02-06-2011, 09:52 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

Hi,

Now that squeeze is released, I've started thinking about how to
improve the quality of security support for testing.

The biggest problem I saw during the squeeze development cycle was that
kernel security update transitions were extremely slow due to unrelated
RC bugs. This was bad since it left testing users vulnerable to issues
for much larger periods of time than stable/unstable users.

Another issue was that a lot of vulnerabilities that were found in that
time frame were actually flaws in new kernel code, so testing/unstable
were vulnerable, but the stable kernel itself was unaffected, so it was
a bit safer to be running the stable kernel since the code was older
(i.e. there was more time to find and fix issues). For example, the
vulnerability for one of the local privilege escalations that was
exploited in the wild was introduced in 2.6.30, so lenny wasn't
affected, but testing/unstable were.

I'd like to propose a solution to these two problems: only upload known
rock solid longterm cadence upstream supported kernels into
testing/unstable. This will hopefully reduce the amount of transition
delay since the longterm kernels should have fewer RC issues (after
they've had a little time to cook of course).

There are, of course, some undesirable consequences to this plan. One
is that a certain subset of testing users expect the latest shiny all
the time; but they can easily get their fix from the experimental
kernels instead, so that isn't really a problem (I think).

The second issue is that testing d-i will not support the latest and
greatest hardware and features. I think this can be solved by
providing two sets of d-i media for testing (one that uses the longterm
testing kernel and one that uses newer experimental kernel). Of course
this means that some d-i development will need to move to experimental
to make use of the newer kernel feature, but I don't think that would
really be a problem.

A benefit to this proposal is that there will be reduced work for those
currently supporting kernel security updates since the same package can
be uploaded to both stable-security and unstable. Also, there should
be no RC issues that prevent transitions to testing since for example
the 2.6.32 kernel is so well-tested already.

Anyway, I think this would go a long way toward improving the quality
of security support in testing and thus reducing the common advice/meme
that users should avoid testing if they're concerned about security.

So, my proposal in a nutshell is to only upload upstream 2.6.32 point
releases to wheezy/sid for the next 12-18 months. At that time,
reevaluate and determine what the next longterm cadence kernel will be,
and then once that is reasonable stabilized in experimental, finally
upload it to unstable for the final stages of wheezy development
(perhaps a few months before the freeze).

Looking forward to thoughts and discussion on the matter.

Best wishes,
Mike

Disclaimer: note that I haven't participated in kernel packaging or
applied kernel security patches directly myself (yet), but I have been
triaging and tracking kernel security issues for about a year and a
half now [0], so I have a pretty good understanding of the status quo.

[0] http://svn.debian.org/wsvn/kernel-sec/?op=log


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110206175211.cd94ac24.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110206175211.cd94ac24.michael.s.gilbert@gmail.co m
 
Old 02-07-2011, 12:58 AM
Joey Hess
 
Default For discussion: security support strategy for the wheezy kernel

Well, I have a few horses in this race in between testing-security,
d-i, and CUT, as well as having been a Release Assistant in the past,
and I think this proposal stinks from every perspective.

Michael Gilbert wrote:
> The biggest problem I saw during the squeeze development cycle was that
> kernel security update transitions were extremely slow due to unrelated
> RC bugs. This was bad since it left testing users vulnerable to issues
> for much larger periods of time than stable/unstable users.

Which proves nicely that not all RC bugs are equally RC, and that britney's
old_rc_count <= new_rc_count
is a flawed heuristic whose main virtue is that it's probably the best
a machine can do with the available information. Which is why the release
team has override files..

> Another issue was that a lot of vulnerabilities that were found in that
> time frame were actually flaws in new kernel code, so testing/unstable
> were vulnerable, but the stable kernel itself was unaffected, so it was
> a bit safer to be running the stable kernel since the code was older
> (i.e. there was more time to find and fix issues). For example, the
> vulnerability for one of the local privilege escalations that was
> exploited in the wild was introduced in 2.6.30, so lenny wasn't
> affected, but testing/unstable were.

LWN's analysis of age of introduction of kernel security holes in 2010
doesn't seem to agree? http://lwn.net/Articles/410606/

| So, in a sense, the above-mentioned kernel hacker was correct - an
| awful lot of the vulnerabilities fixed over the last year predate the
| git era, and are thus over five years old.

At best, you seem to be grossly oversimplifying. In the immortal words
of FaceBook, "it's complicated".

> I'd like to propose a solution to these two problems: only upload known
> rock solid longterm cadence upstream supported kernels into
> testing/unstable. This will hopefully reduce the amount of transition
> delay since the longterm kernels should have fewer RC issues (after
> they've had a little time to cook of course).
>
> There are, of course, some undesirable consequences to this plan. One
> is that a certain subset of testing users expect the latest shiny all
> the time; but they can easily get their fix from the experimental
> kernels instead, so that isn't really a problem (I think).

I feel that unstable is heading in much too stable a direction already.
I think that Bdale mentioned this (as a possible negative feature of CUT)
at DebConf. If testing is as stale as stable, why would anyone want to
bother with CUT?

> The second issue is that testing d-i will not support the latest and
> greatest hardware and features. I think this can be solved by
> providing two sets of d-i media for testing (one that uses the longterm
> testing kernel and one that uses newer experimental kernel).

This seems likely to increase the workload of the d-i (and CD..) team
significantly. And wouldn't it result in either an installed system that
used unstable's old kernel and so didn't work, or used experimental's
kernel and so didn't auto-upgrade to fix security holes?

Also, what are teams like the X team to do, when their packages depend
on new kernel features? How are we supposed to ever integrate support
for the new kernel distribution-wide if unstable constantly has an old
version? Should the whole distribution lag years behind the state of the
art?

> Anyway, I think this would go a long way toward improving the quality
> of security support in testing and thus reducing the common advice/meme
> that users should avoid testing if they're concerned about security.

A meme that is not founded in truth, as you can see if you compare
existing known security holes in stable and in testing at most points in
the release cycle. Perhaps the project should consider how it allows
these types of myths to stand up when their foundations are so easily
disproven?

--
see shy jo
 
Old 02-07-2011, 05:12 PM
Moritz Mühlenhoff
 
Default For discussion: security support strategy for the wheezy kernel

Michael Gilbert <michael.s.gilbert@gmail.com> schrieb:
> Hi,

> So, my proposal in a nutshell is to only upload upstream 2.6.32 point
> releases to wheezy/sid for the next 12-18 months. At that time,
> reevaluate and determine what the next longterm cadence kernel will be,
> and then once that is reasonable stabilized in experimental, finally
> upload it to unstable for the final stages of wheezy development
> (perhaps a few months before the freeze).

No way. The idea of unstable is to get the current upstream code in
shape and that won't be achieved with staying with an old kernel.

Whatever the technical solution to testing-security kernel might be,
it needs to be based on following the upstream kernel development.

Cheers,
Moritz


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnil0dh0.3dh.jmm@inutil.org">http://lists.debian.org/slrnil0dh0.3dh.jmm@inutil.org
 
Old 02-07-2011, 08:14 PM
Ben Hutchings
 
Default For discussion: security support strategy for the wheezy kernel

On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote:
> Michael Gilbert <michael.s.gilbert@gmail.com> schrieb:
> > Hi,
>
> > So, my proposal in a nutshell is to only upload upstream 2.6.32 point
> > releases to wheezy/sid for the next 12-18 months. At that time,
> > reevaluate and determine what the next longterm cadence kernel will be,
> > and then once that is reasonable stabilized in experimental, finally
> > upload it to unstable for the final stages of wheezy development
> > (perhaps a few months before the freeze).
>
> No way. The idea of unstable is to get the current upstream code in
> shape and that won't be achieved with staying with an old kernel.
>
> Whatever the technical solution to testing-security kernel might be,
> it needs to be based on following the upstream kernel development.

Totally agreed. We should be tracking current upstream releases,
and not just in experimental (which can now be used for upstream
release candidates).

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110207211415.GC21934@decadent.org.uk">http://lists.debian.org/20110207211415.GC21934@decadent.org.uk
 
Old 02-07-2011, 08:28 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote:
> Michael Gilbert <michael.s.gilbert@gmail.com> schrieb:
> > Hi,
>
> > So, my proposal in a nutshell is to only upload upstream 2.6.32 point
> > releases to wheezy/sid for the next 12-18 months. At that time,
> > reevaluate and determine what the next longterm cadence kernel will be,
> > and then once that is reasonable stabilized in experimental, finally
> > upload it to unstable for the final stages of wheezy development
> > (perhaps a few months before the freeze).
>
> No way. The idea of unstable is to get the current upstream code in
> shape and that won't be achieved with staying with an old kernel.

I'm not sure if there's a precise definition of unstable other than
the statement at [0], but it seems to be whatever teams make of it.
It's perfectly ok to upload only stable versions (if that's what the
team wants to do), and its perfectly ok to upload the most unstable
thing ever, but then the consequences of that have to be dealt with. I
guess what I'm saying is that each team can decide specifically how
they want to use unstable, so the kernel team can deviate from the
status quo if they decide to; that is if I can make a sufficiently
convincing argument.

Also, my suggestion does involve eventually moving to a newer kernel in
the wheezy development cycle; just a while from now, rather than
rushing in to things.

> Whatever the technical solution to testing-security kernel might be,
> it needs to be based on following the upstream kernel development.

2.6.32.x is in fact an upstream kernel currently being developed

Best wishes,
Mike

[0] http://www.debian.org/releases/unstable/


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110207162831.fbd75367.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110207162831.fbd75367.michael.s.gilbert@gmail.co m
 
Old 02-07-2011, 09:08 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

2011/2/7 Ben Hutchings wrote:
> On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote:
>> Michael Gilbert <michael.s.gilbert@gmail.com> schrieb:
>> > Hi,
>>
>> > So, my proposal in a nutshell is to only upload upstream 2.6.32 point
>> > releases to wheezy/sid for the next 12-18 months. Â*At that time,
>> > reevaluate and determine what the next longterm cadence kernel will be,
>> > and then once that is reasonable stabilized in experimental, finally
>> > upload it to unstable for the final stages of wheezy development
>> > (perhaps a few months before the freeze).
>>
>> No way. The idea of unstable is to get the current upstream code in
>> shape and that won't be achieved with staying with an old kernel.
>>
>> Whatever the technical solution to testing-security kernel might be,
>> it needs to be based on following the upstream kernel development.
>
> Totally agreed. Â*We should be tracking current upstream releases,
> and not just in experimental (which can now be used for upstream
> release candidates).

What about introducing a new linux-2.6-stable kernel package as a
compromise? That way users that want stability and security support
in testing continue to have that as an option. Also, I will assume
responsibility as the maintainer, so there will be hopefully very
little impact to any other part of Debian. Also, I can look at
generating d-i media for this kernel.

Any thoughts on that? The only downside I can think of right away is
introducing a huge code copy into the archive.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTin7H+4DNM90YK-6hwLaaT+m=GcpuKZ6Xs2grHv2@mail.gmail.com">http://lists.debian.org/AANLkTin7H+4DNM90YK-6hwLaaT+m=GcpuKZ6Xs2grHv2@mail.gmail.com


Mon Feb 7 23:30:01 2011
Return-path: <devel-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Mon, 07 Feb 2011 23:18:59 +0200
Received: from bastion02.fedoraproject.org ([209.132.181.3]:38832 helo�stion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <devel-bounces@lists.fedoraproject.org>)
id 1PmYU7-00022u-AT
for tom@linux-archive.org; Mon, 07 Feb 2011 23:18:59 +0200
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [192.168.1.21])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id BD9611106F4;
Mon, 7 Feb 2011 22:27:44 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id 0358F326782;
Mon, 7 Feb 2011 22:27:44 +0000 (UTC)
X-Original-To: devel@lists.fedoraproject.org
Delivered-To: devel@lists.fedoraproject.org
Received: from smtp-mm02.fedoraproject.org (smtp-mm2.fedoraproject.org
[66.35.62.164])
by lists.fedoraproject.org (Postfix) with ESMTP id BB697326781
for <devel@lists.fedoraproject.org>;
Mon, 7 Feb 2011 22:27:41 +0000 (UTC)
Received: from mail-wy0-f173.google.com (mail-wy0-f173.google.com
[74.125.82.173])
by smtp-mm02.fedoraproject.org (Postfix) with ESMTP id 26BC9E71F7
for <devel@lists.fedoraproject.org>;
Mon, 7 Feb 2011 22:27:41 +0000 (UTC)
Received: by wyg36 with SMTP id 36so5400524wyg.32
for <devel@lists.fedoraproject.org>;
Mon, 07 Feb 2011 14:27:40 -0800 (PST)
Received: by 10.227.128.141 with SMTP id k13mr16614152wbs.11.1297117396952;
Mon, 07 Feb 2011 14:23:16 -0800 (PST)
Received: from [192.168.1.1] (157-157-196-145.dsl.dynamic.simnet.is
[157.157.196.145])
by mx.google.com with ESMTPS id f27sm3790702wbf.7.2011.02.07.14.23.15
(version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 14:23:16 -0800 (PST)
Subject: Could not find debuginfo pkg for dependency package. . .
From: =?ISO-8859-1?Q?J�n?= "B." =?ISO-8859-1?Q?Gu�dsson? <johannbg@gmail.com>
To: Development discussions related to Fedora <devel@lists.fedoraproject.org>
Date: Mon, 07 Feb 2011 22:23:11 +0000
X-Mailer: Evolution 2.91.6.1 (2.91.6.1-1.fc15)
Message-ID: <1297117392.3733.9.camel@localhost.localdomain>
Mime-Version: 1.0
X-BeenThere: devel@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Development discussions related to Fedora
<devel@lists.fedoraproject.org>
List-Id: Development discussions related to Fedora
<devel.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/devel>
List-Post: <mailto:devel@lists.fedoraproject.org>
List-Help: <mailto:devel-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: devel-bounces@lists.fedoraproject.org
Errors-To: devel-bounces@lists.fedoraproject.org

I've been experiencing some mutter crashes when trying to report it via
abrt, abrt informed me that reporting was disabled because the backtrace
is unusable and suggested I installed debuginfo-install mutter then
refresh and try again which revealed. ..

Could not find debuginfo pkg for dependency package
glibc-2.13.90-2.x86_64
Could not find debuginfo pkg for dependency package
clutter-1.6.2-1.fc15.x86_64

I'm a bit curious if we cant automatically check for missing debuginfo
pacakges for relevant component(s) and inform the packager/maintainer
encase they dont exist to prevent encounters like this?

JBG

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-07-2011, 09:09 PM
Julien Cristau
 
Default For discussion: security support strategy for the wheezy kernel

On Mon, Feb 7, 2011 at 16:28:31 -0500, Michael Gilbert wrote:

> On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote:
> > Michael Gilbert <michael.s.gilbert@gmail.com> schrieb:
> > > Hi,
> >
> > > So, my proposal in a nutshell is to only upload upstream 2.6.32 point
> > > releases to wheezy/sid for the next 12-18 months. At that time,
> > > reevaluate and determine what the next longterm cadence kernel will be,
> > > and then once that is reasonable stabilized in experimental, finally
> > > upload it to unstable for the final stages of wheezy development
> > > (perhaps a few months before the freeze).
> >
> > No way. The idea of unstable is to get the current upstream code in
> > shape and that won't be achieved with staying with an old kernel.
>
> I'm not sure if there's a precise definition of unstable other than
> the statement at [0], but it seems to be whatever teams make of it.

unstable is where debian development work happens.

> It's perfectly ok to upload only stable versions (if that's what the
> team wants to do), and its perfectly ok to upload the most unstable
> thing ever, but then the consequences of that have to be dealt with. I
> guess what I'm saying is that each team can decide specifically how
> they want to use unstable, so the kernel team can deviate from the
> status quo if they decide to; that is if I can make a sufficiently
> convincing argument.
>
> Also, my suggestion does involve eventually moving to a newer kernel in
> the wheezy development cycle; just a while from now, rather than
> rushing in to things.
>
What does that buy us? It means instead of dealing with bugs on an
ongoing basis, you get them all at the same time and get to bisect along
many kernel versions at once instead of just one. It means problems
don't get reported (and fixed) upstream until it's too late. It means
any package that could use a newer kernel interface doesn't get any
testing. I'm sure there's plenty of others.

> > Whatever the technical solution to testing-security kernel might be,
> > it needs to be based on following the upstream kernel development.
>
> 2.6.32.x is in fact an upstream kernel currently being developed
>
No it's not. Go read the definition of development.

I'm sorry, but your proposal is insane.

Cheers,
Julien
 
Old 02-07-2011, 09:12 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Mon, Feb 7, 2011 at 5:08 PM, Michael Gilbert wrote:
> What about introducing a new linux-2.6-stable kernel package as a
> compromise? *That way users that want stability and security support
> in testing continue to have that as an option. *Also, I will assume
> responsibility as the maintainer, so there will be hopefully very
> little impact to any other part of Debian. *Also, I can look at
> generating d-i media for this kernel.
>
> Any thoughts on that? *The only downside I can think of right away is
> introducing a huge code copy into the archive.

Also the same effect can be achieved by apt-pinning the squeeze kernel.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinNLPeSzJn+VhYMFn6om0duiYrX6=M6zjN2XL0J@mail .gmail.com">http://lists.debian.org/AANLkTinNLPeSzJn+VhYMFn6om0duiYrX6=M6zjN2XL0J@mail .gmail.com
 
Old 02-07-2011, 09:15 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Mon, Feb 7, 2011 at 5:09 PM, Julien Cristau wrote:
> What does that buy us? *It means instead of dealing with bugs on an
> ongoing basis, you get them all at the same time and get to bisect along
> many kernel versions at once instead of just one. *It means problems
> don't get reported (and fixed) upstream until it's too late. *It means
> any package that could use a newer kernel interface doesn't get any
> testing. *I'm sure there's plenty of others.

Bugs can be submitted and dealt with in experimental just as well as
in unstable.

>> > Whatever the technical solution to testing-security kernel might be,
>> > it needs to be based on following the upstream kernel development.
>>
>> 2.6.32.x is in fact an upstream kernel currently being developed
>>
> No it's not. *Go read the definition of development.
>
> I'm sorry, but your proposal is insane.

Is this kind of negativity really necessary? I'm trying to guide a
discussion on a real problem, and I'm an engineer, so I never present
problems without at least an idea about a solution. It may not be the
best, but you start at something and work toward bettering it until
you have something good.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTimiCaXv+Yhgg=UW7=1miK-Y5=aLwp9=psVH1dxn@mail.gmail.com">http://lists.debian.org/AANLkTimiCaXv+Yhgg=UW7=1miK-Y5=aLwp9=psVH1dxn@mail.gmail.com
 
Old 02-08-2011, 02:54 AM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

Hi Joey,

Thank you so much for your very thoughtful reply.

On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote:
> Michael Gilbert wrote:
> > Another issue was that a lot of vulnerabilities that were found in that
> > time frame were actually flaws in new kernel code, so testing/unstable
> > were vulnerable, but the stable kernel itself was unaffected, so it was
> > a bit safer to be running the stable kernel since the code was older
> > (i.e. there was more time to find and fix issues). For example, the
> > vulnerability for one of the local privilege escalations that was
> > exploited in the wild was introduced in 2.6.30, so lenny wasn't
> > affected, but testing/unstable were.
>
> LWN's analysis of age of introduction of kernel security holes in 2010
> doesn't seem to agree? http://lwn.net/Articles/410606/
>
> | So, in a sense, the above-mentioned kernel hacker was correct - an
> | awful lot of the vulnerabilities fixed over the last year predate the
> | git era, and are thus over five years old.

LWN's analysis is far from comprehensive, and the conclusions are not
based in sufficiently rigorous analysis, but instead on the usual
numbers game. Their reporting is however very useful as a basis for
further research.

The first fact that they completely miss is that not all CVEs are
created equal. A memory info disclosure gets a CVE just like a
privilege escalation that has known exploits, but both are on the same
playing field in the numbers game. Annecdotally, CVE-2010-3301 and
CVE-2010-1146 had an exploit in the wild, and 2.6.26 was never
affected. The only issue that had an in-the-wild exploit affecting
lenny in that list (that I'm aware of) was CVE-2010-3081 (and lenny
would have sidestepped that too if it had had been even more
conservative and gone with the older/stabler 2.6.25).

Even playing the numbers game with a bit more thoughtful analysis with
the LWN data, lenny looks a lot better. It can be seen that lenny
(2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities
listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of
52). In my opinion that's a rather substantial difference, and thus a
problem worth pondering.

> At best, you seem to be grossly oversimplifying. In the immortal words
> of FaceBook, "it's complicated".

Yes, I have taken a hard problem (that of improving overall testing
security), and divided it into a specifically manageable part that I
want to attempt to conquer. That process can indeed be called
simplifying, but it is an inevitable consequence of problem solving,
and not something to be treated as a flaw.

> > I'd like to propose a solution to these two problems: only upload known
> > rock solid longterm cadence upstream supported kernels into
> > testing/unstable. This will hopefully reduce the amount of transition
> > delay since the longterm kernels should have fewer RC issues (after
> > they've had a little time to cook of course).
> >
> > There are, of course, some undesirable consequences to this plan. One
> > is that a certain subset of testing users expect the latest shiny all
> > the time; but they can easily get their fix from the experimental
> > kernels instead, so that isn't really a problem (I think).
>
> I feel that unstable is heading in much too stable a direction already.
> I think that Bdale mentioned this (as a possible negative feature of CUT)
> at DebConf.

Why is that such a bad thing? Perhaps the current state is simply an
inevitable consequence of progress, or in the terminology of the
fashion industry, "experimental is the new unstable".

> > The second issue is that testing d-i will not support the latest and
> > greatest hardware and features. I think this can be solved by
> > providing two sets of d-i media for testing (one that uses the longterm
> > testing kernel and one that uses newer experimental kernel).
>
> This seems likely to increase the workload of the d-i (and CD..) team
> significantly.

Yes, there will of course be a larger workload to maintain two sets of
testing d-i media, although only one (the one based off experimental)
would be likely to have any breakage, so the stable one won't need too
much attention.

> And wouldn't it result in either an installed system that
> used unstable's old kernel and so didn't work, or used experimental's
> kernel and so didn't auto-upgrade to fix security holes?

The experimental media would be provided with zero claimed security
support, the other media would get full security support. I don't see
why you think that would be broken though; it would be using the
current set of packages so it should remain stable (as long as all d-i
development moves to experimental).

> Also, what are teams like the X team to do, when their packages depend
> on new kernel features? How are we supposed to ever integrate support
> for the new kernel distribution-wide if unstable constantly has an old
> version? Should the whole distribution lag years behind the state of the
> art?

That can certainly still happen; it will just be close to the freeze,
rather than right now. In the meantime, they can stage their updates
in experimental (or provide a compatibility layer).

> > Anyway, I think this would go a long way toward improving the quality
> > of security support in testing and thus reducing the common advice/meme
> > that users should avoid testing if they're concerned about security.
>
> A meme that is not founded in truth, as you can see if you compare
> existing known security holes in stable and in testing at most points in
> the release cycle. Perhaps the project should consider how it allows
> these types of myths to stand up when their foundations are so easily
> disproven?

The meme actually continues to be true, but to a lesser degree than in
the past. That's thanks to the herculean and thankless efforts of
members of the testing security team such as Moritz Muehlenhoff, Nico
Golde, Raphael Geissert, and many others for the past couple years.
Let's take the freedom made available by the new cycle to try to
address one of the biggest remaining offenders.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110207225453.d45c85dd.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110207225453.d45c85dd.michael.s.gilbert@gmail.co m
 

Thread Tools




All times are GMT. The time now is 02:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org