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

Re: sarge kernel security transition



dann frazier wrote:
> The ABI/security discussions have left me with a question - at what
> point does security maintenance of our kernels transition from the
> debian-kernel/testing security teams to the Debian security team, and
> how will we interact with one another?  I assume there will be some
> overlap, but it might be good to define this transition before it
> happens.

When security.debian.org has to be used the security team needs to
be in the loop.  We need to work together with the kernel maintainers,
though.  I believe that this is even more important for the kernel
than for other packages.

> Source Control
> ==============
> I assume at some point we'll want to branch off our 2.4.27/2.6.8 kernels
> and lock them down for only security changes.  I think it would be nice
> to keep our svn repo up to date with the security releases, even if it
> is an after-the-fact svn_load_dirs dump.  I assume this would fall to
> the kernel team to maintain, if we choose to do so (versus the security
> team doing the committing).

That should be doable.

> Sarge package vs. latest packages
> =================================
> When the first security update happens, will the uploaders start with
> whatever is in sarge, or the latest version?

Regular security updates always take care of the version that was released
with the released/frozen Debian distribution.  When the kernel is frozen,
that package should probably be used.  Until that, a more recent version
can be used as basis, I guess, to be judged by the kernel team.

Updates to the once-released distributions will be based on the
latest version in that particular distribution (here: woody, sarge).

> When sarge happens, its likely there will be pending changes in
> kernel-source in svn, and maybe in sid.  Its also possible that some
> kernel-image re-builds may not have propagated into sarge yet.  The
> changes here should be mostly security fixes at this point; however
> we've not formally frozen these packages to my knowledge, so this isn't
> guaranteed.  Maybe now is the time to do that?

Ack.

Regards,

	Joey

-- 
The only stupid question is the unasked one.



Reply to: