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.
