recoll is currently uninstallable on any open ISA (libre firmware) platform due to being built with QtWebEngine support turned on. This impacts ppc64el, see Bug #1101034, and generally runs against Debian's general philosophy of self sovereignty / owner control by effectively requiring the use of closed software (Intel ME / AMD PSP) to use the recoll application. As the recoll application is perfectly usable without QtWebEngine, and in fact was both installable and working in previous Debian versions on ppc64el, I consider this a serious regression. Editing debian/rules to change -Dwebengine=true to -Dwebengine=false is enough to get a working build on ppc64el. Please release a version of recoll that has this change with ppc64el builds enabled. Thank you!
Please ignore the spurious patch file, I used a template Email and hit Send too soon. Interestingly, even the Web preview works great on recoll on ppc64el with QtWebEngine disabled. I'm honestly not sure why it's turned on at all, as the only visible purpose it has is to ensure that closed software is required to use the recoll application.----- Original Message -----
Recoll uses an HTML engine for displaying the result list and the preview window. There are three possible engines: - QTextBrowser, which is the Qt native HTML engine - Qt Webkit - Qt Webengine (chromium-based) Of the 3, Qt Webkit was by far the best for our usage, with a much better API. Qt decided that they needed to switch to using the chromium version, probably because of better Web "standards" support, mostly for people who actually use it for implementing a Web browser. Qt Webkit was externally maintained for Qt5. As far as I know, there is no Qt6 implementation, so there is no way ahead for it. QTextBrowser has only incomplete support for CSS styling (and no Javascript which is an issue for some result list customisations). Attaching a preview of the wikipedia front page with QTextBrowser (on the left), and QWebengine (right) for illustration. For the moment, it is still possible to build with qt5 and libqt5webkit5, which is probably the best current solution, but it has no future. Is it possible at all to use different rules for different architectures ? Disabling the "real" HTML engines only for architectures platforms which don't support them would probably be the best approach going forward. jf
Understood, thank you for the explanation. That helps, and also brings up another question. On the debian/rules architecture selection, yes, this is supported. Something similar to: ifeq (ppc64el,$(DEB_HOST_ARCH)) # cmake without webengine else # cmake with webengine endif should work. However, the explanation of the renderers does bring up a privacy / security question. I would personally consider the lack of Javascript support a plus, in that it stops pingback or similar tracing / monitoring to third party servers. Loading up an entire Chromium instance without being able to turn off external access, disable Javascript execution, etc. seems like a major security and privacy risk. As an example of how I would expect to see this handled, VLC pops up a warning indicating that third party services will be able to see what media you are playing when you turn on metadata lookup -- it seems that if we're going to use QWebEngine for rendering, a similar popup should be displayed somewhere indicating that we're loading and executing the Web pages including all of the tracking and monitoring pingbacks. I bring up the privacy issues because I would be tempted to disable QWebEngine across all architectures on those grounds alone, but it's not my call. Building without QWebEngine on ppc64el would be enough to close this bug. Thanks!----- Original Message -----
Several things: - As the documents loaded by the preview are loaded from local files, I don't think that the Javascript is allowed to fetch from the network. I am no javascript or browser expert though. - In order to prevent webkit or webengine (or anything inside the app actually) from making network requests, recoll sets up the Qt app with a bogus proxy (socks5 proxy on localhost with username recoll and no password). This is a bit of a hack but I think that it should work in case something does try to reach out. - I just saw that there is an additional layer which could be set in the code calling Qt Webengine, for intercepting all network requests. I'm going to have a look at adding this as an additional protection layer. Because recoll is by nature processing a lot of user data, I try to make sure that it initiates no external network traffic at all. I've not ever had any report to the contrary, but I'm quite ready to fix issues in this area. Timothy Pearson writes: > Understood, thank you for the explanation. That helps, and also brings up another question. > > On the debian/rules architecture selection, yes, this is supported. Something similar to: > > ifeq (ppc64el,$(DEB_HOST_ARCH)) > # cmake without webengine > else > # cmake with webengine > endif > > should work. > > However, the explanation of the renderers does bring up a privacy / security question. I would personally consider the lack of Javascript support a plus, in that it stops pingback or similar tracing / monitoring to third party servers. Loading up an entire Chromium instance without being able to turn off external access, disable Javascript execution, etc. seems like a major security and privacy risk. As an example of how I would expect to see this handled, VLC pops up a warning indicating that third party services will be able to see what media you are playing when you turn on metadata lookup -- it seems that if we're going to use QWebEngine for rendering, a similar popup should be displayed somewhere indicating that we're loading and executing the Web pages including all of the tracking and monitoring pingbacks. > > I bring up the privacy issues because I would be tempted to disable QWebEngine across all architectures on those grounds alone, but it's not my call. Building without QWebEngine on ppc64el would be enough to close this bug. > > Thanks! > > ----- Original Message ----- > > From: "Jean-Francois Dockes" <jf@dockes.org> > > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "1111324" <1111324@bugs.debian.org> > > Sent: Sunday, August 17, 2025 3:22:09 AM > > Subject: Re: Bug#1111324: Acknowledgement ([regression] recollgui uninstallable on ppc64el) > > > Recoll uses an HTML engine for displaying the result list and the preview > > window. > > > > There are three possible engines: > > - QTextBrowser, which is the Qt native HTML engine > > - Qt Webkit > > - Qt Webengine (chromium-based) > > > > Of the 3, Qt Webkit was by far the best for our usage, with a much better API. > > > > Qt decided that they needed to switch to using the chromium version, probably > > because of > > better Web "standards" support, mostly for people who actually use it for > > implementing a > > Web browser. > > > > Qt Webkit was externally maintained for Qt5. As far as I know, there is no Qt6 > > implementation, so there is no way ahead for it. > > > > QTextBrowser has only incomplete support for CSS styling (and no Javascript > > which is an > > issue for some result list customisations). Attaching a preview of the wikipedia > > front > > page with QTextBrowser (on the left), and QWebengine (right) for illustration. > > > > For the moment, it is still possible to build with qt5 and libqt5webkit5, which > > is > > probably the best current solution, but it has no future. > > > > Is it possible at all to use different rules for different architectures ? > > Disabling the > > "real" HTML engines only for architectures platforms which don't support them > > would > > probably be the best approach going forward. > > > > jf > > > > > > > > > > [image/png:recoll-wikipedia-preview.png]
That's great to hear, thank you for the explanation and for considering user privacy in the application design. Chromium makes me nervous from a privacy and security standpoint, I am actually the ppc64el maintainer for the Chromium codebase -- it's a complex beast that tries nearly every way imaginable by default to phone home back to Google, which is why I wasn't too happy to see it show up in recoll. :) I haven't caught recoll making any unauthorized network requests, but then again I haven't used the new QWebEngine version because I don't use amd64 machines in any significant capacity (the newest one I have is from 2013, when you could still run libre firmware on the mainboards). It would definitely be interesting to see if QWebEngine is able to initiate network requests somehow.----- Original Message -----
I checked again, and as far as I can see, JS is blocked from making external requests by the cross origin policy. Image fetches were blocked by the bogus proxy, but I'm not quite sure that this is 100% so I added another layer (a QWebEngineUrlRequestInterceptor) to block anything but the initial page load. I don't think that the webengine preview poses a security or privacy risk in the current version, and even less on the next one. The qt5+webkit configuration is probably even better but it probably has no way forward. So I think that a default of building with webengine with an exception for platforms which don't support it is the best approach. Timothy Pearson writes: > That's great to hear, thank you for the explanation and for considering user privacy in the application design. Chromium makes me nervous from a privacy and security standpoint, I am actually the ppc64el maintainer for the Chromium codebase -- it's a complex beast that tries nearly every way imaginable by default to phone home back to Google, which is why I wasn't too happy to see it show up in recoll. :) > > I haven't caught recoll making any unauthorized network requests, but then again I haven't used the new QWebEngine version because I don't use amd64 machines in any significant capacity (the newest one I have is from 2013, when you could still run libre firmware on the mainboards). It would definitely be interesting to see if QWebEngine is able to initiate network requests somehow. > > ----- Original Message ----- > > From: "Jean-Francois Dockes" <jf@dockes.org> > > To: "Timothy Pearson" <tpearson@raptorengineering.com> > > Cc: "1111324" <1111324@bugs.debian.org> > > Sent: Sunday, August 17, 2025 3:39:51 PM > > Subject: Re: Bug#1111324: Acknowledgement ([regression] recollgui uninstallable on ppc64el) > > > Several things: > > - As the documents loaded by the preview are loaded from local files, I > > don't think that the Javascript is allowed to fetch from the network. I > > am no javascript or browser expert though. > > - In order to prevent webkit or webengine (or anything inside the app > > actually) from making network requests, recoll sets up the Qt app with a > > bogus proxy (socks5 proxy on localhost with username recoll and no > > password). This is a bit of a hack but I think that it should work in > > case something does try to reach out. > > - I just saw that there is an additional layer which could be set in the code > > calling Qt Webengine, for intercepting all network requests. I'm going to > > have a look at adding this as an additional protection layer. > > > > Because recoll is by nature processing a lot of user data, I try to make > > sure that it initiates no external network traffic at all. > > > > I've not ever had any report to the contrary, but I'm quite ready to fix > > issues in this area. > > > > > > > > Timothy Pearson writes: > > > Understood, thank you for the explanation. That helps, and also brings up > > > another question. > > > > > > On the debian/rules architecture selection, yes, this is supported. Something > > > similar to: > > > > > > ifeq (ppc64el,$(DEB_HOST_ARCH)) > > > # cmake without webengine > > > else > > > # cmake with webengine > > > endif > > > > > > should work. > > > > > > However, the explanation of the renderers does bring up a privacy / security > > > question. I would personally consider the lack of Javascript support a plus, > > > in that it stops pingback or similar tracing / monitoring to third party > > > servers. Loading up an entire Chromium instance without being able to turn off > > > external access, disable Javascript execution, etc. seems like a major security > > > and privacy risk. As an example of how I would expect to see this handled, VLC > > > pops up a warning indicating that third party services will be able to see what > > > media you are playing when you turn on metadata lookup -- it seems that if > > > we're going to use QWebEngine for rendering, a similar popup should be > > > displayed somewhere indicating that we're loading and executing the Web pages > > > including all of the tracking and monitoring pingbacks. > > > > > > I bring up the privacy issues because I would be tempted to disable QWebEngine > > > across all architectures on those grounds alone, but it's not my call. > > > Building without QWebEngine on ppc64el would be enough to close this bug. > > > > > > Thanks! > > > > > > ----- Original Message ----- > > > > From: "Jean-Francois Dockes" <jf@dockes.org> > > > > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "1111324" > > > > <1111324@bugs.debian.org> > > > > Sent: Sunday, August 17, 2025 3:22:09 AM > > > > Subject: Re: Bug#1111324: Acknowledgement ([regression] recollgui uninstallable > > > > on ppc64el) > > > > > > > Recoll uses an HTML engine for displaying the result list and the preview > > > > window. > > > > > > > > There are three possible engines: > > > > - QTextBrowser, which is the Qt native HTML engine > > > > - Qt Webkit > > > > - Qt Webengine (chromium-based) > > > > > > > > Of the 3, Qt Webkit was by far the best for our usage, with a much better API. > > > > > > > > Qt decided that they needed to switch to using the chromium version, probably > > > > because of > > > > better Web "standards" support, mostly for people who actually use it for > > > > implementing a > > > > Web browser. > > > > > > > > Qt Webkit was externally maintained for Qt5. As far as I know, there is no Qt6 > > > > implementation, so there is no way ahead for it. > > > > > > > > QTextBrowser has only incomplete support for CSS styling (and no Javascript > > > > which is an > > > > issue for some result list customisations). Attaching a preview of the wikipedia > > > > front > > > > page with QTextBrowser (on the left), and QWebengine (right) for illustration. > > > > > > > > For the moment, it is still possible to build with qt5 and libqt5webkit5, which > > > > is > > > > probably the best current solution, but it has no future. > > > > > > > > Is it possible at all to use different rules for different architectures ? > > > > Disabling the > > > > "real" HTML engines only for architectures platforms which don't support them > > > > would > > > > probably be the best approach going forward. > > > > > > > > jf > > > > > > > > > > > > > > > > > > > > [image/png:recoll-wikipedia-preview.png]