On Mon, 28 Dec 2015 14:24:29 -0600
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
Hi,
This mail is in regards to
WSA-2015-0002: http://webkitgtk.org/security /WSA-2015-0002.html
In short, we have by my count:
* Zero CVEs affecting the webkitgtk4 package in F23
* 40 CVEs affecting the webkitgtk4 package in F22
* 129 CVEs affecting the webkitgtk and webkitgtk3 packages in F22/F23
The vast majority of these issues allow for "remote attackers to
execute arbitrary code or cause a denial of service (memory corruption
and application crash) via a crafted web site."
My proposal is to update webkitgtk4 in F22 from 2.8.5 to 2.10.4 and
hope that not much breaks. This is probably relatively safe, since
2.10.4 has been in F23 for a while, I'm not aware of any issues
related to the upgrade, and it's API/ABI compatible. 2.8 -> 2.10 is a
major upgrade encompassing six months of development on WebKit trunk
(from February to August 2015). This means there will inevitably be
regressions. Normally I don't advocate large version updates for
stable Fedora releases, but web engines are special in that it's the
only practical way to provide security support. We can't backport 40
patches to F22, so if we don't do this update, we should instead
announce that security support for webkitgtk4 is provided only to the
latest Fedora release.
Certainly it's not practical to provide security support for the
webkitgtk or webkitgtk3 packages going forward. We can either remove
them from the distro at some flag date (F25 branch point?), or ignore
the problem like we do for qtwebkit. Probably the later is a better
approach, since there is a lot that still depends on these packages.
A deadline might help motivate some upstream projects to move to
webkitgtk4 I suppose. I'm not sure we can say the f25 branch point,
because we don't really yet know what that date exactly is. ;(
Perhaps we pick some date after the planned f24 release, like say
2016-06-30 so we have an exact date to communicate to upstreams?
That would give them around 6 months.
Of course there are some pretty important packages in the list, so not
sure if we really want to remove them if they don't port. I guess it
might depend on how receptive those upstreams are to moving...
kevin