I think there is much more that can be done besides the short list from Ananda. The thing you have to remember is that "security" does not mean "I'm running the newest code.". Things to remember: 1. There is no such thing as "secure". 2. Proper security consists of multiple layers of defense. Additional examples of things the AST could do: 1. Propose changes to default configuration files to be "more secure", and have more documentation around setting up services in a more secure fashion. 2. Assist with SELinux & GRsecurity projects. 3. Propose changes to initscripts to make sure software drops privileges and chroots where possible, or at least make it easier to enable such features. 4. pie / ssp 5. PaX 6. Audits This list is by no means complete, but the end goal should be to make things more secure. The other thing to remember is that just because you are running the latest rev of code, it doesn't mean there aren't vulnerabilities, or unpatched issues. Developers don't always consider issues that could be security issues to be security issues, or don't they understand the security implications of certain issues. Lastly, just because Arch is a rolling release it doesn't mean that everybody that uses it just updates everything at a whim. Some people do believe in change control and it may be useful for those people to be aware of security issues in certain packages that need to be updated. Not everybody does a daily/weekly/monthly system update. For some people "stability" is a feature. Some people might choose to upgrade packages which are security conscious while taking caution to upgrade a package they are dependent on. TOFU. -Miah On Thu, Jun 17, 2010 at 3:06 PM, Jeroen Op 't Eynde <jeroen@xprsyrslf.be>wrote:
On Thu, 17 Jun 2010 20:57:56 +0200, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
1. Check for vulnerabilities
2. Know how to use PKGBUILDS and abs 3. Can spare some time to send announcements, create interim PKGBUILDs and file security issues on the bug tracker.
1. [testing] users do that 2. [testing] users, Devs and TUs (should) know this 3. see 1 and 2
IMHO, Arch's rolling release and cutting/bleeding edge kicks the need for a security team. Just do your one man thing like any testing user. The only thing I can think of in ways of security is signed packages, so write some code if you are a coder or put some time in a plan on how to achieve this instead of starting a strange vague unofficial security mailing list. If you do have a lot of security issues about arch, just flood the arch-general mailing list. If the devs see 'a lot' of messages concerning security, they might come back on the arch-security mailing list. Just be patient.
-- To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting