Only auditing current 2.4 code?

[Darron Froese <darron@froese.org>]

Someone had this suggestion (I forgot who and deleted the email) and I
think that that is probably not the correct way to go.

2.4 is still in heavy development and will probably be that way for the
next few months. When it comes out, there will probably be some lag time
between the initial 2.4.0 release and a ready-for-primetime
production-quality release. Then there will be some time after that to
migrate production servers over - if they're even migrated.

2.2 is in use on production servers right now and will be in use for quite
some time. The codebase is pretty stable - there probably aren't going to
be any huge changes (like there will be in 2.4) in the near future.

I think an audit of the 2.2 code would serve quite well as a starting
point. We could:

1. Track that known issues in 2.4 that didn't get back ported to 2.2.
(for whatever reason)
2. Look for other unknown issues and audit away.

There will be plenty of time to audit 2.4 once it's stabilized somewhat -
c'mon, the code freeze was announced in October sometime and it's still
not really frozen. ;-)

Anyways, that's just my 2 cents. I'd love to be able to help but can't
program in C yet.
--
Darron
darron@froese.org


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/