The list, which the developers plan to announce soon, is an answer to some open-source developers' concerns that reports of security flaws were getting lost in the large amount of e-mail messages sent to the kernel team.
"We aim to keep the process as open as possible," said Chris Wright, Linux kernel developer at Open Source Development Labs. "Sometimes, people prefer to report security vulnerabilities in private to make sure the implications are understood and the fix is known before going public. This is in place to facilitate that and keep things from falling through the cracks."
The mailing list will be the contact point for security issues in the kernel and is the result of several weeks of mulling over how accessible to the public the list should be.
Disclosure of security issues has been a heated debate, both for the kernel development group and in the. While some argue that publicly revealing a software bug in popular software hurts the security of the Internet, others point out that flaws are generally caused by poor development procedures and a lack of focus on security.
The current practice in the commercial software industry is to request that security researchers who find flaws wait until the software company has created a fix and is ready to release the update before divulging details of the vulnerability. However, the creator of the original Linux kernel,, condemned taking that approach in Linux development.
"I personally prefer as much openness as possible and feel pretty comfortable with it," he said in a recent e-mail interview with CNET News.com. "It requires--but thus also encourages--a certain level of security to be in place, and people who feel nervous about that level of security at any point in time thus tend to argue against openness."
Compared with commercial software makers and even the Linux vendor security list, Vendor-sec, the Linux kernel development team appears to be adopting that goal of open disclosure.
In a draft statement regarding the list, the kernel team stated: "We prefer to fully disclose the bug as soon as possible. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested or for vendor coordination. However, we expect these delays to be short--measurable in days, not weeks or months."