[Secure-testing-commits] r14935 - in data: . CVE

Michael Gilbert michael.s.gilbert at gmail.com
Mon Jul 5 14:39:22 UTC 2010


On Sun, 4 Jul 2010 21:45:13 +0200 Moritz Muehlenhoff wrote:

> On Thu, Jul 01, 2010 at 10:44:24AM -0400, Michael Gilbert wrote:
> > On Wed, 30 Jun 2010 17:25:29 +0000, Moritz Muehlenhoff wrote:
> > > - remove a few old undetermined entries for webkit copies for new,
> > >   we won't be able to realistically triage/support them if
> > >   this isn't even done upstream
> > 
> > are kdelibs, etc. going to be removed from squeeze?  if not, i think
> > they really need to receive security support.  it's a matter of getting
> > someone to volunteer for that.  i'm going to attempt to take
> > responsibility for webkit gtk, but i really don't think i can commit to
> > supporting the kde packages since i don't use kde and i'm not that
> > interested.  once i've triaged webkit gtk, the commits/patches will be
> > available for anyone willing support the kde versions.
> 
> We'll need to document that security support for the webkit
> related code in kdelibs, kde4libs and qt4 is limited. We
> can backport/fix anything which is announced by KDE or
> Nokia, but we won't be able to triage the monster flow
> of webkit forks:

ok, but its a bit disappointing that the maintainers aren't willing to
be responsible.  normally lack of security maintenance is cause for the
package to be removed (i understand that's sort of off the table in
this case since it would be a big setback to lose core parts of kde).

> None of the upstreams seem to systematically follow webkit
> security issues and patch their code bases. 

true, but we do have links to most of the commits from other sources,
so it is possible to do the work ourselves.

> Anyone wanting
> to fix this should work with KDE or Nokia to remedy this,
> but we don't need to clutter the tracker with hundreds
> of undetermined entries noone works on.

as you requested, i've intentionally hidden undetermined entries in the
tracker by default, so there is no clutter unless the user opts for the
clutter. i think the state all issues should be tracked as accurately as
possible.  as a consequence, as more issues land on this pile, it
becomes more and more clear that someone really needs to be working that
problem, and perhaps that will prompt someone to take responsibility.

mike



More information about the Secure-testing-commits mailing list