Re: [Secure-testing-commits] r11636 - data/CVE
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
Reply to: