dev meeting irc june 5th 1400EST 2200CET

Jon South striker at lunar-linux.org
Tue Jun 1 03:29:15 GMT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Elaine wrote:
| Jon South did inscribe thusly:
|>I'd also like to add to the agenda, Security Updates and Update
|>Monitoring. It has already been discussed that a security team is needed
|
| I'd actually prefer to table that for a separate discussion -- there is
| more than enough to be getting along with already (imo) -- more discussion
| below

I actually meant them as 2 seperate topics.

|>there are several modules that slip through version bumps
|>and in some cases go 2 years without being bumped.
|
| Please advise which modules you mean?

The most recent one that I can recall was gnaughty (I'm sure no one was
heartbroken about that one though :P) which had not been updated since 2002.

| Generally, I don't think a 'team' will make us more effective, rather the
| overhead will slow down hwo it happens now (some individual notes a bump/
| fix is needed and does it).

| Basically I think it comes down to this: either you trust the ppl who have
| cvs or you don't. Our devs have been pretty responsive to fixing both
| crit/sec updates and found things in lunar itself.

I dont mean security 'team' in the sense that a set amount of people
should join it and be forced to scour the internet for the latest
exploits/vuln's; what I mean is, and what I hoped to discuss at the
meeting, was the need for a set of security lists/websites that at least
a few lunar devs should monitor and check. As you know, some of us
already do that, of course. It would be nice if we had a set of
guidlines as well, governing the way security issues are dealt with. I'm
sure some would agree that I should not be the one to bump a
gnome/kde/glibc/linux module just because I saw a security issue for one
of them. I'm not the maintainer of those modules, and would not feel
comfortable bumping/testing them myself without the maintainer/sofar's
permission.

| The best thing (imo) we can do for lunar's security is improve the overall
| quality of the lunar code.

I dont particularly think /lunar/ per se, has any security issues with
the quality of any code in the core (at least that I know/heard of),
unless we have scripts that run set(u|g)id. I believe quality of lunar
code goes under a different topic of discussion.

- -Striker

- --
The system requirements said "Windows 95 or better."
So I installed Linux.

v1sw6CUhw5ln4pr5ck4ma6/7u8Lw3Tm5l6+8GOa21s6Mr2e5+7t5/6TNDVESLFRXMb3Hp0en6/7g9ASTHCNMP
www.hackerkey.com

Registered Linux User: 332618
<http://striker.interhact.net/striker.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAu/gLy3qPFSnhIpMRAtdLAKDDqn5uZBYFk6UpicoNqKWplgWQggCglPr6
HZUjX+mINBfccDfPWdpPN5M=
=OOqw
-----END PGP SIGNATURE-----


More information about the Lunar-dev mailing list