This same discussion is taking place in a few forums.  Are you opposed to
creating a security contact point for the kernel for people to contact
with potential security issues?  This is standard operating procedure
for many projects and complies with RFPolicy.

http://www.wiretrip.net/rfp/policy.html

Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
It would be nice to have a more centralized place for all of this
information to help track it, make sure things don't fall through
the cracks, and make sure of timely fix and disclosure.

In addition, I think it's worth considering keeping the current stable
kernel version moving forward (point releases ala 2.6.x.y) for critical
(mostly security) bugs.  If nothing else, I can provide a subset of -ac
patches that are only that.

I volunteer to help with _all_ of the above.  It's what I'm here for.
Use me, abuse me 

thanks,
-chris

===== MAINTAINERS 1.269 vs edited =====
--- 1.269/MAINTAINERS	2005-01-10 17:29:35 -08:00
+++ edited/MAINTAINERS	2005-01-11 13:29:23 -08:00
@@ -1959,6 +1959,11 @@ M:	christer <at> weinigel.se
 W:	http://www.weinigel.se
 S:	Supported

+SECURITY CONTACT
+P:	Security Officers
+M:	kernel-security@{vger.kernel.org, osdl.org, wherever}
+S:	Supported
+
 SELINUX SECURITY MODULE
 P:	Stephen Smalley
 M:	sds <at> epoch.ncsc.mil
===== REPORTING-BUGS 1.2 vs edited =====
--- 1.2/REPORTING-BUGS	2002-02-04 23:39:13 -08:00
+++ edited/REPORTING-BUGS	2005-01-10 15:35:10 -08:00
@@ -16,6 +16,9 @@ code relevant to what you were doing. If
 describe how to recreate it. That is worth even more than the oops itself.
 The list of maintainers is in the MAINTAINERS file in this directory.

+      If it is a security bug, please copy the Security Contact listed
+in the MAINTAINERS file.  They can help coordinate bugfix and disclosure.
+
       If you are totally stumped as to whom to send the report, send it to
 linux-kernel <at> vger.kernel.org. (For more information on the linux-kernel
 mailing list see http://www.tux.org/lkml/).