Difference between revisions of "Security Task Force"

From ArchWiki
Jump to: navigation, search
(Removed Alternative 2)
m
Line 1: Line 1:
 
[[Category:General]]
 
[[Category:General]]
 
+
[[Category:Security]]
 
This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [http://bbs.archlinux.org/viewtopic.php?t=13985]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.
 
This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [http://bbs.archlinux.org/viewtopic.php?t=13985]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.
  

Revision as of 23:11, 31 July 2005

This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [1]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.

Philosophy

STF should help the developers, not add more work to them. Participation in STF should be voluntary and, with the exception of one or more TUs, left to the non-developers. STF should conform to the Arch Philosophy - following the STF recommendations should be optional for all users of Arch Linux.

Purpose

STF should embody the efforts of the "security-conscious" part of the Arch users population. Server owners, maintainers of workstations in production environments as well as concerned personal users would gain the benefit of relatively prompt security updates. STF should help alleviate two important problems.

Mirror update speed

STF important security notices will include a direct link to the updated package on one of the central servers. This allows the users to manually download the updated package and pacman -U it.

Maintainer's "not-fast-enough" reaction

Arch Linux developers are volunteers with their own personal lives. They might not have time to promptly address updates of their packages. They might have not heard about a recent security update. STF members would suggest the maintainers to update their packages. If the package has not been updated by the maintainer in, say, 2 days, an interim package would be created by one or more TU members of STF.

Example

A big security exploit has been found for package-1.5.8. The developer of this package has released 1.5.9 that fixes this exploit. An STF member picks up this information from some mailing list he/she is following. Since the member believes this constitutes an important security update (see below), he/she contacts the maintainer of package Arch Linux package.

Once the maintainer addresses the issue and updates the package to package-1.5.9, the STF member posts on the "Arch-Security" mailing lists something like this:

Package 1.5.8 has a significant buffer overflow bug, etc. etc. See 
LINK FROM BUGTRAQ HERE, ...

Package 1.5.9 fixes these issues and is now available in the repo. If 
you are on a slow mirror, you might want to download the package 
directly and update it via "pacman -U pkgname". LINK HERE

Implementation

What constitutes an important security update?

This is left to STF members. An update to, say, apache would definitely be considered important. On the other hand, member might find a security flaw in gaim not to be of too much importance. How big the security exploit is also affects the reasoning. If it is a relatively popular network program and allows arbitrary code execution then it will probably be deemed important.

It is worth noting, though, that STF should aim towards having as little security notices as possible. If there is too many STF notices, the users may feel overwhelmed, or maintaing STF would be too much of a burden. Therefore, STF members would be advised to report only truly important security updates in their judgment.

Infrastructure

STF members would need an "Arch-security" mailing list, hopefully linked from archlinux.org webpage. For inter-STF discussions, a forum thread should be enough.

STF members' duties

The members would need to read their favourite security-related mailing list and act accordingly. TUs might need to build some interim packages, however, hopefully that should only be a small number change in PKGBUILD.