Hi,
This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1].
Note: to count the vulnerabilities, I just manually added up the CVEs listed at [2], ignoring the oldest advisory WSA-2015-0001, and discounting five of the older vulnerabilities in WSA-2015-0002.
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1375784 [2] https://webkitgtk.org/security.html
Michael Catanzaro wrote:
This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide.
There are still several high-profile applications depending on those libraries, including Gnucash. I don't see how it is practical at all to remove those libraries at this time.
Kevin Kofler
On Mon, 2017-01-23 at 07:35 -0600, Michael Catanzaro wrote:
Hi,
This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1].
Hi,
This is now complete in rawhide. The packages have *not* been retired from F26, so if this broke your package you have the rest of the F27 development cycle to decide how to handle it. The best option is to port to the modern webkitgtk4 package, but alternatively you could try bundling older WebKit with your package.
Michael
Looks like this was done without involving FESCo and without going through a proper Change process. I don't think it's a proper way to approach it like this as it breaks a large part of the distro.
I would like to unretire webkitgtk3 as removing it breaks one of my packages (bijiben). My intention is to keep maintaining the webkitgtk3 package until bijiben gets ported to something else.
I took ownership in pkgdb, but it appears to be still blocked in koji. Does anyone know how I can get it unblocked?
Pete
14.03.2017, 19:29, "Michael Catanzaro" mcatanzaro@gnome.org:
On Mon, 2017-01-23 at 07:35 -0600, Michael Catanzaro wrote:
Hi,
This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1].
Hi,
This is now complete in rawhide. The packages have *not* been retired from F26, so if this broke your package you have the rest of the F27 development cycle to decide how to handle it. The best option is to port to the modern webkitgtk4 package, but alternatively you could try bundling older WebKit with your package.
Michael _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Mar 22, 2017 at 11:28 AM, Pete Walter walter.pete@yandex.com wrote:
Looks like this was done without involving FESCo and without going through a proper Change process. I don't think it's a proper way to approach it like this as it breaks a large part of the distro.
I would like to unretire webkitgtk3 as removing it breaks one of my packages (bijiben). My intention is to keep maintaining the webkitgtk3 package until bijiben gets ported to something else.
I took ownership in pkgdb, but it appears to be still blocked in koji. Does anyone know how I can get it unblocked?
You can file the unblock request in releng: https://pagure.io/releng
On Wed, 2017-03-22 at 18:28 +0300, Pete Walter wrote:
I would like to unretire webkitgtk3 as removing it breaks one of my packages (bijiben). My intention is to keep maintaining the webkitgtk3 package until bijiben gets ported to something else.
I recommend publishing a git snapshot of bijiben for now, or applying one of the patches from upstream:
https://git.gnome.org/browse/bijiben/log/?h=wip/igaldino/webkit2-port
Of course it would be advisable to check with upstream regarding the state of that port first, but there's plenty of time between now and the Fedora 27 release in November to get problems ironed out.
On Wed, 2017-03-22 at 18:28 +0300, Pete Walter wrote:
I took ownership in pkgdb, but it appears to be still blocked in koji. Does anyone know how I can get it unblocked?
You have to make a request to releng, as Neal says. I hope that releng will not approve such a request without a decision on the matter from FESCo, since this would entail reintroducing a security-critical package to the distribution that is affected by over 200 known vulnerabilities.
Michael
On 03/22/2017 09:40 AM, Michael Catanzaro wrote:
You have to make a request to releng, as Neal says. I hope that releng will not approve such a request without a decision on the matter from FESCo, since this would entail reintroducing a security-critical package to the distribution that is affected by over 200 known vulnerabilities.
I could have sworn FESCo discussed and approved this plan, but I cannot seem to find it. I guess it might have been discussed, but didn't have a ticket. If needed we could discuss it at the next meeting.
I'm not sure a change makes sense, but we could definitely make sure documentation mentions the removals.
Everyone has had years here, so this shouldn't really be a surprise. I also really don't want these packages and their hundreds of vulnerabilities coming back into the collection.
kevin
On Wed, 2017-03-22 at 09:48 -0600, Kevin Fenzi wrote:
I could have sworn FESCo discussed and approved this plan, but I cannot seem to find it. I guess it might have been discussed, but didn't have a ticket. If needed we could discuss it at the next meeting.
I never created a ticket, and I'm not personally aware of any FESCo discussion, so Pete is not incorrect to say "Looks like this was done without involving FESCo and without going through a proper Change process."
Michael
On Mon, 2017-01-23 at 07:35 -0600, Michael Catanzaro wrote:
Hi,
This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1].
Note: to count the vulnerabilities, I just manually added up the CVEs listed at [2], ignoring the oldest advisory WSA-2015-0001, and discounting five of the older vulnerabilities in WSA-2015-0002.
It seems that nothing has been set to obsolete these packages. This is breaking upgrade from Fedora 24 to Fedora 27 (without --allow-erasing), since webkitgtk3 is installed by default in many Fedora 24 package sets, and is built against a libicu version that is no longer in Rawhide:
https://openqa.fedoraproject.org/tests/82613#step/upgrade_run/9
Can someone please do something about this? Thanks.
On Tue, 2017-04-18 at 18:03 -0700, Adam Williamson wrote:
It seems that nothing has been set to obsolete these packages. This is breaking upgrade from Fedora 24 to Fedora 27 (without --allow- erasing), since webkitgtk3 is installed by default in many Fedora 24 package sets, and is built against a libicu version that is no longer in Rawhide:
https://openqa.fedoraproject.org/tests/82613#step/upgrade_run/9
Can someone please do something about this? Thanks.
What do you think "something" should be? It was removed without any replacement. I think passing --allow-erasing is just what you're going to have to do in order to perform an upgrade that requires erasing packages, right?
GNOME Software should already handle this nicely, informing users of which applications will be erased, so at least it won't be a problem for Workstation.
Michael
On Tue, 2017-04-18 at 21:01 -0500, Michael Catanzaro wrote:
On Tue, 2017-04-18 at 18:03 -0700, Adam Williamson wrote:
It seems that nothing has been set to obsolete these packages. This is breaking upgrade from Fedora 24 to Fedora 27 (without --allow- erasing), since webkitgtk3 is installed by default in many Fedora 24 package sets, and is built against a libicu version that is no longer in Rawhide:
https://openqa.fedoraproject.org/tests/82613#step/upgrade_run/9
Can someone please do something about this? Thanks.
What do you think "something" should be?
fedora-obsolete-packages.
https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Exi...
"If a retired package needs to be removed from end user machines because it causes dependency issues which interfere with upgrades or is otherwise harmful, a packager MAY request that an Obsoletes: be added to fedora-obsolete-packages. Simply file a bugzilla ticket here, including information on which package needs to be obsoleted and the reasons why it cannot be allowed to remain installed."
On Tue, 2017-04-18 at 19:20 -0700, Adam Williamson wrote:
fedora-obsolete-packages.
https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplac ing_Existing_Packages
OK, I filed this request:
https://bugzilla.redhat.com/show_bug.cgi?id=1443614
Michael
It does not seems to be properly retired in pkgdb [1], although it seem to be retired in dist-git [2].
BTW what is the state of Empathy which is broken by this retirement :(
Vít
[1] https://admin.fedoraproject.org/pkgdb/package/rpms/webkitgtk3/
[2] http://pkgs.fedoraproject.org/cgit/rpms/webkitgtk3.git/commit/?id=6f85a399bf...
Dne 23.1.2017 v 14:35 Michael Catanzaro napsal(a):
Hi,
This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1].
Note: to count the vulnerabilities, I just manually added up the CVEs listed at [2], ignoring the oldest advisory WSA-2015-0001, and discounting five of the older vulnerabilities in WSA-2015-0002.
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1375784 [2] https://webkitgtk.org/security.html _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Fri, Jul 7, 2017 at 8:08 AM, Vít Ondruch vondruch@redhat.com wrote:
It does not seems to be properly retired in pkgdb [1], although it seem to be retired in dist-git [2].
BTW what is the state of Empathy which is broken by this retirement :(
Upstream master is ported to WK2, but there are bugs that need fixed (fallout from switch to single-window UI) before it can be released. So no Empathy until I find time to fix them or someone else decides to help. The goal is just to start Empathy with no critical warnings. I will cut a release once we reach that point. It should not be too hard to get to, I think, just needs a bit of time.
Remember, it's no longer maintained upstream for many years now, so if we want to keep Empathy in Fedora we have to fix it ourselves!
Michael
On Fri, 2017-07-07 at 11:34 -0500, Michael Catanzaro wrote:
On Fri, Jul 7, 2017 at 8:08 AM, Vít Ondruch vondruch@redhat.com wrote:
It does not seems to be properly retired in pkgdb [1], although it seem to be retired in dist-git [2].
BTW what is the state of Empathy which is broken by this retirement :(
Upstream master is ported to WK2, but there are bugs that need fixed (fallout from switch to single-window UI) before it can be released. So no Empathy until I find time to fix them or someone else decides to help. The goal is just to start Empathy with no critical warnings. I will cut a release once we reach that point. It should not be too hard to get to, I think, just needs a bit of time.
Remember, it's no longer maintained upstream for many years now, so if we want to keep Empathy in Fedora we have to fix it ourselves!
Another victim is geany Markdown plugin, each I need to work on my md documentation .
Please remember me what is the difference of webkitgtk, webkitgtk3 and webkitgtk4 ?
Michael _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, Nov 20, 2017 at 5:59 AM, Sérgio Basto sergio@serjux.com wrote:
Please remember me what is the difference of webkitgtk, webkitgtk3 and webkitgtk4 ?
The package names are very confusing, sorry.
webkitgtk: This package is WebKitGTK+ 2.4 built with the original WebKitGTK+ API, for use by GTK+ 2 applications. If you really, really want to use it in your package, you can bundle it, but this is discouraged since security updates ended in 2014.
webkitgtk3: This package is WebKitGTK+ 2.4 built with the original WebKitGTK+ API, for use by GTK+ 3 applications. Ditto.
webkitgtk4: This package is the modern version of WebKitGTK+ (currently 2.18.3). It's the only version that you should be using. It exposes a newer multiprocess API. The "4" in the package name is related to the API version, but this was a mistake IMO.
To save the Markdown plugin, you'd need to rewrite all of Geany with GTK+ 3, first using the webkitgtk3 package. Then you can switch to webkitgtk4 as the next step. It's not possible to mix GTK+ 2 and GTK+ 3 in the same process, so switching to GTK+ 3 is the only way you can continue using WebKitGTK+ without bundling the old version. A better alternative might be to stop using WebKitGTK+ altogether if it's not absolutely required. (I don't know, but perhaps you could use pango, for instance.) Alternatively: possibly you could try to run the markdown plugin in a separate process from the rest of Geany?
Note: even if you rewrite Geany with GTK+ 3, it's only a matter of time (guess: five years or so) before we drop GTK+ 3 support. So you have to be prepared to move on to GTK+ 4 sooner or later. If you're not OK with this then you should not be using WebKitGTK+ at all.
Hope that helps,
Michael
On Mon, 2017-11-20 at 09:03 -0600, Michael Catanzaro wrote:
webkitgtk4: This package is the modern version of WebKitGTK+ (currently 2.18.3). It's the only version that you should be using. It exposes a newer multiprocess API. The "4" in the package name is related to the API version, but this was a mistake IMO.
To save the Markdown plugin, you'd need to rewrite all of Geany with GTK+ 3, first using the webkitgtk3 package. Then you can switch to webkitgtk4 as the next step. It's not possible to mix GTK+ 2 and GTK+ 3 in the same process, so switching to GTK+ 3 is the only way you can continue using WebKitGTK+ without bundling the old version. A better alternative might be to stop using WebKitGTK+ altogether if it's not absolutely required. (I don't know, but perhaps you could use pango, for instance.) Alternatively: possibly you could try to run the markdown plugin in a separate process from the rest of Geany?
Note: even if you rewrite Geany with GTK+ 3, it's only a matter of time (guess: five years or so) before we drop GTK+ 3 support. So you have to be prepared to move on to GTK+ 4 sooner or later. If you're not OK with this then you should not be using WebKitGTK+ at all.
hum Markdown plugin is build with GTK3 , the plus of GTK+ is confusing me
Hope that helps,
It helps thanks,
Michael
On Thu, 2017-12-07 at 00:04 +0000, Sérgio Basto wrote:
hum Markdown plugin is build with GTK3 , the plus of GTK+ is confusing me
GTK+ is the correct name of the project and the product. It is not called GTK. "GTK+ 3" and "GTK 3" refer to the same thing, and "GTK+ 3" is technically the correct name. (It was called GTK a long, long, long time ago and the + was added to indicate an OO rewrite, but that's ancient history).
On Wed, 2017-12-06 at 16:19 -0800, Adam Williamson wrote:
On Thu, 2017-12-07 at 00:04 +0000, Sérgio Basto wrote:
hum Markdown plugin is build with GTK3 , the plus of GTK+ is confusing me
GTK+ is the correct name of the project and the product. It is not called GTK. "GTK+ 3" and "GTK 3" refer to the same thing, and "GTK+ 3" is technically the correct name. (It was called GTK a long, long, long time ago and the + was added to indicate an OO rewrite, but that's ancient history).
Thanks, I already can build geany-plugin-markdown with webkitgtk3-devel .
On Thu, 2017-12-07 at 23:26 +0000, Sérgio Basto wrote:
On Wed, 2017-12-06 at 16:19 -0800, Adam Williamson wrote:
On Thu, 2017-12-07 at 00:04 +0000, Sérgio Basto wrote:
hum Markdown plugin is build with GTK3 , the plus of GTK+ is confusing me
GTK+ is the correct name of the project and the product. It is not called GTK. "GTK+ 3" and "GTK 3" refer to the same thing, and "GTK+ 3" is technically the correct name. (It was called GTK a long, long, long time ago and the + was added to indicate an OO rewrite, but that's ancient history).
Thanks, I already can build geany-plugin-markdown with webkitgtk3- devel
It is working with webkitgtk4 :) [1]
[1] https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Rele ases/build/685925/
Thank you Michael , btw about package naming IMHO webkitgtk4 should be called webkit2gtk3 and for gtk4 webkit2gtk4
On Fri, Dec 8, 2017 at 10:16 PM, Sérgio Basto sergio@serjux.com wrote:
On Thu, 2017-12-07 at 23:26 +0000, Sérgio Basto wrote:
On Wed, 2017-12-06 at 16:19 -0800, Adam Williamson wrote:
On Thu, 2017-12-07 at 00:04 +0000, Sérgio Basto wrote:
hum Markdown plugin is build with GTK3 , the plus of GTK+ is confusing me
GTK+ is the correct name of the project and the product. It is not called GTK. "GTK+ 3" and "GTK 3" refer to the same thing, and "GTK+ 3" is technically the correct name. (It was called GTK a long, long, long time ago and the + was added to indicate an OO rewrite, but that's ancient history).
Thanks, I already can build geany-plugin-markdown with webkitgtk3- devel
It is working with webkitgtk4 :) [1]
[1] https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Rele ases/build/685925/
Thank you Michael , btw about package naming IMHO webkitgtk4 should be called webkit2gtk3 and for gtk4 webkit2gtk4
The webkitgtk4-devel package already provides pkgconfig(webkit2gtk-4.0).
The GNOME system for naming pkg-config files is <name>-<major-ver-series>, so it's clearer with the pkgconfig name than the package name.
The naming of the packages was especially dumb in Fedora. It might make sense to add some Provides that add sensible names, too.
Hi,
On Sat, Dec 9, 2017 at 5:06 PM, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 8, 2017 at 10:16 PM, Sérgio Basto sergio@serjux.com wrote:
Thank you Michael , btw about package naming IMHO webkitgtk4 should be called webkit2gtk3 and for gtk4 webkit2gtk4
The webkitgtk4-devel package already provides pkgconfig(webkit2gtk-4.0).
The GNOME system for naming pkg-config files is <name>-<major-ver-series>, so it's clearer with the pkgconfig name than the package name.
The naming of the packages was especially dumb in Fedora. It might make sense to add some Provides that add sensible names, too.
The right name from upstream's POV (I talked to them when adding the package to Fedora - and I was considering webkit2gtk3 as well) is webkitgtk4 as the 4 on the ends means API version and it's not connected to GTK+ version.
But during the last Web Engines Hackfest Michael was keen on renaming the package to webkit2gtk3 (so we are ready for GTK+ 4 based WebKit).
Tom
On Wed, 2017-12-13 at 07:00 +0100, Tomas Popela wrote:
Hi,
On Sat, Dec 9, 2017 at 5:06 PM, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 8, 2017 at 10:16 PM, Sérgio Basto sergio@serjux.com wrote:
Thank you Michael , btw about package naming IMHO webkitgtk4
should be
called webkit2gtk3 and for gtk4 webkit2gtk4
The webkitgtk4-devel package already provides pkgconfig(webkit2gtk- 4.0).
The GNOME system for naming pkg-config files is
<name>-<major-ver-series>, so it's clearer with the pkgconfig name
than the package name.
The naming of the packages was especially dumb in Fedora. It might
make sense to add some Provides that add sensible names, too.
The right name from upstream's POV (I talked to them when adding the package to Fedora - and I was considering webkit2gtk3 as well) is webkitgtk4 as the 4 on the ends means API version and it's not connected to GTK+ version.
But during the last Web Engines Hackfest Michael was keen on renaming the package to webkit2gtk3 (so we are ready for GTK+ 4 based WebKit).
BTW , I checked debian package and they build webkit2gtk3 and webkit2gtk2 [1] and also his naming looks better ;) (webkit2gtk-4.0) .So I would suggest webkit2gtk3-4.0 , webkit2gtk2-4.0 and webkit2gtk4- 4.0 [1]https://tracker.debian.org/pkg/webkit2gtk
Tom
On Wed, Dec 13, 2017 at 11:54 AM, Sérgio Basto sergio@serjux.com wrote:
BTW , I checked debian package and they build webkit2gtk3 and webkit2gtk2 [1] and also his naming looks better ;) (webkit2gtk-4.0) . So I would suggest webkit2gtk3-4.0 , webkit2gtk2-4.0 and webkit2gtk4-4.0
Just a note - there is nothing like "webkit2gtk2-4.0" or "webkit2gtk2" because WebKit2 is only for GTK+ 3. As I said I checked the naming with upstream. If we want to change the name then we should probably want to do it ASAP.
On Wed, 2017-12-13 at 12:58 +0100, Tomas Popela wrote:
On Wed, Dec 13, 2017 at 11:54 AM, Sérgio Basto sergio@serjux.com wrote:
BTW , I checked debian package and they build webkit2gtk3 and webkit2gtk2 [1] and also his naming looks better ;) (webkit2gtk- 4.0) . So I would suggest webkit2gtk3-4.0 , webkit2gtk2-4.0 and webkit2gtk4-4.0
Just a note - there is nothing like "webkit2gtk2-4.0" or "webkit2gtk2" because WebKit2 is only for GTK+ 3. As I said I checked the naming with upstream. If we want to change the name then we should probably want to do it ASAP.
Hum my point was that Debian have https://packages.debian.org/unstable/libwebkit2gtk-4.0-37-gtk2
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Dec 13, 2017 at 1:17 PM, Sérgio Basto sergio@serjux.com wrote:
On Wed, 2017-12-13 at 12:58 +0100, Tomas Popela wrote:
On Wed, Dec 13, 2017 at 11:54 AM, Sérgio Basto sergio@serjux.com wrote:
BTW , I checked debian package and they build webkit2gtk3 and webkit2gtk2 [1] and also his naming looks better ;) (webkit2gtk- 4.0) . So I would suggest webkit2gtk3-4.0 , webkit2gtk2-4.0 and webkit2gtk4-4.0
Just a note - there is nothing like "webkit2gtk2-4.0" or "webkit2gtk2" because WebKit2 is only for GTK+ 3. As I said I checked the naming with upstream. If we want to change the name then we should probably want to do it ASAP.
Hum my point was that Debian have https://packages.debian.org/unstable/libwebkit2gtk-4.0-37-gtk2
Which is completely confusing - that's only a plugin process for GTK+ 2 based NPAPI plugins (like Flash)..
On Wed, 2017-12-13 at 13:31 +0100, Tomas Popela wrote:
On Wed, Dec 13, 2017 at 1:17 PM, Sérgio Basto sergio@serjux.com wrote:
On Wed, 2017-12-13 at 12:58 +0100, Tomas Popela wrote:
On Wed, Dec 13, 2017 at 11:54 AM, Sérgio Basto <sergio@serjux.com
wrote:
BTW , I checked debian package and they build webkit2gtk3 and webkit2gtk2 [1] and also his naming looks better ;)
(webkit2gtk-
4.0) . So I would suggest webkit2gtk3-4.0 , webkit2gtk2-4.0 and webkit2gtk4-4.0
Just a note - there is nothing like "webkit2gtk2-4.0" or "webkit2gtk2" because WebKit2 is only for GTK+ 3. As I said I
checked
the naming with upstream. If we want to change the name then we should probably want to do it ASAP.
Hum my point was that Debian have https://packages.debian.org/unstable/libwebkit2gtk-4.0-37-gtk2
Which is completely confusing - that's only a plugin process for GTK+ 2 based NPAPI plugins (like Flash)..
Ah ok , sorry my confusing. Another BTW :) we need help to migrate webhelper of geany-plugins [1] ...
[1] https://github.com/geany/geany-plugins/pull/656
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Kevin Fenzi -
Kevin Kofler -
Michael Catanzaro -
Michael Catanzaro -
Neal Gompa -
Pete Walter -
Sérgio Basto -
Tomas Popela -
Vít Ondruch