guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: texmaker, Qt and Chromium


From: Danny Milosavljevic
Subject: Re: texmaker, Qt and Chromium
Date: Sat, 8 Oct 2016 10:55:45 +0200

Hi,

On Fri, 07 Oct 2016 21:17:30 +0200
Ricardo Wurmus <address@hidden> wrote:
> our build of the “texmaker” package is broken ever since we disabled the
> webkit module of our Qt package.  I’m currently looking into packaging
> up the needed Qt modules, but the obvious question remains: do we want
> this?  “qtwebengine” not only bundles chromium, chromium itself also
> bundles a whole bunch of other stuff.
> 
> Personally, I think it’s acceptable to package “qtwebengine” because
> ultimately it’s up to the Qt and Chromium developers to keep their
> software secure

One of the reasons I'm using distributions rather than just ./configure ; make 
; make install is that distributors stay on top of security problems and 
disable and/or patch packages as problems arise. I think many others also 
mainly use distributions because of that.

Having security problems in dependencies-I-did-not-specify-to-be-installed is 
much worse than having them in a package I directly asked to be installed.

I'm still not clear on why texmaker needs an integrated web browser (with 
Javascript, support for video formats, access to the internet, background 
tasks, local store access, authentication support, dynamic font downloading, 
all my cookies, password storage etcetc). It's a frontend for TeX, right? Does 
TeX support HTML output and preview?

I've checked the texmaker source - seems they are using the web browser to 
display PDF (WTF...) and the help (documentation) and a plain text file (diff 
file).

They have commented out the call to QDesktopServices::openUrl() - which would 
be how I'd expect one to open a web page. I tried to find their source code 
repository in order to determine why, but failed.

(I think one should either write a webapp in which case run it in a web 
browser. Or write a desktop application in which case don't run it in a web 
browser. If you need a web browser, invoke the user's preferred web browser 
(automatically, if needed) in an extra process. Otherwise the attack surface is 
just too large...)

Having read the source code now, I'd rather not use it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]