From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: texmaker, Qt and Chromium Date: Sat, 08 Oct 2016 11:16:03 +0200 Message-ID: <874m4nuros.fsf@elephly.net> References: <877f9kufxx.fsf@elephly.net> <20161008105545.6154ed73@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsnjt-0006QA-5K for guix-devel@gnu.org; Sat, 08 Oct 2016 05:16:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsnjp-0000LO-Qj for guix-devel@gnu.org; Sat, 08 Oct 2016 05:16:16 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:21447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsnjp-0000Km-Gn for guix-devel@gnu.org; Sat, 08 Oct 2016 05:16:13 -0400 In-reply-to: <20161008105545.6154ed73@scratchpost.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel Danny Milosavljevic writes: > On Fri, 07 Oct 2016 21:17:30 +0200 > Ricardo Wurmus 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. I agree. But this doesn’t mean that we do upstream’s work. If software is vulnerable and there’s a fix we’ll apply it, but we cannot audit software ourselves. > 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. Correct, which is why I think it’s reasonable to disable “qtwebengine” as part of our default Qt package. Software that does depend on “qtwebengine”, however, can only be built when the module exists, which is why I’d like to package it separately. > 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. I’m not using Texmaker and I don’t know why it needs qtwebengine. I just see that the build is currently broken, so I’d like to find a solution. Either by removing the package or by packaging its (now missing) dependency. ~~ Ricardo