Hi, * Michael S. Gilbert <michael.s.gilb...@gmail.com> [2009-04-27 15:27]: > On Tue, 21 Apr 2009 23:54:36 +0200 Nico Golde wrote: > > turns out CVE-2008-6679 also is fixed since 8.64. > > The only unfixed issue in this report is CVE-2009-0196. > > > > Michael, please better check the code next time, this would > > have save me a lot of time this evening. > > I appologize. I have been relying on changelogs, rather than code > review. ghostscript doesn't have a changelog, so I had no idea that > those CVEs had been fixed.
Sorry this doesn't work in most of the cases, usually changelog entries are missing :) > My intent is to get information into the tracker as soon as possible and > bug reports submitted. My perception is that once the bug is > submitted, it is now the maintainer's responsibility to work with the > security team, determine affected versions, and get patches ready. That doesn't work because either the maintainer is not available or he is not experienced in handling security issues. Sure there are some maintainers who are very capable but the truth is most of the maintainers are not (why should they anyway). > It seems overburdening that the security team does almost all > of the work. Shouldn't we rely on the maintainer to do his/her fair share? No sorry, as outlined above we can't always count on the maintainer being available (xpdf is a good example) and we really have to do more than just coordinating things. > I mean, it is their package and they should be intimately familiar with > it and upstream's changes. > > If I should be doing more code review, I will try. Do you have any > guidelines or workflow that I should follow? It would be good to have > this kind of stuff documented for other newbies so that there isn't so > much trial-and-error like I'm running in to. I don't know of any guideline and I don't really have an idea how one should look like, read the CVE id description, understand what this bug is about, find the piece of code that is responsible for this and read. If there is a reference to a patch or you know of a new upstream version that should fix it, look at that, create diffs and check it. The same goes for the CVE id descriptions, if they say that something is fixed in version xy or something is vulnerable up to version xy, don't rely on that but check the code. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted.
pgpNryht9rzsE.pgp
Description: PGP signature
