Re: Security updates for bundled copies of libraries in Qt

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> Fair enough, but consider this: IMO, the most severe problem with using
> bundled copies of libraries has to do with security updates.  We have
> yet to develop a security policy, but in my opinion we should not allow
> software with known security flaws to remain in Guix for more than a
> short time.  Either someone must take responsibility for applying
> security fixes to a given package, or else that package should be
> removed.  Does that make sense?

I think it is clear that we must avoid bundled libraries, and it seems
there’s consensus on this.  Would someone like to prepare a subsection
on this under “Packaging Guidelines”?

As for the policy of removing packages that lack security updates, I’d
be all for it in an ideal world.  However, I wonder if we can afford to
follow an all-or-nothing policy this strictly at this point.

To palliate our limited development resources, what we do need is tools
(perhaps an extension to ‘guix refresh’ or ‘guix lint’) to at least
determine whether there are unpatched CVEs in our packages.  I know this
is possible because the Nixpkgs Monitor has something like that:
<https://github.com/Phreedom/nixpkgs-monitor>.

I’ve just opened a bug for it.  Any takers?

> I've been doing my best to apply security fixes to Guix in a timely
> fashion -- which turns out to be a big job and I could use more help --
> but I'm *not* willing to do the duplicated work of applying the same
> fixes to the bundled copies of libraries in Qt.  If our Qt packages are
> going to use bundled copies of libraries, then someone needs to take
> responsibility for applying security updates to those copies.

In <https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00302.html>
there was consensus that, to begin with, we should remove the bundled
Chromium and all the things it pulls from Qt5, and 宋文武
half-volunteered ;-) to work on the modular Qt5.

I’ve open a bug to keep track of this (bugs.gnu.org seems to be
currently unreachable, though.)

Ludo’.