Re: Looking for someone to take over.

[Bryan Paxton <bpaxton@securityportal.com>]

On Tue, 17 Oct 2000, you wrote:
> On Tue, 17 Oct 2000, Bryan Paxton wrote:
> > I've put this off long enough, and instead of stamping this project as a
> > dead beast, I'm querying as to whether there is anyone out there who like
> > to take over.
> > Your duties would be nothing but taking over as list owner(for this
> > mailing list), help developers manage projects, set goals, etc.......
>
> I think this project had good intentions, which were unfortunatly
> satisfied through existing lists/channels.

*nod* I agree. 

>
> Members of the security-audit list for example occasionally audit parts of
> the kernel and either report to their own list, or to linux-kernel.
>
> I'd like this list to remain, but only if someone actually intends to use
> it for the purpose it was originally set up for, and not have it turn into
> a list for "Wouldn't it be cool if we had xxx feature".

Yup, and if anyone is still confused about the over all goal they can read my 
original mission statement here:
http://lkap.org/mission.html


>
> Other ideas:
>  - The sorts of things the Stanford students who posted to Linux Kernel a
>    few months ago. Their tests showed up a _lot_ of places we do bad
>    things. If someone would be prepared to take those results and just
>    confirm that they're still true for the latest kernel, it would be a
>    good start.
>  - Someone even submitted lclint outputs to l-k once which turned up a few
>    previously unnoticed bugs.
>  - Tytso's TODO list still shows a lot of areas that could be classed as
>    auditting.
>  - The sort of things that Arnaldo Carvalho de Melo has been posting
>    umpteen patches to l-k. Mostly things like updating drivers
>    to use newer interfaces. The kernel is still carrying a lot of old
>    backage because of this. And remember, if we kill off the old
>    interface, that's less code that needs auditting.
>
> There's no shortage of things that need checking.

hehe, there's probably an overflow of things that need checking : )

On a side note, the first place I'd start is a problem that still exist.
The ability to force the insert of kernel modules, even if you're kernel 
doesn't have support for this.

There was a really good white paper on this, and if anyone has the url to it, 
please let me know.

> Have a list of files and hope people will say "Ok, I'll take
> drivers/blah.c and audit it" ? Personally I don't think that's the right
> approach. We need >1 pair of eyes looking over code, and therefore more
> than one person could be auditting 1 piece of code at a time.
>

I agree, when this first started I tried to setup a list of what to do.
Which of course that didn't work. I mean this is free software, how you gonna 
encourage people to volunteer to work by shoving a list down their throat. 

And after giving this some though I think I'm going to leave the list "as is" 
for right now, that is untill a _group_ of people currently very much 
involved in this project contact me a route of better things.

But despite that all that, we'll just see what happens....

-- 
Bryan Paxton
SecurityPortal, your focal point for security on the net.
http://www.securityportal.com/

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