[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Getting started



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 <jmm@inutil.org> 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


Reply to: