On Wed, 15 Oct 2008, Hugo Doria wrote:
A few days ago I showed Sheriff [1], . IMHO it is good tool to help us improve Arch's security.
What is missing now is a way to integrate Sheriff with Arch and mark a vulnerability as fixed.
You need first to to 2 fixes on Sheriff: - as discussed in IRC some time ago, you should use the current db to generate your list, not the content of /var/lib/pacman/sync/ on Gerolde. 'pacman -Sy' is ran very infrequently on Gerolde so your list currently contains warnings for packages in the repo that were fixed weeks ago. - Sheriff list a vulnability for realplayer which is not even in the repo. If you want to keep track of vulnerability for community/unsopported package, it's fine. But you should separate them in 3 categories: core/extra community and unsupported. Either have them on their separate web page or implement a repo column so we could use the sorting to regroup them. Devs will take care of core/extra, TU for community, TU/users for unsupported. No one here has the time or patience to go through a page of needed security update to realize that most of them are already done or that the packages are in community or in unsupported.
It would be great if we could add a field in PKGBUILD to indicate that it fixed a vulnerability. It could be a comment (as the 'Contributor' tag work) or even a new variable (fix=('vulnx' 'vulny')).
All this, of course, leads to some other things as commitment to correct flaws or the creation of a security team. I do not know. I am open to suggestions and would really like to know what you guys think about it and if you think it is worth.
[1] http://dev.archlinux.org/~hugo/sheriff/
-- Hugo
I thing a PKGBUILD field is overkill. We just need to make sure that packages updates/fixes are done promptly when it's for a security fix. Currently, because of the major orphaning a while ago, several packages are in limbo. IN 2 days, all orphaned packages will be availiable for open adoption. Hopefully, most of them will get a new maintainer with more time/interest so they'll be updated soon after being adopted. That will probably fix several of the pending security update. We could also have a couple of dev in a security team to do the updates when the mainatiner is busy. Maybe open a bug report and assign it to the package maintainer. If the package is not updated after X days (assuming the maintainer didn't replied to the bug report saying he's too busy), then the security team updates the package. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.