As a followup: what amount of "checking" should be done before marking an issue as fixed? Is a changelog entry by the maintainer saying that CVE/bug has been fixed enough? Or do people on this list research the vulnerability itself, check the code, and confirm that the patch actually fixes the issue (regardless of claims by the maintainer)?
-Johnathan On Sat, Jul 23, 2011 at 7:55 AM, Moritz Muehlenhoff <[email protected]> wrote: > On Thu, Jul 21, 2011 at 04:26:57PM -0700, Johnathan Ritzi wrote: > > Hello, > > > > I'd like to help out with the Tracker (in whatever minor ways I can), so > I > > created an Alioth account and requested to be added to the project. I've > > read the Introduction document and understand the general idea, but was > > wondering how to get started. Should I make edits but leave the "TODO: > > check" line in for someone else to double-check my work for a while? > > Peer review is done via the commits list, so please remove the TODOs > rightaway. > > > Or is there documentation somewhere > > explaining exactly what needs to be checked before an issue can be > triaged > > into one of the various categories? > > If you mark something as NOT-FOR-US: > - Make sure it's not in the archive, e.g. by searching on a sid chroot > with apt-cache search, googling for "software name Debian" etc. > Sometimes software was in the archive at an earlier time and now removed > or vice versa. This looks tedious in the beginning, but with a bit of > experience it gets really smooth. I can replace packages.debian.org in > my mind these days :-) > - If in doubt, just add a NOTE with your findings and ask people to > doublecheck > > If you mark something as affecting Debian: > - If it's apparently unfixed, file a bug so that the maintainers can chime > in > - If it apparently fixed (per CVE description) double-check (sometimes > the CVE descriptions or information from databases like Secunia is > incorrect) and set the fixed version for unstable. If you have > additional information wrt oldstable/stable (e.g. vulnerable code not > present and as such not affected), please add it as well. > > It would be nice if you could integrate missing information into the > introduction document :-) > > Cheers, > Moritz >
