Re: RFC: creating a security team
- From: Brian Cameron <Brian Cameron Sun COM>
- To: Vincent Untz <vuntz gnome org>
- Cc: gnome-hackers gnome org
- Subject: Re: RFC: creating a security team
- Date: Mon, 26 Mar 2007 16:10:03 +0800
I'd think another good responsiiblity for a GNOME security team would
be to compile some documentation (perhaps a website) that discusses
all known security related issues with the desktop. By "issues", I
mean things that sysadmins might want to be aware of, configuration
choices that affect security (e.g. /etc/orbitrc), and perhaps some
information about how GNOME works to ensure a secure user environment.
For example, it might be nice to have some information about how
programs like gnome-keyring, GDM, gnome-screensaver, etc. work from
a security perspective (which could simply be pointers to the module
documentation)
In our Solaris ARC (Architecture Review Committee) process, I had
to put together a security analysis of the desktop. I think this
document contains much of this sort of information. It's perhaps a bit
out-of-date, having been written mid-2004, but I think much of the
information is the same. I sent this document to desktop-devel-list
for community review, so you can find it here:
http://mail.gnome.org/archives/desktop-devel-list/2004-July/msg00385.html
I'd also be happy to participate in such a security team.
Brian
Le vendredi 23 mars 2007, à 13:16, Federico Mena Quintero a écrit :
El mar, 20-03-2007 a las 20:49 +0100, Vincent Untz escribió:
Would it make sense to create a small security team? I guess it wouldn't
be a lot of work, since it'd be mainly contacting the relevant
maintainers. We would probably create a private security gnome org
mailing list. And also, we could add a small checkbox in bugzilla to
mention that a bug is security-related, so it should be hidden by
default (and the security team would be cc'ed).
Getting reports on security bugs -> an alias for the release team is
probably fine; make sure distributor-list gets notified as well.
I'm not sure about using an alias for release team: usually, security
bugs are hidden before there's a fix delivered. That's why I suggested a
private security gnome org mailing list. Members of this list could well
be the release team.
Someone *may* need to get their act together and patch obsolete GNOME
releases as well :)
I'd love to understand that this means you're volunteering for this ;-)
Notifying distributors of security fixes -> do we need anything more
than to mail distributor-list when a fix is available? We can ask
maintainers to mail that list when appropriate.
Again, I'm slightly worried that mailing a public mailing list might not
be perfect if the fix didn't go downstream first.
Vincent
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]