[Interest] Qt 5.6LTS vs 5.7+

[André Pönitz]

On Sun, Sep 04, 2016 at 07:38:18PM +0000, Tuukka Turunen wrote:
> > -----Original Message----- From: Interest
> > [mailto:interest-bounces+tuukka.turunen=qt.io at qt- project.org] On
> > Behalf Of Roland Hughes Sent: sunnuntaina 4. syyskuuta 2016 21.14 To:
> > 2202873.hgKzyLeXCm at patux.local; Interests Qt <interest at qt- project.org>
> > Subject: Re: [Interest] Qt 5.6LTS vs 5.7+
> > 
> > 
> > >Qt 5.6 is for those who cannot upgrade. If you can upgrade, upgrade.
> > 
> > >>How (un)likely is it that one can remain locked into 5.6 because of
> > >>dependent code that doesn't build against 5.7+? Qt's backward
> > >>compatibility principle should prevent that, no?
> > 
> > It is extremely likely for development to remain locked to a version.
> 
> This is absolutely true. But what does it mean to keep using an outdated
> version in a connected system? How to ensure that the system remains
> secure?

Being connected is the #1 security problem of recent technical systems, and
given the plethora of parties of widely varying interests in the typical
operation of connected systems up to parties with a specific interest in
*insecure* operation of such systems this is unlikely to change.

So I am not really convinced that there is a question about *remaining*
secure in a connected context, and rather accept as first approximation
that a connected system is insecure by design and intent, and that making a
system connected is a conscious business choice of the vendor trading the
pros and cons of having the system connected against the pros and cons of
making the system secure.

Building and updating connected *and* secure applications and devices is
pretty much a science (and business...) of its own. Unfortunately, lots of
folks whose applications and devices happened to be not exploited in the
past (mainly because they had not been connected and nobody bothered to
walk up to the the places of installation and physically break into) think
they can just connect (that's easy), make extra $$$ (possible), and nothing
else changes (no chance). 

There is obviously due diligence involved on all levels, but beyond that I
think a consciously chosen "difficult" setup is mainly the problem of the
application vendor, libraries can focus on issues that are clearly on there
side, in this case security, not update.

Andre'