[Development] QtCS 2018: Third-party and security policy

[Thiago Macieira]

There's a session scheduled for Monday (unless it gets moved). Here's what I 
will propose.

0) Where not really necessary, delete the third-party code and force the use 
of a system library (see assimp discussion, can be applied to qtimageformats 
too).

1) Third-party bundled should be opt-in, not opt-out. That is, the system 
library always takes precedence, if found.

2) Qt Project sources always ship the latest third-party sources available one 
week before the Qt release. The grace period is just so that we can release 
the RC that passed QA. Every feature release receives updates to the latest 
and greatest upstream; every patch release receives updates in the same patch-
series by upstream, if such exists. Release Management will put this as a P1 
requirement for the release, like the changelog, header check, BC check, etc.

3) Qt Project sources receive a patch for a security fix in a library that 
cannot be built as a system library. That's the case of the bundled FreeBSD 
sources or TinyCBOR or right now with Qt Creator's sqlite. We do this within 
one week of the fix, even if it is high Summer in Finland. All releases after 
this point will contain the patched version.

4) No patches are necessarily issued for fixes to libraries that can be used 
as system libraries. But all releases from that point on will be patched.

5) Qt Project binaries containing third-party code are re-released every time 
the code has a fix for a CVE that isn't in what we're shipping. We do this 
within one week of the fix, same conditions. Note this applies to the 
"gnuwin32" dir in qt5.git too.

6) Each third-party bundled library must have an official maintainer and one 
deputy who know how to update it and are tracking that library's security 
advisories. They'll both be added to the Qt Security Team. They have to inform 
the Security Team if they are going to be completely unavailable for more than 
a week. If both are going to be unavailable, they need to ensure there's 
someone who is tracking the library.
Corollary: existing code that cannot meet this requirement will be 
deleted from the Qt Project sources.

I know this is harsh, but I think it's necessary. Let's discuss on Monday to 
see if there's any solution I've missed.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> The Qt promise is to maintain not only source code, but upward binary
> compatibility until a major version.
> 
> When said promise is broken immediately after a major version release, as it
> was the case just after Qt5 release to fix an oversight, this is not harmful.
> 
> When it happens years after release, and this is indeed the case here for
> deprecated modules, and was also the case with the switch away from Webkit,
> it can be a major problem not just for distributions, but for many projects 
> that
> depend on it and did not budget a major change.

Overall I do think we're on the very conservative side when it comes to 
removing things. We're still dragging modules along that were deprecated in Qt 
5.0 already ... Qt WebKit was somewhat special in that a) it was quite big, and 
b) it's often used in a security critical setup. But eventually Konstantin 
volunteered to revive qtwebkit, so I guess it's ok now?

> To maintain source and binary compatibility, deprecated modules should not
> be removed until QT6. I do not even understand why there is a debate about
> this.

Note that the case in question is about deprecated functionality in the build 
system, not about removing any Qt modules. So the BC guarantee doesn't apply 
here. 

Kai

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[Thiago Macieira]

On Friday, 8 June 2018 07:59:10 PDT Kevin Funk wrote:
> I would lean towards restoring qt5_use_modules() in Qt 5.11.1 (and keep it
> for the Qt5 lifetime). But I'd leave the other removals of
> 02ed1b36daebed5f3997bb676cf5e818c0db9d3c (mainly removal of support of older
> CMake versions) intact.
> 
> Agreed? If so I'll file a patch soon-ish.

I think it makes sense. This doesn't look like a simple change.

The missing #includes is a known issue and even then I looked at what caused 
the issue for QButtonGroup and QAction. I can't find the relevant change.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[Kevin Funk]

On Thursday, 7 June 2018 08:03:40 CEST Thiago Macieira wrote:
> Commit 02ed1b36daebed5f3997bb676cf5e818c0db9d3c was
> 
> Remove CMake code for CMake < 3.1
> 
> This removes the following functions from Qt5CoreMacros:
> - qt5_use_modules(...)
> 
> Which follows 2013's d9ea4bb1441534cfb9253303ac258951dfcc4d9e
> 
> Mark qt5_use_modules as obsolete.
> 
> Forward-port of cb7f32f5b861fe115fa71f64500a5cbb0b643f1b (Mark
> qt4_use_modules and qt4_automoc as obsolete., 2013-07-04) from
> cmake.git.
> 
> But it appears that in the 5 years since we deprecated it, people have not
> stopped using it. Did we have to remove it? Or should we have kept
> compatibility until Qt 6?

Heya Thiago,

thanks for bringing this up on the mailing list. I have authored the patch 
which (also) removed qt5_use_modules(). To my excuse, I haven't expected that 
so many projects still use said macro actively. I was maybe misguided by my 
perception from the KDE world; where most projects have used to using 
target_link_libraries(...).

I understand that the removal of qt5_use_modules() creates tons of unnecessary 
extra work for distro and project maintainers.

I would lean towards restoring qt5_use_modules() in Qt 5.11.1 (and keep it for 
the Qt5 lifetime). But I'd leave the other removals of 
02ed1b36daebed5f3997bb676cf5e818c0db9d3c (mainly removal of support of older 
CMake versions) intact.

Agreed? If so I'll file a patch soon-ish.


PS: Regarding the motivation for such changes:
  
Obviously I don't want to make other ppl's life more difficult -- but the 
CMake support in Qt5 has grown tons of fallback or compat code over the years 
which makes it very hard to improve it. We ideally should try to get rid off 
this in order to move forward. CMake has learned a lot throughout the years 
but in Qt's CMake support code there were and still are lots of places where 
we try to mimic what CMake supports out of the box since years.

Regards,
Kevin

> Just look at the failures in
> https://build.opensuse.org/project/monitor/openSUSE:Factory?
> arch_x86_64=1&defaults=0&failed=1&repo_standard=1
> 
> The majority of them are caused by the Qt 5.11 update, a great number of
> which are the cmake update (the rest are indirect header dependency and are
> easy to fix).


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite

[Marco Bubke]

The Sqlite module is not a plugin but a library. It is linked to a plugin but 
this plugin is not build in release and normally disabled.
Like I said, it can be simply not build for release. Please stick to KISS.

On June 8, 2018 16:30:19 Edward Welbourne  wrote:

> Marco Bubke (7 June 2018 19:37) wrote:
>> AFAIK the refactoring plugin is disabled for release. Just do the same for 
>> the Sqlite library.
>
> Probably better to do as Thiago said:
>
> On June 7, 2018 23:54:43 Thiago Macieira  wrote:
>>> So we just need a conditional to disable the building if the refactoring
>>> plugin isn't enabled either.
>
> or, perhaps more to the point, only enable building of the sqlite plugin
> if (it's explicitly wanted or) something that needs it is enabled,
>
> Eddy.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[qt . dantec]

Le Wed, 06 Jun 2018 23:03:40 -0700, Thiago Macieira
  écrivait:

>But it appears that in the 5 years since we deprecated it, people have not 
>stopped using it. Did we have to remove it? Or should we have kept 
>compatibility until Qt 6?

The Qt promise is to maintain not only source code, but upward binary
compatibility until a major version.

When said promise is broken immediately after a major version release,
as it was the case just after Qt5 release to fix an oversight, this is
not harmful.

When it happens years after release, and this is indeed the case here
for deprecated modules, and was also the case with the switch away
from Webkit, it can be a major problem not just for distributions, but
for many projects that depend on it and did not budget a major change.

To maintain source and binary compatibility, deprecated modules should
not be removed until QT6. I do not even understand why there is a
debate about this.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Maintainers, your action needed: Qt 5.11.1 changes files

[Jani Heikkinen]

Hi,

Initial ones here: 
https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.11.1%22,n,z

Please do needed updates & get approval as soon as possible; We need to get 
these in soon to be able to keep our release schedule (final packages next 
week, release 19.6.2018)

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite

[Edward Welbourne]

Marco Bubke (7 June 2018 19:37) wrote:
> AFAIK the refactoring plugin is disabled for release. Just do the same for 
> the Sqlite library.

Probably better to do as Thiago said:

On June 7, 2018 23:54:43 Thiago Macieira  wrote:
>> So we just need a conditional to disable the building if the refactoring
>> plugin isn't enabled either.

or, perhaps more to the point, only enable building of the sqlite plugin
if (it's explicitly wanted or) something that needs it is enabled,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Do we really need Assimp?

[Mike Krus]

Hi

Using system assimp is probably the best scenario indeed. Except I think users 
would expect install packages to have that enabled so ideally assimp should be 
installed on CI systems.

Mike

> On 7 Jun 2018, at 17:24, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> El jueves, 7 de junio de 2018 13:03:43 -03 Thiago Macieira escribió:
>> On Thursday, 7 June 2018 04:31:13 PDT Sean Harmer wrote:
>>> Another option is to only rely upon a system installed assimp and build
>>> these tools only if found at configure time. In fact, that's probably
>>> easiest and best. Then we can remove assimp from the source. It means
>>> users woudl need to build these tools/plugins themselves (typically on
>>> macOS/Windows) but at least they would be easily available.
>>> 
>>> Would that be acceptable to the project?
>> 
>> How often is the tool used and how needed is the plugin? Asked differently,
>> if most users didn't have access to them, would they notice?
> 
> In Debian we dropped it for some time due to some factor I can't remember 
> now. 
> After a couple of months we've got one user asking for it.
> 
> I think had it been a very used component we would have received bugs more 
> promptly.
> 
> We are currently using system assimp [log], so I guess that if this route is 
> decided upon then it should not be too complicated to accomplish.
> 
> [log] 
> 
> 
> 
> -- 
> 9: Que es el "Explorador" de Windows
>* El tipo que le roba las ideas a MacOs
>Damian Nadales
>http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html
> 
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908   Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts



smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development