Staying on top of Qt security

Staying on top of Qt security

[Leo Famulari]

It's been pointed out in the past that Qt [0] bundles many other softare
distributions, making it more difficult to fully apply security updates.
One would have to *know* what software was bundled and be sure to update
the bundled copy along with the standalone copy.

I asked for guidance on #qt [2] and they pointed me to their security
policy:
https://wiki.qt.io/Qt_project_security_policy

The salient points are:

1) Security updates are only guaranteed for the latest version, and the
preceding minor version. Updates may be issued for earlier versions but
there is no commitment from Qt on this subject.

2) Security problems will be publicly disclosed to the
annouce@qt-project.org mailing list.

3) There is an early notification system for those who need it, such as
distribution packagers (like us) on a private security-annouce mailing
list.

We currently package qt-4.8.7 and qt-5.5.1. My interpretation of Qt's
policy is that 4.x is unsupported, while 5.5 is supported, but I might
be wrong; their website is a real maze.

I think we need a Qt champion(s) for Guix.

Here is what I think this person should do:

1) Get on the Qt security-announce list so that we can patch bugs before
they are disclosed.

2) Figure out *what* 3rd party software is bundled by Qt and try to make
Qt use external versions of this software. This will go a long way to
making our Qt packaging secure.

3) Manage the process of removing unsupported versions of Qt. This means
upgraded dependent packages once they support the latest Qt release. [3]

4) Help us decide what do about about Qt dependent packages that only
work with unsupported versions of Qt.

This is my first time thinking about this sort of issue, so it's
quite possible that my recommendations are wrong or incomplete!

Your thoughts? Any takers?

[0]
http://www.qt.io/

[1]
https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00302.html
https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00018.html

[2]
irc://irc.freenode.net/qt

[3]
$ guix refresh -l qt-4                        
Building the following 18 packages would ensure 24 dependent packages
are rebuilt: soprano-2.9.4 python2-pyqt-4.11.4 polkit-qt-1-0.112.0
frescobaldi-2.18.1 keepassx-2.0.2 hydrogen-0.9.5.1 strigi-0.7.8
attica-0.4.2 pumpa-0.9.2 libdbusmenu-qt-0.9.2 phonon-4.8.3
brdf-explorer-17 gpsbabel-1.5.0 librecad-2.0.6-rc
alsa-modular-synth-2.1.2 qtractor-0.7.3 ardour-4.4 jalv-1.4.6

Re: Staying on top of Qt security

[Andreas Enge]

Hi Leo,

thanks for your initiative!

On Sun, Feb 14, 2016 at 03:01:43PM -0500, Leo Famulari wrote:
> I think we need a Qt champion(s) for Guix.

I am not volunteering, mainly because I am not a Qt champion (but I am
interested in the package).

> $ guix refresh -l qt-4                        
> Building the following 18 packages would ensure 24 dependent packages
> are rebuilt: soprano-2.9.4 python2-pyqt-4.11.4 polkit-qt-1-0.112.0
> frescobaldi-2.18.1 keepassx-2.0.2 hydrogen-0.9.5.1 strigi-0.7.8
> attica-0.4.2 pumpa-0.9.2 libdbusmenu-qt-0.9.2 phonon-4.8.3
> brdf-explorer-17 gpsbabel-1.5.0 librecad-2.0.6-rc
> alsa-modular-synth-2.1.2 qtractor-0.7.3 ardour-4.4 jalv-1.4.6

Some of them have no dependent packages, and I think they are mainly or
exclusively used for KDE-4, which I started packaging a while ago (and
dropped again when I got my Novena, as it turns out that KDE is too
resource demanding). In any case, we would package KDE-5 now, and I would
suggest to simply remove these packages. There are traces in git, so if
it turns out we will need them in the end, we can still revive them.
This concerns:
attica soprano strigi polkit-qt automoc4 qjson libdbusmenu-qt
So while we are it it, I suggest to simply remove kde.scm (there is no use
in keeping a lonely oxygen-icons around...).

Also, python2-pyqt has no dependent package.

I looked at frescobaldi; they claim that a Qt-5 port is on the TODO list
for their version 3, but without giving any timings.

If there is no outcry, I will remove the above-mentioned packages/modules.

Could maybe people using the other packages have a look at them?

Chris, what about pumpa?

Andreas

Re: Staying on top of Qt security

[Leo Famulari]

On Thu, Feb 18, 2016 at 09:43:49PM +0100, Andreas Enge wrote:
> Hi Leo,
> 
> thanks for your initiative!
> 
> On Sun, Feb 14, 2016 at 03:01:43PM -0500, Leo Famulari wrote:
> > I think we need a Qt champion(s) for Guix.
> 
> I am not volunteering, mainly because I am not a Qt champion (but I am
> interested in the package).
> 
> > $ guix refresh -l qt-4                        
> > Building the following 18 packages would ensure 24 dependent packages
> > are rebuilt: soprano-2.9.4 python2-pyqt-4.11.4 polkit-qt-1-0.112.0
> > frescobaldi-2.18.1 keepassx-2.0.2 hydrogen-0.9.5.1 strigi-0.7.8
> > attica-0.4.2 pumpa-0.9.2 libdbusmenu-qt-0.9.2 phonon-4.8.3
> > brdf-explorer-17 gpsbabel-1.5.0 librecad-2.0.6-rc
> > alsa-modular-synth-2.1.2 qtractor-0.7.3 ardour-4.4 jalv-1.4.6
> 
> Some of them have no dependent packages, and I think they are mainly or
> exclusively used for KDE-4, which I started packaging a while ago (and
> dropped again when I got my Novena, as it turns out that KDE is too
> resource demanding). In any case, we would package KDE-5 now, and I would
> suggest to simply remove these packages. There are traces in git, so if
> it turns out we will need them in the end, we can still revive them.
> This concerns:
> attica soprano strigi polkit-qt automoc4 qjson libdbusmenu-qt
> So while we are it it, I suggest to simply remove kde.scm (there is no use
> in keeping a lonely oxygen-icons around...).
> 
> Also, python2-pyqt has no dependent package.
> 
> I looked at frescobaldi; they claim that a Qt-5 port is on the TODO list
> for their version 3, but without giving any timings.
> 
> If there is no outcry, I will remove the above-mentioned packages/modules.
> 
> Could maybe people using the other packages have a look at them?

I noticed that Efraim has upgraded a few qt-4 dependencies so that they
can use qt(-5).

> 
> Chris, what about pumpa?
> 
> Andreas
> 

Re: Staying on top of Qt security

[Christopher Allan Webber]

Andreas Enge writes:

> Chris, what about pumpa?

I'm assuming this was directed at me (though I don't work on Pumpa, but
I could ask the author things... I do *use* it every day though).  What
am I being asked here... I'm not sure?  Whether Pumpa could be updated
to QT 5?

Re: Staying on top of Qt security

[Andreas Enge]

On Thu, Feb 18, 2016 at 02:53:40PM -0800, Christopher Allan Webber wrote:
> I'm assuming this was directed at me (though I don't work on Pumpa, but
> I could ask the author things... I do *use* it every day though).  What
> am I being asked here... I'm not sure?  Whether Pumpa could be updated
> to QT 5?

I think so :-)

The alternative question would have been whether we could remove it,
but I already knew the answer...

Andreas

Re: Staying on top of Qt security

[Christopher Allan Webber]

Andreas Enge writes:

> On Thu, Feb 18, 2016 at 02:53:40PM -0800, Christopher Allan Webber wrote:
>> I'm assuming this was directed at me (though I don't work on Pumpa, but
>> I could ask the author things... I do *use* it every day though).  What
>> am I being asked here... I'm not sure?  Whether Pumpa could be updated
>> to QT 5?
>
> I think so :-)
>
> The alternative question would have been whether we could remove it,
> but I already knew the answer...
>
> Andreas

From Sazius:

  Hi! Pumpa already works with Qt 5, I'm running it on Qt 5.3.2 in Debian
  jessie myself. If you have any problems (e.g. with a newer version of
  Qt) I would consider it a bug and try to fix it :-)

So it looks like we just need to update the pacakge?

Re: Staying on top of Qt security

[Efraim Flashner]

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

On Thu, 18 Feb 2016 17:35:29 -0500
Leo Famulari <leo@famulari.name> wrote:

> On Thu, Feb 18, 2016 at 09:43:49PM +0100, Andreas Enge wrote:
>  [...]  
>  [...]  
>  [...]  
> > > $ guix refresh -l qt-4                        
> > > Building the following 18 packages would ensure 24 dependent packages
> > > are rebuilt: soprano-2.9.4 python2-pyqt-4.11.4 polkit-qt-1-0.112.0
> > > frescobaldi-2.18.1 keepassx-2.0.2 hydrogen-0.9.5.1 strigi-0.7.8
> > > attica-0.4.2 pumpa-0.9.2 libdbusmenu-qt-0.9.2 phonon-4.8.3
> > > brdf-explorer-17 gpsbabel-1.5.0 librecad-2.0.6-rc
> > > alsa-modular-synth-2.1.2 qtractor-0.7.3 ardour-4.4 jalv-1.4.6  
> > 
> > Some of them have no dependent packages, and I think they are mainly or
> > exclusively used for KDE-4, which I started packaging a while ago (and
> > dropped again when I got my Novena, as it turns out that KDE is too
> > resource demanding). In any case, we would package KDE-5 now, and I would
> > suggest to simply remove these packages. There are traces in git, so if
> > it turns out we will need them in the end, we can still revive them.
> > This concerns:
> > attica soprano strigi polkit-qt automoc4 qjson libdbusmenu-qt
> > So while we are it it, I suggest to simply remove kde.scm (there is no use
> > in keeping a lonely oxygen-icons around...).
> > 
> > Also, python2-pyqt has no dependent package.
> > 
> > I looked at frescobaldi; they claim that a Qt-5 port is on the TODO list
> > for their version 3, but without giving any timings.
> > 
> > If there is no outcry, I will remove the above-mentioned packages/modules.
> > 
> > Could maybe people using the other packages have a look at them?  
> 
> I noticed that Efraim has upgraded a few qt-4 dependencies so that they
> can use qt(-5).
> 

A bunch of the programs that use qt-4 currently use the cmake-build-system,
and it seems that cmake or something else reads Qt > 4.2 and won't accept
qt-5 as an input. Currently CMake is at 3.3.2, I was going to update it to
3.4.3 but 3.5.0 is almost out. It could be that this is what allows those
programs to be switched.


-- 
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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Staying on top of Qt security

[Leo Famulari]

On Sat, Feb 20, 2016 at 10:27:52AM -0800, Christopher Allan Webber wrote:
> Andreas Enge writes:
> 
> > On Thu, Feb 18, 2016 at 02:53:40PM -0800, Christopher Allan Webber wrote:
> >> I'm assuming this was directed at me (though I don't work on Pumpa, but
> >> I could ask the author things... I do *use* it every day though).  What
> >> am I being asked here... I'm not sure?  Whether Pumpa could be updated
> >> to QT 5?
> >
> > I think so :-)
> >
> > The alternative question would have been whether we could remove it,
> > but I already knew the answer...
> >
> > Andreas
> 
> From Sazius:
> 
>   Hi! Pumpa already works with Qt 5, I'm running it on Qt 5.3.2 in Debian
>   jessie myself. If you have any problems (e.g. with a newer version of
>   Qt) I would consider it a bug and try to fix it :-)
> 
> So it looks like we just need to update the pacakge?

The blocker is the Pumpa dependency QJson, which has a hard dependency
on Qt-4. QJson is also used by libdbusmenu-qt.

Apparently QJson's master branch has supported Qt-5 for some time, so I
asked the maintainers if that is true, and if they plan to issue a new
release [0]. We could try packaging from git.

[0]
https://github.com/flavio/qjson/issues/49

Re: Staying on top of Qt security

[Christopher Allan Webber]

Leo Famulari writes:

> On Sat, Feb 20, 2016 at 10:27:52AM -0800, Christopher Allan Webber wrote:
>> Andreas Enge writes:
>> 
>> > On Thu, Feb 18, 2016 at 02:53:40PM -0800, Christopher Allan Webber wrote:
>> >> I'm assuming this was directed at me (though I don't work on Pumpa, but
>> >> I could ask the author things... I do *use* it every day though).  What
>> >> am I being asked here... I'm not sure?  Whether Pumpa could be updated
>> >> to QT 5?
>> >
>> > I think so :-)
>> >
>> > The alternative question would have been whether we could remove it,
>> > but I already knew the answer...
>> >
>> > Andreas
>> 
>> From Sazius:
>> 
>>   Hi! Pumpa already works with Qt 5, I'm running it on Qt 5.3.2 in Debian
>>   jessie myself. If you have any problems (e.g. with a newer version of
>>   Qt) I would consider it a bug and try to fix it :-)
>> 
>> So it looks like we just need to update the pacakge?
>
> The blocker is the Pumpa dependency QJson, which has a hard dependency
> on Qt-4. QJson is also used by libdbusmenu-qt.
>
> Apparently QJson's master branch has supported Qt-5 for some time, so I
> asked the maintainers if that is true, and if they plan to issue a new
> release [0]. We could try packaging from git.
>
> [0]
> https://github.com/flavio/qjson/issues/49

Sounds good.  If they don't make a new release, I think packaging from
git is the best option.

Re: Staying on top of Qt security

[Leo Famulari]

On Sun, Feb 21, 2016 at 09:42:43AM -0800, Christopher Allan Webber wrote:
> Leo Famulari writes:
> 
> > On Sat, Feb 20, 2016 at 10:27:52AM -0800, Christopher Allan Webber wrote:
> >> Andreas Enge writes:
> >> 
> >> > On Thu, Feb 18, 2016 at 02:53:40PM -0800, Christopher Allan Webber wrote:
> >> >> I'm assuming this was directed at me (though I don't work on Pumpa, but
> >> >> I could ask the author things... I do *use* it every day though).  What
> >> >> am I being asked here... I'm not sure?  Whether Pumpa could be updated
> >> >> to QT 5?
> >> >
> >> > I think so :-)
> >> >
> >> > The alternative question would have been whether we could remove it,
> >> > but I already knew the answer...
> >> >
> >> > Andreas
> >> 
> >> From Sazius:
> >> 
> >>   Hi! Pumpa already works with Qt 5, I'm running it on Qt 5.3.2 in Debian
> >>   jessie myself. If you have any problems (e.g. with a newer version of
> >>   Qt) I would consider it a bug and try to fix it :-)
> >> 
> >> So it looks like we just need to update the pacakge?
> >
> > The blocker is the Pumpa dependency QJson, which has a hard dependency
> > on Qt-4. QJson is also used by libdbusmenu-qt.
> >
> > Apparently QJson's master branch has supported Qt-5 for some time, so I
> > asked the maintainers if that is true, and if they plan to issue a new
> > release [0]. We could try packaging from git.
> >
> > [0]
> > https://github.com/flavio/qjson/issues/49
> 
> Sounds good.  If they don't make a new release, I think packaging from
> git is the best option.

I agree. If they don't issue a new release in the next couple of days,
I will test packaging from git.

Re: Staying on top of Qt security

[Andreas Enge]

Sorry, Chris, that I bothered you with the state of pumpa; I was so convinced
that you were the packager that I did not even check! I suppose that I have
read too many of your blog posts to planet gnu; whenever I hear "federation"
or "pumpsomething" now, I think of you.

On Sun, Feb 21, 2016 at 09:42:43AM -0800, Christopher Allan Webber wrote:
> Leo Famulari writes:
> > Apparently QJson's master branch has supported Qt-5 for some time, so I
> > asked the maintainers if that is true, and if they plan to issue a new
> > release [0]. We could try packaging from git.
> > https://github.com/flavio/qjson/issues/49

Thanks for the initiative!

> Sounds good.  If they don't make a new release, I think packaging from
> git is the best option.

I am not a big fan of packaging from non-release versions. Maybe you could
convince upstream that this is enough of an exciting change to make a release,
Leo? In the end, it is probably more interesting and important to get rid
of Qt-4 than to not package from git. But there are still other packages
requiring Qt-4. Maybe we should wait a bit until their number is more reduced, 
and then take a joint decision for the remaining ones.

Andreas

Re: Staying on top of Qt security

[Leo Famulari]

On Mon, Feb 22, 2016 at 08:53:39PM +0100, Andreas Enge wrote:
> Sorry, Chris, that I bothered you with the state of pumpa; I was so convinced
> that you were the packager that I did not even check! I suppose that I have
> read too many of your blog posts to planet gnu; whenever I hear "federation"
> or "pumpsomething" now, I think of you.
> 
> On Sun, Feb 21, 2016 at 09:42:43AM -0800, Christopher Allan Webber wrote:
> > Leo Famulari writes:
> > > Apparently QJson's master branch has supported Qt-5 for some time, so I
> > > asked the maintainers if that is true, and if they plan to issue a new
> > > release [0]. We could try packaging from git.
> > > https://github.com/flavio/qjson/issues/49
> 
> Thanks for the initiative!
> 
> > Sounds good.  If they don't make a new release, I think packaging from
> > git is the best option.
> 
> I am not a big fan of packaging from non-release versions. Maybe you could
> convince upstream that this is enough of an exciting change to make a release,
> Leo? In the end, it is probably more interesting and important to get rid
> of Qt-4 than to not package from git. But there are still other packages
> requiring Qt-4. Maybe we should wait a bit until their number is more reduced, 
> and then take a joint decision for the remaining ones.

I agree that packaging non-release versions is not ideal. We may trade
one security issue for another, since non-release commits are usually
not scrutinized as much by upstream.

My plan is to wait a little bit to see if QJson takes action.

Another option is to persuade the Pumpa upstream to stop using QJson.

Re: Staying on top of Qt security

[Andreas Enge]

On Thu, Feb 18, 2016 at 09:43:49PM +0100, Andreas Enge wrote:
> So while we are it it, I suggest to simply remove kde.scm (there is no use
> in keeping a lonely oxygen-icons around...).
> Also, python2-pyqt has no dependent package.
> If there is no outcry, I will remove the above-mentioned packages/modules.

Done and pushed.

Andreas

Re: Staying on top of Qt security

[Andreas Enge]

On Sun, Feb 21, 2016 at 02:28:37AM -0500, Leo Famulari wrote:
> QJson is also used by libdbusmenu-qt.

The latter is also gone with the KDE 4 module. It had no followers outside
of it, but if it turns out to be needed somewhere else, we will have to
think again.

Andreas

Re: Staying on top of Qt security

[Andreas Enge]

Hello,

looking at why ardour depends on qt-4, I came across suil:
    (description
     "Suil is a lightweight C library for loading and wrapping LV2 plugin UIs.
Suil makes it possible to load a UI of a toolkit in a host using another
toolkit.  The API is designed such that hosts do not need to explicitly
support specific toolkits – if Suil supports a particular toolkit, then UIs in
that toolkit will work in all hosts that use Suil automatically.
Suil currently supports every combination of Gtk 2, Qt 4, and X11.")

It is currently used by ardour and jalv, both of which seem to use gtk+-2
and not qt-4.

The suil package itself, however, depends on gtk+-2 _and_ qt-4.

Do you think we could drop the qt-4 input?

If at some point in time suil also works with qt-5, we might be better
served by creating two packages, suil-gtk and suil-qt, with only one of
the respective inputs; I find it unlikely that an application would need
both of gtk+ and qt.

Andreas

Re: Staying on top of Qt security

[Andreas Enge]

On Thu, Feb 25, 2016 at 09:35:45AM +0100, Andreas Enge wrote:
> I find it unlikely that an application would need both of gtk+ and qt.

Maybe I am wrong; jalv does depend on both... It creates binaries jalv.gtk
and jalv.qt. If nobody uses the qt version, we could remove the input qt-4.

Andreas

Re: Staying on top of Qt security

[Andreas Enge]

Probably we can:
"jalv.qt (...) This is a versionm of Jalv with a GUI implemented in Qt.
It is mainly for developer testing purposes, for a production ready program
use jalv.gtk."

Andreas

Re: Staying on top of Qt security

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> Probably we can:
> "jalv.qt (...) This is a versionm of Jalv with a GUI implemented in Qt.
> It is mainly for developer testing purposes, for a production ready program
> use jalv.gtk."

I agree.

Re: Staying on top of Qt security

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> looking at why ardour depends on qt-4, I came across suil:
>     (description
>      "Suil is a lightweight C library for loading and wrapping LV2 plugin UIs.
> Suil makes it possible to load a UI of a toolkit in a host using another
> toolkit.  The API is designed such that hosts do not need to explicitly
> support specific toolkits – if Suil supports a particular toolkit, then UIs in
> that toolkit will work in all hosts that use Suil automatically.
> Suil currently supports every combination of Gtk 2, Qt 4, and X11.")
>
> It is currently used by ardour and jalv, both of which seem to use gtk+-2
> and not qt-4.
>
> The suil package itself, however, depends on gtk+-2 _and_ qt-4.
>
> Do you think we could drop the qt-4 input?
>
> If at some point in time suil also works with qt-5, we might be better
> served by creating two packages, suil-gtk and suil-qt, with only one of
> the respective inputs; I find it unlikely that an application would need
> both of gtk+ and qt.

We cannot know what toolkit the GUI of audio plugins will use.  Suil
supports the three most popular ones so plugin authors providing GUIs
don’t need to worry about support in popular hosts such as Ardour.

~~ Ricardo

Re: Staying on top of Qt security

[Andreas Enge]

On Thu, Feb 25, 2016 at 10:38:32AM +0100, Ricardo Wurmus wrote:
> > The suil package itself, however, depends on gtk+-2 _and_ qt-4.
> > Do you think we could drop the qt-4 input?
> We cannot know what toolkit the GUI of audio plugins will use.  Suil
> supports the three most popular ones so plugin authors providing GUIs
> don’t need to worry about support in popular hosts such as Ardour.

So you would keep the dependency on qt? What is annoying is that right now,
this must be qt-4. The library had its last release in August 2014, but
I see the following svn commit:
r5725 | drobilla | 2015-09-12 18:02:02 +0200 (Sa, 12 Sep 2015) | 1 line
Add Gtk2 and X11 in Qt5 wrappers.

Should we try to package an svn checkout? And convince the author to make
a new release?

If someone wants to beat me to it, I would not refuse :-)

Andreas

Re: Staying on top of Qt security

[Andreas Enge]

On Thu, Feb 25, 2016 at 10:06:42AM +0100, Andreas Enge wrote:
> Probably we can:
> "jalv.qt (...) This is a versionm of Jalv with a GUI implemented in Qt.
> It is mainly for developer testing purposes, for a production ready program
> use jalv.gtk."

Qt-4 support dropped in commit 03d55ee.

This does not have much impact, however, since there is still a dependency
on suil, which depends on qt-4.

So the question still stands:
On Thu, Feb 25, 2016 at 09:22:29PM +0100, Andreas Enge wrote:
> On Thu, Feb 25, 2016 at 10:38:32AM +0100, Ricardo Wurmus wrote:
> > We cannot know what toolkit the GUI of audio plugins will use.  Suil
> > supports the three most popular ones so plugin authors providing GUIs
> > don’t need to worry about support in popular hosts such as Ardour.
> So you would keep the dependency on qt? What is annoying is that right now,
> this must be qt-4. The library had its last release in August 2014, but
> I see the following svn commit:
> r5725 | drobilla | 2015-09-12 18:02:02 +0200 (Sa, 12 Sep 2015) | 1 line
> Add Gtk2 and X11 in Qt5 wrappers.
>
> Should we try to package an svn checkout? And convince the author to make
> a new release?

Andreas

Re: Staying on top of Qt security

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> On Thu, Feb 25, 2016 at 10:06:42AM +0100, Andreas Enge wrote:
>> Probably we can:
>> "jalv.qt (...) This is a versionm of Jalv with a GUI implemented in Qt.
>> It is mainly for developer testing purposes, for a production ready program
>> use jalv.gtk."
>
> Qt-4 support dropped in commit 03d55ee.
>
> This does not have much impact, however, since there is still a dependency
> on suil, which depends on qt-4.
>
> So the question still stands:
> On Thu, Feb 25, 2016 at 09:22:29PM +0100, Andreas Enge wrote:
>> On Thu, Feb 25, 2016 at 10:38:32AM +0100, Ricardo Wurmus wrote:
>> > We cannot know what toolkit the GUI of audio plugins will use.  Suil
>> > supports the three most popular ones so plugin authors providing GUIs
>> > don’t need to worry about support in popular hosts such as Ardour.
>> So you would keep the dependency on qt? What is annoying is that right now,
>> this must be qt-4. The library had its last release in August 2014, but
>> I see the following svn commit:
>> r5725 | drobilla | 2015-09-12 18:02:02 +0200 (Sa, 12 Sep 2015) | 1 line
>> Add Gtk2 and X11 in Qt5 wrappers.
>>
>> Should we try to package an svn checkout? And convince the author to make
>> a new release?

We could ask drobilla for a new suil release.  I don’t think we should
package the development version as it’s not clear if dependent
applications would work with the latest suil.

~~ Ricardo

Re: Staying on top of Qt security

[Andreas Enge]

On Sat, Mar 05, 2016 at 10:16:05PM +0100, Ricardo Wurmus wrote:
> We could ask drobilla for a new suil release.  I don’t think we should
> package the development version as it’s not clear if dependent
> applications would work with the latest suil.

Sounds good. Would you like to do it, since you are clearly the expert?

Andreas

Re: Staying on top of Qt security

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> On Sat, Mar 05, 2016 at 10:16:05PM +0100, Ricardo Wurmus wrote:
>> We could ask drobilla for a new suil release.  I don’t think we should
>> package the development version as it’s not clear if dependent
>> applications would work with the latest suil.
>
> Sounds good. Would you like to do it, since you are clearly the expert?

I just checked some packaging information for Suil.  Maybe we should
just split it into different packages:

    The purpose of Suil is to abstract plugin UI toolkits away from host
    code.  To achieve this, Suil performs its magic by dynamically
    loading modules for each toolkit.  The main Suil library does NOT
    depend on any toolkit libraries, and thus neither should your
    package.  Please package the individual modules
    (e.g. libsuil_gtk2_in_qt4.so) as separate packages, which themselves
    depend on the involved toolkits.  These packages should also be
    versioned as described above to support parallel installation.

    Please do not make the main Suil package depend on any toolkit
    package, this defeats the purpose of Suil and will severely irritate
    those who for whatever reason do not want a particular toolkit
    dependency.  The main Suil package may have a weak dependency
    (e.g. "recommends") on the individual wrapper modules, and it's fine
    if these are installed by default, but it must be possible to
    install Suil without installing them if the user explicitly wishes
    to do so.

    [http://svn.drobilla.net/lad/trunk/suil/PACKAGING]

How about we do just that?  Maybe we’ll find that the qt4 backend is not
needed by any other package at all.

~~ Ricardo