Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote:
> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote:
>> Sven Luther wrote:
[...]
>> >
>> > This is not a ubuntu related problem though, and the help the ubuntu
>> > kernel/security team has provided us was invaluable, but it should maybe not
>> > be necessary if the information was not unrightfully hold from us in the first
>> > time.
>>
>> You seem to be implying that ubuntu is providing you with confidential
>> prior warning about kernel security holes, but I really doubt this,
>
Actually, that was the case for a while (before ubuntu's kernel team went
on vacation, and I went on vacation). However, w/ all the vacations
that have been happening, it hasn't been the case for a few months.
> Nope, but i was at one time
hinted that i should wait a couple of days
> before starting a 12 hours build.
>
>> since many of the ubuntu secutity advisories that I've backchecked
>> against the debian kernels have turned out to still be unfixed in the
>> kernel teams's svn weeks later.
>
> There is nobody actively doing debian security for unstable kernels
> right now, well, not consistently, and not with the kind of advance
> warning that is needed. This is rather a disapointement, i believe. But
> i understand that our security team doesn't want or can care about
> unstable/testing security updates.
Unfortunately, we don't have any real database of vulnerabilties to ensure
that they're fixed. I've been using
http://people.ubuntu.com/~pitti/ubuntu-cve.html, but that's about it. The
official CAN database is close to useless, as the CAN descriptions are
generally not publically available for weeks after the vulnerability is
publically known. As well, each kernel release is quite a pain due to the
time involved in building and coordination across architectures (I've had
my releases tagged and then backed out, for example); so, that combined w/
the rate of kernel vulnerability generally means we stick to a
release schedule of once or twice a month for each kernel (which ranges
from 2 or 3, since we have to track 2.6.8 specifically for sarge, as well
as the latest 2.6.x kernel, plus 2.6.x-1 if 2.6.x is rotting in NEW). We
end up having anywhere from 5-10 security-related patches in each release.
For example, I just released kernel-source 2.6.8-14, but have not bothered
to build a kernel-image for i386 yet, as horms committed another security
fix to SVN for -15 about a day after I released. Instead, I guess I'll
make sure he doesn't have any further commits, check ubuntu's latest
kernel advisories, talk to pitti to make sure he doesn't have anything
pending, release -15, and try for an i386 image at that point. This i386
image will, of course, have to sit around in NEW for a bit, as the ABINAME
needs to be bumped by at least 2 different security related patches in -14.
After that, I'll try some sparc kernel-images for 2.6.8 and 2.6.10. And
after that, I may even get the chance to look at 2.6.11, but I doubt it;
I'll probably leave that to svenl or something.
Reply to: