texmaker, Qt and Chromium

texmaker, Qt and Chromium

[Ricardo Wurmus]

Hi Guix,

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 — and it’s up to the developers of software like
Texmaker to choose their dependencies wisely.  As long as we keep
Chromium out of our default “qt” package, thereby preventing it from
being installed for every Qt application, I think we’re good.

What do you think?  The alternative is to drop Texmaker and all the
other packages that depend on Chromium as distributed by Qt.

~~ Ricardo

Re: texmaker, Qt and Chromium

[Roel Janssen]

Ricardo Wurmus writes:

> Hi Guix,
>
> 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 — and it’s up to the developers of software like
> Texmaker to choose their dependencies wisely.  As long as we keep
> Chromium out of our default “qt” package, thereby preventing it from
> being installed for every Qt application, I think we’re good.
>
> What do you think?  The alternative is to drop Texmaker and all the
> other packages that depend on Chromium as distributed by Qt.

I'm not super familiar with Qt modules anymore, but can't we just
package the QtWebKit module?  How does QtWebEngine relate to QtWebKit?

Also, I know that Calibre is broken (it compiles file, but it doesn't
start anymore) since we are missing the QtWebKit module.

Thanks for your efforts for looking into this.

Kind regards,
Roel Janssen

Re: texmaker, Qt and Chromium

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Fri, Oct 07, 2016 at 09:17:30PM +0200, Ricardo Wurmus wrote:
     Hi Guix,
     
     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 ??? and it???s up to the developers of software like
     Texmaker to choose their dependencies wisely.  As long as we keep
     Chromium out of our default ???qt??? package, thereby preventing it from
     being installed for every Qt application, I think we???re good.
     
     What do you think?  The alternative is to drop Texmaker and all the
     other packages that depend on Chromium as distributed by Qt.
     

I thought that Chromium was non-free ??

J'
     

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: texmaker, Qt and Chromium

[Danny Milosavljevic]

Hi,

On Fri, 07 Oct 2016 21:17:30 +0200
Ricardo Wurmus <rekado@elephly.net> 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.

Re: texmaker, Qt and Chromium

[David Craven]

> What do you think?  The alternative is to drop Texmaker and all the
> other packages that depend on Chromium as distributed by Qt.

Weren't you vocal on IRC about bundling and the hell it brings? Sounds
like bundling is ok when it suits you... :) To be fair I've looked
into packaging chromium (with the inox patchset applied) [0] and I
came to the conclusion that it's impossible to debundle 100% (unless
you are a full-time chromium developer working on just this and fix
all the bugs that occur when using upstream packages etc. other
distros only unbundle chromium to an extent, it looks like gentoo
comes closest).

I'm running into a python issue: EOF where object expected when
importing certain modules during the build. When I execute the command
that ninja ran manually it succeeds, which is weird. If I run ninja
again to continue the build it fails on the next command with the same
error. If you'd like to look into this...

> I thought that Chromium was non-free ??

That's not quite true. The reason why chromium is sometimes considered
non-free is because of some default build settings it uses. You can
disable support for the chrome webstore and the hangouts extension,
etc. It also shouldn't be confused with Chrome which is indeed
non-free.

> I'm not super familiar with Qt modules anymore, but can't we just
> package the QtWebKit module?  How does QtWebEngine relate to QtWebKit?

QtWebKit is deprecated and no longer part of qt 5.7.

[0] https://github.com/dvc94ch/guix/commit/41bbf4060e805c8607ab9dc05012c1f929f6699e

Re: texmaker, Qt and Chromium

[Ricardo Wurmus]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Fri, 07 Oct 2016 21:17:30 +0200
> Ricardo Wurmus <rekado@elephly.net> 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

Re: texmaker, Qt and Chromium

[Ricardo Wurmus]

Roel Janssen <roel@gnu.org> writes:

> Ricardo Wurmus writes:
>> What do you think?  The alternative is to drop Texmaker and all the
>> other packages that depend on Chromium as distributed by Qt.
>
> I'm not super familiar with Qt modules anymore, but can't we just
> package the QtWebKit module?  How does QtWebEngine relate to QtWebKit?

I’m not familiar with this myself, but QtWebEngine is needed to build
QtWebView.  (There is no downloadable QtWebKit submodule.)

> Also, I know that Calibre is broken (it compiles file, but it doesn't
> start anymore) since we are missing the QtWebKit module.

Yet another package for which we would need to decide: remove the
package or add “qtwebengine”.

~~ Ricardo

Re: texmaker, Qt and Chromium

[Ricardo Wurmus]

David Craven <david@craven.ch> writes:

>> What do you think?  The alternative is to drop Texmaker and all the
>> other packages that depend on Chromium as distributed by Qt.
>
> Weren't you vocal on IRC about bundling and the hell it brings? Sounds
> like bundling is ok when it suits you... :)

I have no problems dropping Texmaker.  I’m not even using it.

~~ Ricardo

Re: texmaker, Qt and Chromium

[David Craven]

> I have no problems dropping Texmaker.  I’m not even using it.

That would be a shame, but I'm not using it either... I don't think
there's a problem with bundling in this case, I just don't understand
why you where against bundling in cargo's case, but not this one,
that's all. I'm all for striving for ideals and perfectionism, as long
as we keep in mind that nothing is perfect and stay pragmatic.

Re: texmaker, Qt and Chromium

[Ricardo Wurmus]

David Craven <david@craven.ch> writes:

>> I have no problems dropping Texmaker.  I’m not even using it.
>
> That would be a shame, but I'm not using it either... I don't think
> there's a problem with bundling in this case, I just don't understand
> why you where against bundling in cargo's case, but not this one,
> that's all. I'm all for striving for ideals and perfectionism, as long
> as we keep in mind that nothing is perfect and stay pragmatic.

The situation with Texmaker is: we used to have a build of Qt where
qtwebengine was included.  (This was before we had a set of modular Qt
packages, IIRC.)  Then we ripped qtwebengine out of the monolithic “qt”
package for good reasons.  As a result a couple of packages broke.

So this is about fixing a regression.  We still got rid of bundling for
*most* packages using Qt.

The approach you suggested for cargo (a new package) is to make bundling
the default and in the build system, if I understood correctly.

We’ve gone to great lengths to avoid bundling in providing other
packages.  See the Java bootstrap, for example, or Ruby.  I don’t think
it’s “perfectionist” to apply the same standards to other languages and
build systems.

~~ Ricardo

Re: texmaker, Qt and Chromium

[David Craven]

> We’ve gone to great lengths to avoid bundling in providing other
> packages.  See the Java bootstrap, for example, or Ruby.  I don’t think
> it’s “perfectionist” to apply the same standards to other languages and
> build systems.

Maybe it wasn't such a good idea, but since crates are distributed in
source form and compiled statically I didn't see much advantage in
unbundling them. And from what I understand the reason why the js
build system hasn't landed yet is because of similar complications. It
could also be me just being lazy of course... :) I'll revisit this
some other time...

Re: texmaker, Qt and Chromium

[Danny Milosavljevic]

Hi,

On Sat, 08 Oct 2016 11:16:03 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> 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.

Oh, then I agree - as long as the qtwebengine package (or any package, really) cannot be accidentially installed if known vulnerabilities exist.

> I’m not using Texmaker and 

>I don’t know why it needs qtwebengine. 

You do now :)

> 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.

In this specific case I vote for either removing the package or patching it that it does QDesktopServices::openUrl() as it should. If it were up to me I'd remove it. But maybe people use it - so they, if any, can patch it. It entails changing about 5 lines (commenting one block out and re-enabling the other block that is already there).

That reminds me, is there something like Gentoo's "/etc/portage/package.mask" in Guix where I can (permanently) specify packages that I don't want to be installed - as a resolved dependency or otherwise? Some way I can nuke a package variable permanently? 

Like

  guix build --with-input=texmaker=bash something

but permanently for all guix commands...

Re: texmaker, Qt and Chromium

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On Fri, Oct 07, 2016 at 09:17:30PM +0200, Ricardo Wurmus wrote:
> Hi Guix,
> 
> 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 — and it’s up to the developers of software like
> Texmaker to choose their dependencies wisely.  As long as we keep
> Chromium out of our default “qt” package, thereby preventing it from
> being installed for every Qt application, I think we’re good.
> 
> What do you think?  The alternative is to drop Texmaker and all the
> other packages that depend on Chromium as distributed by Qt.
> 
> ~~ Ricardo
> 

AFAIK Chromium doesn't modify any of its bundled software. Would it make
sense to create a chromium-source package that replaces the bundled
sources with our sources, allowing us to keep the chromium source and
the bundled source up-to-date. Then we could use this new
'chromium-source' package as a replacement source for
chromium/inox/qtwebengine?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: texmaker, Qt and Chromium

[Ricardo Wurmus]

Efraim Flashner <efraim@flashner.co.il> writes:

> AFAIK Chromium doesn't modify any of its bundled software. Would it make
> sense to create a chromium-source package that replaces the bundled
> sources with our sources, allowing us to keep the chromium source and
> the bundled source up-to-date. Then we could use this new
> 'chromium-source' package as a replacement source for
> chromium/inox/qtwebengine?

Are you certain they don’t modify their bundle?  I thought that was the
whole point for them to bundle things in the first place: to be able to
modify things without having to coordinate with the various upstreams.

~~ Ricardo

Re: texmaker, Qt and Chromium

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

On Sat, Oct 08, 2016 at 11:00:29PM +0200, Ricardo Wurmus wrote:
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > AFAIK Chromium doesn't modify any of its bundled software. Would it make
> > sense to create a chromium-source package that replaces the bundled
> > sources with our sources, allowing us to keep the chromium source and
> > the bundled source up-to-date. Then we could use this new
> > 'chromium-source' package as a replacement source for
> > chromium/inox/qtwebengine?
> 
> Are you certain they don’t modify their bundle?  I thought that was the
> whole point for them to bundle things in the first place: to be able to
> modify things without having to coordinate with the various upstreams.
> 
> ~~ Ricardo
> 

I'm not sure, but I assumed it was so that anyone could download the
source and run './configure; make; (sudo) make install' without worrying
about those pesky things known as dependancies.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: texmaker, Qt and Chromium

[ng0]

Efraim Flashner <efraim@flashner.co.il> writes:

> [ Unknown signature status ]
> On Sat, Oct 08, 2016 at 11:00:29PM +0200, Ricardo Wurmus wrote:
>> 
>> Efraim Flashner <efraim@flashner.co.il> writes:
>> 
>> > AFAIK Chromium doesn't modify any of its bundled software. Would it make
>> > sense to create a chromium-source package that replaces the bundled
>> > sources with our sources, allowing us to keep the chromium source and
>> > the bundled source up-to-date. Then we could use this new
>> > 'chromium-source' package as a replacement source for
>> > chromium/inox/qtwebengine?
>> 
>> Are you certain they don’t modify their bundle?  I thought that was the
>> whole point for them to bundle things in the first place: to be able to
>> modify things without having to coordinate with the various upstreams.
>> 
>> ~~ Ricardo
>> 
>
> I'm not sure, but I assumed it was so that anyone could download the
> source and run './configure; make; (sudo) make install' without worrying
> about those pesky things known as dependancies.
>
> -- 
> Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

As far as I know - I could be wrong - I linked to the bug ticket for
unbundling chromium in my inox.scm ... Fedora got so frustrated over
the whole, well... neglection.. of the ticket that they forked
chromium. I would say at best it (unbundling) just works, but not with
all of the dependencies/bundles as far as I understand comments Gentoo
and Archlinux do in their chrome/chromium/inox related packages.

Re: texmaker, Qt and Chromium

[Danny Milosavljevic]

On Sun, 9 Oct 2016 00:08:50 +0300
Efraim Flashner <efraim@flashner.co.il> wrote:
> I'm not sure, but I assumed it was so that anyone could download the
> source and run './configure; make; (sudo) make install' without worrying
> about those pesky things known as dependancies.

That's certainly why I bundle. Also that the dependencies don't suddenly change their API or version or anything.

So I don't think that just because something is bundled it is modified.

After all, you as a bundler have to eventually (on *your* schedule) update the bundled dependencies and then you have to port all your modifications. I always ensure that I don't modify anything in it (or as little as possible if it can't be helped).

Of course I can't speak on why they do it.

Re: texmaker, Qt and Chromium

[Roel Janssen]

Ricardo Wurmus writes:

> David Craven <david@craven.ch> writes:
>
>>> What do you think?  The alternative is to drop Texmaker and all the
>>> other packages that depend on Chromium as distributed by Qt.
>>
>> Weren't you vocal on IRC about bundling and the hell it brings? Sounds
>> like bundling is ok when it suits you... :)
>
> I have no problems dropping Texmaker.  I’m not even using it.

Ouch.  I was the one who submitted the package when the Qt modules
weren't unbundled yet (I guess).  Now, because of a change of how we
package Qt, we're ready to remove a program that used to work just
fine..?

What's next?  Throw the calibre package out of the window too because
it's broken for GNU Guix users?

Kind regards,
Roel Janssen

Re: texmaker, Qt and Chromium

[Ricardo Wurmus]

Roel Janssen <roel@gnu.org> writes:

> Ricardo Wurmus writes:
>
>> David Craven <david@craven.ch> writes:
>>
>>>> What do you think?  The alternative is to drop Texmaker and all the
>>>> other packages that depend on Chromium as distributed by Qt.
>>>
>>> Weren't you vocal on IRC about bundling and the hell it brings? Sounds
>>> like bundling is ok when it suits you... :)
>>
>> I have no problems dropping Texmaker.  I’m not even using it.
>
> Ouch.  I was the one who submitted the package when the Qt modules
> weren't unbundled yet (I guess).  Now, because of a change of how we
> package Qt, we're ready to remove a program that used to work just
> fine..?
>
> What's next?  Throw the calibre package out of the window too because
> it's broken for GNU Guix users?

Today I don’t seem to be communicating effectively.  What I meant was
that *personally* I have no interest in this software, which should be
sufficient to defuse the insinuation that I think “bundling is ok when
it suits [me]” (a remark I consider needlessly inflammatory, despite the
emoticon).

Obviously, I haven’t removed Texmaker — that would have been a simpler
fix to a broken build than what I actually did: investigating the issue,
packaging up more Qt modules, looking into the sources of qtwebengine,
and discussing what to do on the mailing list.

All I’m saying is that we must do *something* because right now the
situation is just as if we had dropped Texmaker: it cannot be built,
neither on Hydra nor on individual people’s machines.  And it won’t be
buildable unless someone does the work.  Hence my email.

I feel I’ve spent too much time of my Saturday on this already.  I’m not
very motivated to continue working on this.

~~ Ricardo

Re: texmaker, Qt and Chromium

[Danny Milosavljevic]

On Sat, 08 Oct 2016 23:35:53 +0200
Roel Janssen <roel@gnu.org> wrote:
> Ouch.  I was the one who submitted the package when the Qt modules
> weren't unbundled yet (I guess). 

Ah. There are two calls QDesktopServices::openUrl commented out. You can put them back in and remove the instantiations of the Browser class right above (if you patch carefully, you actually change very little). It works.

If you want you can also send your patch upstream and everyone will have a little better security. Maybe it makes it into the next release of texmaker.

> What's next?  Throw the calibre package out of the window too because
> it's broken for GNU Guix users?

calibre had bad security problems [1] in the past (and also fixed them badly) and I wouldn't use it outside a VM.

I can't speak on what Guix does, of course. I'm just pointing out that these happen to be two packages where using them is not wise.

[1] https://bugs.launchpad.net/calibre/+cve

Re: texmaker, Qt and Chromium

[Leo Famulari]

On Sat, Oct 08, 2016 at 11:18:55AM +0200, Ricardo Wurmus wrote:
> 
> Roel Janssen <roel@gnu.org> writes:
> > Also, I know that Calibre is broken (it compiles file, but it doesn't
> > start anymore) since we are missing the QtWebKit module.
> 
> Yet another package for which we would need to decide: remove the
> package or add “qtwebengine”.

I don't know anything about qtwebengine besides what's in this
discussion but, based on that, I think we should package qtwebengine if
Calibre requires it.

As far as I know, there is no program that can replace Calibre's ebook
conversion and formatting tools.

Security updates (was Re: texmaker, Qt and Chromium)

[Leo Famulari]

On Sat, Oct 08, 2016 at 10:55:45AM +0200, Danny Milosavljevic wrote:
> 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'm going off-topic here, but... Please Help :)

Right now there are only a few of us paying attention to security bug
disclosures and, in my opinion, that's not enough.

If you are interested in keeping Guix secure, try subscribing to the
oss-sec mailing list. If you use Guix on a foreign distro, you can
subscribe to that distro's security announcement list. If you are the de
facto maintainer of some Guix packages, or if you run your business on
some Guix packages, follow the upstream bug reports.

And then, patch bugs in our packages. If you aren't sure how to fix the
bugs, it's still helpful to present them on guix-devel and ask for
advice.

Help Wanted!

[0]
http://seclists.org/oss-sec/

[1] For example:
https://lists.debian.org/debian-security-announce/

Re: Security updates (was Re: texmaker, Qt and Chromium)

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Sat, Oct 08, 2016 at 10:55:45AM +0200, Danny Milosavljevic wrote:
>> 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'm going off-topic here, but... Please Help :)
>
> Right now there are only a few of us paying attention to security bug
> disclosures and, in my opinion, that's not enough.
>
> If you are interested in keeping Guix secure, try subscribing to the
> oss-sec mailing list. If you use Guix on a foreign distro, you can
> subscribe to that distro's security announcement list. If you are the de
> facto maintainer of some Guix packages, or if you run your business on
> some Guix packages, follow the upstream bug reports.
>
> And then, patch bugs in our packages. If you aren't sure how to fix the
> bugs, it's still helpful to present them on guix-devel and ask for
> advice.
>
> Help Wanted!
>
> [0]
> http://seclists.org/oss-sec/
>
> [1] For example:
> https://lists.debian.org/debian-security-announce/

Subscribed to the oss-sec list!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Security updates (was Re: texmaker, Qt and Chromium)

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Sat, Oct 08, 2016 at 10:55:45AM +0200, Danny Milosavljevic wrote:
>> 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'm going off-topic here, but... Please Help :)
>
> Right now there are only a few of us paying attention to security bug
> disclosures and, in my opinion, that's not enough.

I agree.  I’m very grateful of all the work you’ve been doing, but I
think we should all start doing our share before you get tired of it!

Ludo’.

Re: Security updates (was Re: texmaker, Qt and Chromium)

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

On Sun, Oct 09, 2016 at 05:07:34PM -0400, Kei Kebreau wrote:
> Subscribed to the oss-sec list!

Thank you Kei!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: texmaker, Qt and Chromium

[Roel Janssen]

Ricardo Wurmus writes:

> Roel Janssen <roel@gnu.org> writes:
>
>> Ricardo Wurmus writes:
>>
>>> David Craven <david@craven.ch> writes:
>>>
>>>>> What do you think?  The alternative is to drop Texmaker and all the
>>>>> other packages that depend on Chromium as distributed by Qt.
>>>>
>>>> Weren't you vocal on IRC about bundling and the hell it brings? Sounds
>>>> like bundling is ok when it suits you... :)
>>>
>>> I have no problems dropping Texmaker.  I’m not even using it.
>>
>> Ouch.  I was the one who submitted the package when the Qt modules
>> weren't unbundled yet (I guess).  Now, because of a change of how we
>> package Qt, we're ready to remove a program that used to work just
>> fine..?
>>
>> What's next?  Throw the calibre package out of the window too because
>> it's broken for GNU Guix users?
>
> Today I don’t seem to be communicating effectively.  What I meant was
> that *personally* I have no interest in this software, which should be
> sufficient to defuse the insinuation that I think “bundling is ok when
> it suits [me]” (a remark I consider needlessly inflammatory, despite the
> emoticon).
>
> Obviously, I haven’t removed Texmaker — that would have been a simpler
> fix to a broken build than what I actually did: investigating the issue,
> packaging up more Qt modules, looking into the sources of qtwebengine,
> and discussing what to do on the mailing list.
>
> All I’m saying is that we must do *something* because right now the
> situation is just as if we had dropped Texmaker: it cannot be built,
> neither on Hydra nor on individual people’s machines.  And it won’t be
> buildable unless someone does the work.  Hence my email.
>
> I feel I’ve spent too much time of my Saturday on this already.  I’m not
> very motivated to continue working on this.

Right.  I'm looking into it.  It seems that Texmaker wants
"Webkitwidgets", which are unsupported since version 5.6:

From https://blog.qt.io/blog/2016/03/16/qt-5-6-released/:
> With 5.6, Qt WebKit and Qt Quick 1 will no longer be supported and are
> dropped from the release. The source code for these modules will still
> be available. You can continue to compile and use these modules, but
> we will not be supporting them any longer.

So we should be able to compile it separately as described here:
http://www.linuxfromscratch.org/blfs/view/svn/x/qtwebkit5.html

This only makes me wonder whether this is at all secure.

I will try to add a separate qt-webkit(widgets) package and see if that
solves the build problems for Texmaker.

Kind regards,
Roel Janssen

Re: Security updates (was Re: texmaker, Qt and Chromium)

[ng0]

Leo Famulari <leo@famulari.name> writes:

> On Sat, Oct 08, 2016 at 10:55:45AM +0200, Danny Milosavljevic wrote:
>> 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'm going off-topic here, but... Please Help :)
>
> Right now there are only a few of us paying attention to security bug
> disclosures and, in my opinion, that's not enough.
>
> If you are interested in keeping Guix secure, try subscribing to the
> oss-sec mailing list. If you use Guix on a foreign distro, you can
> subscribe to that distro's security announcement list. If you are the de
> facto maintainer of some Guix packages, or if you run your business on
> some Guix packages, follow the upstream bug reports.
>
> And then, patch bugs in our packages. If you aren't sure how to fix the
> bugs, it's still helpful to present them on guix-devel and ask for
> advice.
>
> Help Wanted!
>
> [0]
> http://seclists.org/oss-sec/
>
> [1] For example:
> https://lists.debian.org/debian-security-announce/
>
>

I can second this help request. It's hard to keep track of the
vulnerabilities. Because I maintain packages for Gentoo I find the
frequently released GLSAs of Gentoo very useful too. They are Gentoo
specific, but Gentoo has a good amount of packages to keep track of.
It can be subscribed via Email or feed reader here:
https://www.gentoo.org/support/security/

-- ng0