Bug#1069574: age-old and insecure webkit package

2024-04-21 Thread Dmitry Shachnev
Hi again Hadmut,

On Sun, Apr 21, 2024 at 08:25:23PM +0300, Hadmut Danisch wrote:
> Hi Dmitry,
>
>
> even their own website
>
> https://wkhtmltopdf.org/status.html
>
> says:
>
>*Do not use wkhtmltopdf with any untrusted HTML* – be sure to
>sanitize any user-supplied HTML/JS, otherwise it can lead to
>complete takeover of the server it is running on! Please consider
>using a Mandatory Access Control system like AppArmor or SELinux,
>see recommended AppArmor policy .
>
> Wouldn't it be more than enough or a reason to throw this out of
> debian/ubuntu, until they fixed this?

First, I am the wrong person to ask about this. I am CCing the wkhtmltopdf
maintainer.

Second, wkhtmltopdf is not a leaf package, there are other packages depending
on it:

  Reverse-Recommends
  ==
  * civicrm-common
  * python3-a38

  Reverse-Depends
  ===
  * odoo-16
  * python3-django-wkhtmltopdf
  * python3-pdfkit

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#1069574: age-old and insecure webkit package

2024-04-21 Thread Hadmut Danisch

Hi Dmitry,


even their own website

https://wkhtmltopdf.org/status.html

says:

   *Do not use wkhtmltopdf with any untrusted HTML* – be sure to
   sanitize any user-supplied HTML/JS, otherwise it can lead to
   complete takeover of the server it is running on! Please consider
   using a Mandatory Access Control system like AppArmor or SELinux,
   see recommended AppArmor policy .

Wouldn't it be more than enough or a reason to throw this out of 
debian/ubuntu, until they fixed this?



regards

Hadmut



Bug#1069574: age-old and insecure webkit package

2024-04-21 Thread Dmitry Shachnev
Hi Hadmut!

On Sat, Apr 20, 2024 at 09:23:37PM +0300, Hadmut Danisch wrote:
> Package: libqt5webkit5
>
> Version: 5.212.0~alpha4-30
>
>
> Hi,
>
> this was originally a bug report against Ubuntu 24.04 as 2061191, but since
> the package is community maintained and not by Ubuntu, they asked me to
> report it "upstreams".
>
>
> Ubuntu 24.04 beta / Debian bookworm still use libqt5webkit5.
>
> It is not obvious, where it comes from, but the version is still an alpha4,
> and the link in the README seems to suggest, that it still comes from
> https://github.com/annulen/webkit, which redirects to
> https://github.com/qtwebkit/qtwebkit, where the alpha4 tag is over 4 years
> old.
>
> There, the latest README tells:
>
> Code in this repository is obsolete. If you are looking for up-to-date
> QtWebKit use this fork: https://github.com/movableink/webkit
>
> https://github.com/movableink/webkit seems to be still maintained – more or
> less. And calls itself "inofficial mirror"

Unfortunately, movableink/webkit seems to be even less stable or ready than
qtwebkit/qtwebkit. For example, it is known that PyQt5 cannot be built
against it [1], and there are packages in Debian which need it:

  $ reverse-depends python3-pyqt5.qtwebkit
  Reverse-Recommends
  ==
  * linuxcnc-uspace [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
  * python3-ginga

  Reverse-Depends
  ===
  * frescobaldi [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
  * manuskript
  * openshot-qt
  * python3-pyface
  * python3-qgis [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
  * python3-qtpy
  * qutebrowser-qtwebkit
  * yade [amd64 arm64]

> Have a look at
>
> https://blogs.gnome.org/mcatanzaro/2022/11/04/stop-using-qtwebkit/
>
> which calls qtwebkit insecure, poorly maintained, and cites CVEs about
> remote code execution (some of them would have to be fixed in the fork, but
> probably not in the version here in ubuntu).
>
> The problem is, that tools like wkhtmltopdf do use this library and are
> typically used to pull contents from a given URL, i.e. from foreign
> websites.
>
> Processing foreign HTML and Javascript code in conjunction with
> vulnerabilities to remote code execution, this is highly dangerous.

I absolutely agree. Projects like wkhtmltopdf should stop using Qt WebKit
and should be ported to Qt WebEngine or other alternatives [2]. Once they do
that, we will be able to remove Qt WebKit from Debian.

Any help with filing bugs, both upstream and here in Debian, is welcome.

It is also worth noting that our Release Notes explicitly mention [3] that
Qt WebKit is not covered by security support, thus anyone who uses it with
untrusted input data does so on their own risk.

[1]: https://github.com/movableink/webkit/issues/16
[2]: ideally, they should be also ported from Qt 5 to Qt 6
[3]: 
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#1069574: age-old and insecure webkit package

2024-04-20 Thread Hadmut Danisch

Package: libqt5webkit5

Version: 5.212.0~alpha4-30


Hi,

this was originally a bug report against Ubuntu 24.04 as 2061191, but 
since the package is community maintained and not by Ubuntu, they asked 
me to report it "upstreams".



Ubuntu 24.04 beta / Debian bookworm still use libqt5webkit5.

It is not obvious, where it comes from, but the version is still an 
alpha4, and the link in the README seems to suggest, that it still comes 
from https://github.com/annulen/webkit 
, which redirects to 
https://github.com/qtwebkit/qtwebkit 
 , where the alpha4 tag is over 4 
years old.


There, the latest README tells:

Code in this repository is obsolete. If you are looking for up-to-date 
QtWebKit use this fork: https://github.com/movableink/webkit 



https://github.com/movableink/webkit 
 seems to be still maintained – 
more or less. And calls itself "inofficial mirror"


Have a look at

https://blogs.gnome.org/mcatanzaro/2022/11/04/stop-using-qtwebkit/ 



which calls qtwebkit insecure, poorly maintained, and cites CVEs about 
remote code execution (some of them would have to be fixed in the fork, 
but probably not in the version here in ubuntu).


The problem is, that tools like wkhtmltopdf do use this library and are 
typically used to pull contents from a given URL, i.e. from foreign 
websites.


Processing foreign HTML and Javascript code in conjunction with 
vulnerabilities to remote code execution, this is highly dangerous.



regards

Hadmut