Samstag, 24. Juni 2017

Improving QtWebKit security for Fedora

The Qt port of the WebKit engine was unmaintained for years, until Konstantin Tokarev (also known as annulen) decided to pick it up in December 2015. Within the last months he did an impressive job on getting QtWebKit up to date again, some days ago he released the second alpha of QtWebKit 5.212.0. As the current state of QtWebkit is really bad in Fedora, we always shipped the latest one from Qt upstream, but they did not do any backports of security fixes from upstream WebKit anymore, the KDE SIG now decided to move to the new community QtWebKit. Qt itself only supports the QtWebEngine based on Chromium, which itself has some issues (hard to maintain as we have to remove codec stuff, always some Chromium releases behind) , but more important: Many applications have not been ported and still use QtWebKit. With Konstantins work on QtWebKit it is possible to use them without all these unfixed security issues again. There are also some reasons to use QtWebKit instead of QtWebEngine, checkout the QtWebKit Wiki.

Within the last two weeks I worked on packaging the new QtWebKit and testing it with several browsers and KDE components to ensure that we do not break the world. So far it looks like new QtWebKit is what it is promised to be: a drop-in replacement for the old one, even without the need to recompile anything. For now our plan to get it in Fedora:

  • Provide a copr for wider testing, already done, checkout https://copr.fedorainfracloud.org/coprs/lupinix/qtwebkit-annulen/
  • Import into Rawhide (done)
  • Update all qt5-qtwebkit packages for Fedora 24+ when some more testing is done, current plan is a 0day update for Fedora 26 (we will not get it in before final freeze) and updates for Fedora 24 and 25 at the same time
Note that I'm talking about the Qt5 version of QtWebKit. There is no upstream support for Qt4 anymore, but it is still in Fedoras repositories. So Qt4 QtWebKit is still without any fixes, I guess we should retire it at some point, in the same way our WebKitGTK+ friends already did.

Donnerstag, 19. Januar 2017

LXQt Spin proposed for Fedora 26, new test build available

Around christmas we announced some initial effort for a Fedora LXQt remix/spin. After some weeks of testing and tuning, reworking translation packages and updating whole LXQt to 0.11.x (x>0) the LXQt SIG decided to propose the LXQt Spin for inclusion in Fedora 26.

The current selection of applications:

  • LXQt 0.11.x
  • PCManFM-Qt (LXQt file manager)
  • Ark (archiver, from KDE)
  • Dragon (media player, from KDE)
  • KCalc (calculator, from KDE)
  • KWrite (text editor, from KDE)
  • LXImage-Qt (image viewer)
  • Psi+ (XMPP client)
  • qBittorrent (torrent client)
  • Qlipper (clipboard tool)
  • qpdfview (pdf and ps viewer)
  • Quassel (IRC client)
  • QupZilla (web browser)
  • Trojita (IMAP mail client)
  • Yarock (music player)
The set of applications is not yet fixed, we've chosen some KDE applications as they are Qt5 based and integrate well while having a small dependency footprint. In cases where LXQt provides an application (e.g. LXImage-Qt image viewer), this one has been selected.

For configuration we included the LXQt config tools (lxqt-config and obconf-qt) of course, in addition we added lxappearance to be able to change GTK themes too. The theme itself is the Breeze theme known from KDE, it looks nice and is provided for GTK in addition, so the user can have a unified look. By default we've chosen the Openbox window manager, in addition the spin will contain KWin for those who like to have compositing etc.

For software management we included dnfdragora, a nice graphical frontend for DNF providing a nice Qt based GUI in our case (but as it uses libyui abstraction layer, it can use GTK and curses too, as known from SUSE YaST). This is not yet included in Fedora, but on a good way to arrive soon. Right now Kevin Kofler provides a COPR for it.

A new test build is available in the usual location, comments and ideas (like different applications which may fit better) should be shared in our project on pagure.