Re: Getting started

[Johnathan Ritzi <jrdioko@gmail.com>]

Thanks for the details! Below is a proposed patch to the introduction file. Questions about what I added:

• Did I get everything that needs to be checked before marking a CVE NFU?
• Is there an easier way to search for removals than looking at the full removals .txt file?
• Is there an better way to use the check-new-issues script on a stable system other than creating a sid chroot and running it (and svn) as root?
• Is everything below accurate?

Thanks,
Johnathan


Index: narrative_introduction
===================================================================
--- narrative_introduction    (revision 16973)
+++ narrative_introduction    (working copy)
@@ -131,16 +131,48 @@

 service ...)
    NOT-FOR-US: Safari
 
+Before marking a package NOT-FOR-US, the following should be done:
+    - Read the full CVE description to determine the product name
+    - Search for the product using apt-cache search <name>

+    - If a file was referenced, search for the file using
+      apt-file search <name>
+    - Search the wnpp list (http://www.debian.org/devel/wnpp/) to see

+      if the product has an ITP or RFP (see "ITP/RFP packages" below)
+    - Search the ftp-master removal list
+      (http://ftp-master.debian.org/removals-full.txt) to see if the

+      issue was present in the past but the package was removed (see
+      "Removed packages" below)
+
+If there is any doubt, add a NOTE with your findings and ask others to
+double check.
+

 There is a tool that helps with sorting out all the NOT-FOR-US issues: 
 See "bin/check-new-issues -h". For the search functions in 
 check-new-issues to work, you need to have unstable in your 
 sources.list and have done "apt-get update" and "apt-file update". 

-Having libterm-readline-gnu-perl installed helps, too.
+Having libterm-readline-gnu-perl installed helps, too. If you are not
+running unstable, you can search at http://packages.debian.org or

+set up an unstable chroot:
 
-Please also make sure to check the wnpp list for possible <itp> items and
-the ftp-master removal list to see if the issue way maybe present in the past
-but the package was removed

+http://www.debian.org/doc/manuals/reference/ch09#_chroot_system
+http://wiki.debian.org/Debootstrap

 
+ITP/RFP packages
+----------------
+
+If it is a package that someone has filed an RFP or ITP for, then that
+is also noted, so it can be tracked to make sure that the issue is
+resolved before the package enters the archive. ITPs are marked with

+<itp>, while RFPs are simply mentioned in a NOTE:
+
+CVE-2004-2525 (Cross-site scripting (XSS) vulnerability in compat.php
+in Serendipity ...)
+        - serendipity <itp> (bug #312413)
+
+CVE-2008-0851 (Multiple cross-site scripting (XSS) vulnerabilities in Dokeos 1.8.4 ...)
+        NOT-FOR-US: Dokeos
+        NOTE: there is an RFP for Dokeos #433352
+
 Reserved entries
 ----------------
 
@@ -163,18 +195,6 @@
 CVE-2005-4129
         REJECTED
 
-ITP packages

-------------
-
-If it is a package that someone has filed an RFP or ITP for, then that
-is also noted, so it can be tracked to make sure that the issue is
-resolved before the package enters the archive:
-
-CVE-2004-2525 (Cross-site scripting (XSS) vulnerability in compat.php
-in Serendipity ...)
-        - serendipity <itp> (bug #312413)
-
-
 Packages in the archive
 -----------------------

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