Hi,
* Michael S. Gilbert <michael.s.gilbert at gmail.com> [2009-04-27
15:27]:> On Tue, 21 Apr 2009 23:54:36 +0200 Nico Golde wrote:
> > turns out CVE-2008-6679 also is fixed since 8.64.
> > The only unfixed issue in this report is CVE-2009-0196.
> >
> > Michael, please better check the code next time, this would
> > have save me a lot of time this evening.
>
> I appologize. I have been relying on changelogs, rather than code
> review. ghostscript doesn''t have a changelog, so I had no idea
that
> those CVEs had been fixed.
Sorry this doesn''t work in most of the cases, usually
changelog entries are missing :)
> My intent is to get information into the tracker as soon as possible and
> bug reports submitted. My perception is that once the bug is
> submitted, it is now the maintainer''s responsibility to work with
the
> security team, determine affected versions, and get patches ready.
That doesn''t work because either the maintainer is not
available or he is not experienced in handling security
issues. Sure there are some maintainers who are very capable
but the truth is most of the maintainers are not (why should
they anyway).
> It seems overburdening that the security team does almost all
> of the work. Shouldn''t we rely on the maintainer to do his/her
fair share?
No sorry, as outlined above we can''t always count on the maintainer
being available (xpdf is a good example) and we really have
to do more than just coordinating things.
> I mean, it is their package and they should be intimately familiar with
> it and upstream''s changes.
>
> If I should be doing more code review, I will try. Do you have any
> guidelines or workflow that I should follow? It would be good to have
> this kind of stuff documented for other newbies so that there
isn''t so
> much trial-and-error like I''m running in to.
I don''t know of any guideline and I don''t really have an
idea how one should look like, read the CVE id description,
understand what this bug is about, find the piece of code
that is responsible for this and read. If there is a
reference to a patch or you know of a new upstream version
that should fix it, look at that, create diffs and check it.
The same goes for the CVE id descriptions, if they say that
something is fixed in version xy or something is vulnerable
up to version xy, don''t rely on that but check the code.
Cheers
Nico
--
Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090427/d7e44977/attachment.pgp>