On June 9, 2018 04:10:58 Thiago Macieira <thiago.macie...@intel.com> wrote:
> 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. This is really problematic in the Sqlite case as an embedded library. An embedded library is meant to be customized to an application. Actually this whole process looks like it is customized to an server based world and much less to an embedded world. So what about some embedded scenario. What is a system library in that sense. If people ship their own binary it's not part of Qt anymore. So it's their problem but for the user it's still a problem and by a high probability you introduced an out dated library. Would it not be better to ship it as part of Qt in that context to make the life of the embedded developer easier? > 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. That is a security fix? If there is an securifix for Sqlite but this not applicable for Qt Creator, should any action be taken? Actually it is hard to imagine any security related problem in this context. We should follow here a reasonable instead of a fundamental approach. In that sense we should distinguish between different Qt Project software packages. > > 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
