Hacker News Reader

Comment by apecat | Hacker News Reader

I looked up the obvious stuff: process isolation and sandboxing, fully expecting not to find any good info on that or security support/lifecycle. Instead, this actually seems pretty interesting. https://qutebrowser.org/doc/faq.html

"Most security issues are in the backend (which handles networking, rendering, JavaScript, etc.) and not qutebrowser itself.

qutebrowser uses QtWebEngine by default. QtWebEngine is based on Google’s Chromium. While Qt only updates to a new Chromium release on every minor Qt release (all ~6 months), every patch release backports security fixes from newer Chromium versions. In other words: As long as you’re using an up-to-date Qt, you should be receiving security updates on a regular basis, without qutebrowser having to do anything. Chromium’s process isolation and sandboxing features are also enabled as a second line of defense."

View on HN

In Debian, libqt5webengine5 is security-support-limited:

> qtwebengine-opensource-src No security support upstream and backports not feasible, only for use on trusted content

The fact that Firefox and Chromium are kept up-to-date with security patches represents a carve-out from the normal Debian security process (ability to build without fully packaging the dependencies).

This may also be partly related to Qt's security backports only existing on commercial LTS branches and not the public LGPL branches.

> This may also be partly related to Qt's security backports only existing on commercial LTS branches and not the public LGPL branches.

The 5.15 LTS branch for QtWebEngine is still public: https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15.3 https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15

The 5.12 LTS (supported until the end of the year) also is public, for all of Qt.

Debian/Ubuntu just don't seem to care enough about security issues in QtWebEngine to keep it updated (it can be combined with an older version of Qt itself, so that wouldn't be an issue, at least in theory).

I didn't look too closely at the code, but have written a toy browser in just this way.

The problem is that QT on targets rarely gets updated, at least not as fast as Chromium.

I had the misfortune of targeting old RHEL systems, whose QT was missing a lot of what I needed.

So then you get into the game of compiling QT yourself, and in my case having to compile python as well, etc. It turns into a real mess.

I imagine modern desktop systems are a bit better today, but am curious how the author solves that(if at all).

Something like Docker existing at the time probably would have been a huge help.

Reply on news.ycombinator.com