[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Security Updates and kernel-tree fun



On Tue, Aug 09, 2005 at 01:15:36PM -0600, dann frazier wrote:
> On Tue, 2005-08-09 at 14:04 +0900, Horms wrote:
> > Hi,
> > 
> > Referring to
> > http://people.debian.org/~dannf/kernel-stats/kernel-avail.html
> > (thanks dannf) I notice that the following kernel-tree versions
> > are in use in Sarge: 
> > 
> > 2.4.27-10: alpha, i386, ia64, powerpc  (latest)
> > 2.4.27-9:  powerpc
> > 2.4.27-8:  s390
> > 2.4.27-5:  apus    (so old its scary)
> > 
> > 2.6.8-16:  alpha, i386, ia64, m68k  (latest)
> > 2.6.8-15:  sparc
> > 2.6.8-13:  hppa, powerpc, s390
> > 
> > 
> > Now as I understand, security updates can only include security fixes.
> > Examining 2.6.8, in the case of arches that use 2.6.8-16, this
> > is easy enough, just add security fixes, make that 2.6.8-16sarge1,
> > and be done with it. Same for sarge2 and so on and so forth.
> 
> I'd like to get an actual "NO" from the security team before giving up
> on sharing a single source tree.  This would save us from adding
> complexity in the build system, which presents its own set of risks.  If
> that sounds ok to Horms and the security team, maybe we could start by
> creating a report of some kind explaining what non-security patches are
> going in, and how the affect various architectures?
> 
> For example, a table of patches versus kernel-image packages, populated
> with symbols noting whether or not the patch is already in sarge or if
> its new, whether the changed code is actually built on that arch, etc.
> 
> Of course, that assumes the security team would consider this sync; if
> not, this is a non-starter.  Security Team: what say you?

Agreed, I'd like to avoid this if we can.

-- 
Horms



Reply to: