On Wed, 29 Apr 2009 12:21:17 -0700 Kees Cook wrote: > Hi, > > On Sun, Apr 19, 2009 at 05:05:14PM -0400, Michael S. Gilbert wrote: > > hence, i think the following would be a good process for ubuntu > > security triagers: > > > > 1. triage issue in ubuntu > > 2. check status of CVE in debian (debsecan could be used for this) > > 3. submit bug report to launchpad (with link to debian bug report if > > it already exists) > > 4. update ubuntu security tracker > > 5. if no existing debian report, submit bug to bugs.debian.org (note > > that bin/report-vuln in secure-testing svn makes this semi-automated), > > and preferably include a link to the launchpad report so the debian > > maintainer can make use of your existing work > > 6. wait for email from the debian bts with bug # and update > > data/CVE/list with this info > > I should probably describe the two hats I wear: I'm employed by Canonical > to work on Ubuntu's "main" repository, and I'm a Debian Developer with some > of my free time. Wearing my Debian hat, my time is limited, so I focus > on areas of Debian that interest me. As it happens, I don't tend to spend > a large amount of my Debian time on security issues, since that's my day > job. :) > > Now, with my Canonical hat on, my role is the same as the other two > Canonical-employed Ubuntu Security Team folks: we are mandated to work on > security issues in "main" and to help facilitate work on "universe". To > this end, our current workflow for "step 1" above is to map CVEs to > packages in general, and if the package is in "main", we dig further to > identify specifically which versions of packages are affected, etc. I > would call this "mapping" and "triage". Since we only triage a subset of > Debian's repository, we are not in a good position to triage everything > for which there is a CVE assigned. However, since we do mapping for the > entire repository, that's the part of our workflow I've been trying to get > fed back into Debian. I've been doing this for some time now with NFUs. > > I feel that both "mapping" and "triage" are non-trivial tasks and had > assumed that helping with the "mapping" part would be a good thing. > Since the Ubuntu team has many priorities and tasks to juggle beyond > strictly triage work, we cannot commit to doing full triage of everything. > It's not because we don't want to help, but rather because our work > priorities demand our attention in other places. I do, however, want to > try to help in ways that are useful to Debian, obviously. > > The sync of NFUs seems to be generally accepted, so we'll continue to do > that. Should we continue to attempt to open <unfixed> entries for stuff > that is not yet listed in the Debian tracker?
i completely understand where you are coming from, and i do appreciate the fact that you have a limited amount of time to work non-ubuntu issues. however, ubuntu is deriving a whole lot of value (i've heard that canonical is now close to turning a profit) from the volunteer work that goes on inside of debian, and i would hope to see a reasonable amount of emphasis on returning some of that favor. i personally am not looking for you to triage the whole set of packages in the debian archive, but instead that when you do triage an issue in ubuntu main that you provide some reasonable assistance (bug report and patches) back to debian so that we can make use of your work and hopefully push out updates for the issue at the same time (with the goal of closing the time gap between DSAs and USNs for the same CVE). we want to try to collaborate and reduce duplication of work. hence, what i would really like to see are your patches and discussion pushed into the related debian bug report so that we have an record what's going on on your end. hence, i propose a modified ubuntu workflow: 1. discover an issue in ubuntu main that you plan to issue a USN for. 2. check status of CVE in debian (debsecan could be used for this). 3. if no existing debian report, submit bug to bugs.debian.org (note that bin/report-vuln in secure-testing svn makes this semi-automated), and preferably include a link to the launchpad report so the debian maintainer can make use of your existing work. wait for email from the debian bts with bug # and update data/CVE/list with this info. 4. if there is an existing debian report submit email to bug with links to your launchpad report and patches. hopefully you can convince your management that this type of feedback to debian is beneficial and worth your time and effort. as an alternative, i am planning to get up to speed with the ubuntu-cve-tracker, and maybe i can derive this information from the work that you are already doing. mike -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
