Re: Bug#594550: RM: webkit/1.0.1-4+lenny2
On Fri, Aug 27, 2010 at 10:56:54AM -0400, Michael Gilbert wrote:
> On Fri, 27 Aug 2010 08:49:54 +0200, Philipp Kern wrote:
> > On Fri, Aug 27, 2010 at 12:01:37AM -0400, Michael Gilbert wrote:
> > > The lenny webkit package has an insurmountable number of security
> > > vulnerabilities [0]. The version included there was of an experimental
> > > nature, and the only front end available is the builtin GtkLauncher
> > > app, which isn't very functional itself and is likely used by no one.
> > > There are no reverse dependencies.
> > >
> > > Please remove the package for the upcoming lenny point release. I've
> > > brought this up with the security team and webkit maintainers [1],[2],
> > > and there has so far been no objection. However, I also didn't get
> > > any responses either way. You may want to try to touch base with
> > > either/both teams directly.
> > >
> > > I think removal is the only supportable course of action.
> >
> > The secure-testing list is inappropriate to ask the security team about a
> > package in Lenny. Please use the appropriate contact and get them to reply.
>
> I was more concerned about getting feedback from the webkit
> developers. I've already talked to Moritz Muehlenhoff from the
> security team about this directly.
That is correct.
> > Some CVEs are listed as "minor issue - no DSA", so it wouldn't be valid
> > to remove it for that.
>
> Perhaps 10 of the 50 or so issues are no-dsa. I think it's valid to
> remove it due to the 40 other issues.
>
> > (Sadly it seems that there's no overview to list
> > a package's vulnerabilities in Lenny at a glance?)
>
> No, there currently isn't a straightfoward way to do that. However,
> you could look at the stable overall page and count the number of
> webkit issues there.
>
> However, it seems a direct removal isn't so straightforward since there
> are two reverse dependencies: mono-tools-gui and
> claws-mail-extra-plugins. Note that the popcon counts are low for
> those: 131 [1] and 258 [2] respectively. Perhaps it would be ok to
> remove them as well?
We would need to check how these packages use webkit, maybe they can be
adapted.
> Or perhaps instead there could be an end-of-life security announcement?
Removal seems cleaner to me in general. An EOL announcement is necessary
anyway.
The much more important question is how we prevent the same situation
for Squeeze. Webkit has a lot more rdeps there. I'm adding
debian-release to the CC list.
The following packages contain webkit or have a webkit heritage:
chromium: That's a leaf package and Guiseppe will be updating it
with point releases and backport later on (like Xulrunner). No
problems here. Except maybe that it needs a co-maintainer.
kdelibs/kdelibs4: Only few webkit issues also affect khtml, since the
code bases have forked away from each other quite some time ago and
webkit has seen lots of changes and rewrites.
My proposal: We'll fix everything for which a KDE advisory is issued,
but won't be able to investigate each webkit issue whether it affects
khtml. khtml upstream doesn't do so either. We should document this in
README.Debian. The KDE 3 version already has a README file stating
that security support is very limited.
qt4: It embeds a webkit copy, but does any application in the archive
use it? It seems as if Nokia doesn't systematically track security
issues either. If the webkit version embedded is the same as the
webkit version in Debian it might be straightforward to carry the
patches over. The alternative: Mark QT4 as unsupported security-wise.
Webkit: Patches need to be backported, but we need more maintainers
involved and commited to backporting patches. A few people need to
step up and commit to it, otherwise it's bound to fail for Squeeze
as it failed for Lenny.
Cheers,
Moritz
Reply to: