Security Task Force
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 . Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.
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.
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.
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.
The maintainer addresses the issue day after that 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
The maintainer hasn't addressed the issue in 2 or more days. The STF member posts a plea to STF TUs (see below) to build an interim package. Once this package has been built, the member posts on "Arch-Security":
Package 1.5.8 has a significant buffer overflow bug, etc. etc. See LINK FROM BUGTRAQ HERE, ... A temporary build of 1.5.9 fixes these security issues and is available HERE.
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.
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.