On Thu, Sep 11, 2008 at 3:17 PM, Guilherme M. Nogueira g.maionogueira@gmail.com wrote:

Nice project, Hugo! Really.

And just a correction: Its a common mistake for us in Brazil, when you said "what we pretend" I think you meant "what we intend to do"

Yeah, you are right. In english "pretend" is something like "simulate" or "fake", right? Im sorry. Thats not what i tried to say.

"Intend" is the right one. Thank you.

-- Hugo

On Thu, Sep 11, 2008 at 12:48 PM, Hugo Doria hugodoria@gmail.com wrote:

The idea now is to create a way to notify a package maintainer about the vulnerability and add a way to mark it as fixed in Arch. We also want to create a login so the maintainers can mark all the vulnerabilities that they fixed and a rss feed.

Arch-Sheriff is still experimental and there are some things that needs to be fixed. But i think that you guys can see what we pretend and where we are going. :)

And, please, tell me what you think about this. Any suggestion is welcome.

Very nice. Being python and all, we might be able to incorporate this into the Arch website and use that package database. Is there anyway you can sort the table by package name (or better yet, just add a little JS sorter script in there so people can sort by any column they want)?

-Dan

On Thu 2008-09-11 14:48, Hugo Doria wrote:

Hi everyone, [...] And, please, tell me what you think about this. Any suggestion is welcome.

You may want to remove the "dashed" border, it's fugly :)

On Thu, Sep 11, 2008 at 18:17, Hugo Doria hugodoria@gmail.com wrote:

Yeah. I could add a .sort() to all lists (vulnerabilities, warning and eol) easily. Now Sheriff is showing all packages using a chronological order (its the default in NetBSD too). We think its better use this way. A JS sorter script would be great though. I will try to add it.

Thank you for the suggestion.

Hugo, give jQuery Tablesorter [1] a try.

BTW, congratulations!

[1] http://tablesorter.com/docs/

Hi,

On Fri, Sep 12, 2008 at 8:29 AM, raca raca@algohumano.net wrote:

The vulns are upstream problems and not packaging problems, so I don't know if this is really that useful for the arch developers. I don't see the packages maintainers making patchs for every vuln on the fly before a new version comes out.

Very often developers take too long to release a new version correcting the vulnerabilities. An example is the current Python release. So we cannot count on having the latest versions of the software.

Fortunately, when a vulnerability is disclosed, often the package developers already came with an upstream patch, or the people that discovered the vulnerability may have provided a patch to fix it.

Unfortunately, currently most package maintainers are unaware when a new vulnerability related to their packages is disclosed. Arch-Sheriff comes to solve this.

One of our ideas is to inform the Arch package maintainer when the pkgsrc package is fixed, and give a link to the package in pkgsrc cvsweb. So the Arch package maintainer will be able to easily look for the patches applied in pkgsrc and apply the same patches in his package.

I think this is a better tool for admins to know which programs are vulnerable at the moment.

The idea is that Arch package maintainers would be informed to fix vulnerabilities, then mark the vulnerability as fixed in Sheriff. This will give us that list of vulnerabilities on hold, then the users can know which packages are currently vulnerable.

However, the package maintainers would only need to mark the vulnerability as fixed if it was needed a patch against the latest version to fix, as Sheriff already compares the vulnerabilities by package version. So if a vulnerability is fixed by package upgrading, it will be automatically detected by Sheriff.

Best regards,

Paulo Matias

Hi,

On Fri, Sep 12, 2008 at 1:29 PM, raca raca@algohumano.net wrote:

I tested it and when saw the mplayer vulns I went.. oh god, never use it again lol.

mplayer 1.0rc2 is very old and the mplayer devs are reluctant to do new releases (since ffmpeg has no releases either). The "stable" version is the svn version, which might not suffer from so many vulnerabilities.

Cheers,