[Development] QtCS 2018: Third-party and security policy
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] QtCS 2018: Third-party and security policy
On June 9, 2018 04:10:58 Thiago Macieira 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
Re: [Development] QtCS 2018: Third-party and security policy
On Saturday, 9 June 2018 16:38:46 IST EXT Marco Bubke wrote: > 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? We'll talk about it on Monday, as this is also the case for TinyCBOR. I designed it so it would be #include'd in other sources. > > 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. Good points for discussion. I'll forego giving my comments now. -- 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] QtCS 2018: Third-party and security policy
Hi Thiago, thanks for starting these conversations on the mailing list. I'll miss this QtCS, so this is great for me and for whomever else won't be able to attend. Il 08/06/2018 22:10, Thiago Macieira ha scritto: 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). What's the definition of "necessary" here? We're having several variations of 3rd party code (list probably not complete): * code that got "extracted" from upstream libraries (e.g. strtoll-like functions from FreeBSD), and most importantly doesn't exist in a suitably packaged format; * libraries that received heavy modifications by Qt (this used to be the case for harfbuzz-ng, not sure if it's still like that) and thus, the upstream version simply isn't usable as-is (we might even say that there isn't an upstream version); * libraries that are usable from upstream, but of which we require a version so recent that it's not included in major distributions (e.g. this used to be the case for PCRE2, it's probably still the case for some XCB code). This opens the can of worms of defining which distributions to include in this definiton (for Linux, I'd include only LTS distributions: latest Debian stable, RHEL latest+latest devtoolset, latest Ubuntu LTS, ...; also, on non-Linux, one has to check things like vcpkg / choco on Windows and homebrew on macOS). * libraries that are usable as-is from upstream and of which there's a reasonably recent version available in major distributions. On an orthogonal level, we also need to classify the usage of our library * we can't build without it * we can build without it, but this would disable this feature of importance X Should we build this sort of matrix? 1) Third-party bundled should be opt-in, not opt-out. That is, the system library always takes precedence, if found. Isn't this already the current behaviour of Qt's configure scripts? 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. One week before the Qt release or one week before the RC? In other words if a library gets an update after the RC is released, and the update isn't related to any security issue, what do we do? 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. This requires a commitment above my powers.. 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. Re-released keeping the same version of Qt? And which binaries are re-released, the ones currently supported (e.g. right now 5.6.latest, 5.9.latest, 5.11.latest)? 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 Mind elaborating why do you think it's necessary? Are we trying to educate Qt users to proper security policies and workflows? Are there business reasons for this (e.g. people not choosing Qt, or Qt getting a bad reputation, etc. because of our lax security policy)? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http:
Re: [Development] QtCS 2018: Third-party and security policy
On Sunday, 10 June 2018 18:17:31 IST Giuseppe D'Angelo wrote: > > 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). > > What's the definition of "necessary" here? We're having several > variations of 3rd party code (list probably not complete): > > * code that got "extracted" from upstream libraries (e.g. strtoll-like > functions from FreeBSD), and most importantly doesn't exist in a > suitably packaged format; That's necessary. > * libraries that received heavy modifications by Qt (this used to be the > case for harfbuzz-ng, not sure if it's still like that) and thus, the > upstream version simply isn't usable as-is (we might even say that there > isn't an upstream version); That's also necessary, but we should strive harder to upstream those changes so we can have an option. > * libraries that are usable from upstream, but of which we require a > version so recent that it's not included in major distributions (e.g. > this used to be the case for PCRE2, it's probably still the case for > some XCB code). Those two are necessary. But as a counter example, libdouble-conversion was needed at a recent version, but could be disabled, if certain other system functions were present. Unfortunately, they're not on Linux. > This opens the can of worms of defining which distributions to include > in this definiton (for Linux, I'd include only LTS distributions: latest > Debian stable, RHEL latest+latest devtoolset, latest Ubuntu LTS, ...; > also, on non-Linux, one has to check things like vcpkg / choco on > Windows and homebrew on macOS). Right, those are points for consideration. > On an orthogonal level, we also need to classify the usage of our library > > * we can't build without it > * we can build without it, but this would disable this feature of > importance X That's my point above. If we can't build without it, then it's necessary. If we can build without it, we could disable it. For example, we can build without XCB. Do we want to? On the other hand, which distribution doesn't have it? > Should we build this sort of matrix? > > > 1) Third-party bundled should be opt-in, not opt-out. That is, the system > > library always takes precedence, if found. > > Isn't this already the current behaviour of Qt's configure scripts? No. > > 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. > One week before the Qt release or one week before the RC? In other words > if a library gets an update after the RC is released, and the update > isn't related to any security issue, what do we do? One week before release. That is, if there's a new release by upstream the same day we released an RC, then we will need a new RC. If it's updated after the RC is released and the released RC is not going to be rev'ed by other reasons, then we don't update. Regardless of reason why upstream released. They're fixing bugs and not all security-worthy bugfixes are noted as such. > > 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. > > This requires a commitment above my powers.. I know. That's why I am bringing this to QtCS. I am setting the bar high enough so that new maintenance of third-party code is unwelcome enough that people will not do it. Right now, it's too easy to import some code into src/3rdparty and forget about it. We can't have that. > > 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 Read: for a CVE that *is* in what we're shipping. I meant to say that if the particular line of code is not compiled, then we don't need to go through this process. But prove you didn't compile it (such as .c source not listed in SOURCES). This excludes "Qt can't reach that code but it was compiled" because people do crazy things, like calling into those libraries supplied with Qt directly from their code. > > do this within one week of the fix, same conditions. Note this applies to > > the "gnuwin32" dir in qt5.git too. > > Re-released keeping the same version of Qt? And which binaries are > re-released, the ones currently supported (e.g. rig
Re: [Development] QtCS 2018: Third-party and security policy
> On 10. Jun 2018, at 22:48, Thiago Macieira wrote: > > On Sunday, 10 June 2018 18:17:31 IST Giuseppe D'Angelo wrote: >>> 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). >> >> What's the definition of "necessary" here? We're having several >> variations of 3rd party code (list probably not complete): >> >> * code that got "extracted" from upstream libraries (e.g. strtoll-like >> functions from FreeBSD), and most importantly doesn't exist in a >> suitably packaged format; > > That's necessary. > >> * libraries that received heavy modifications by Qt (this used to be the >> case for harfbuzz-ng, not sure if it's still like that) and thus, the >> upstream version simply isn't usable as-is (we might even say that there >> isn't an upstream version); > > That's also necessary, but we should strive harder to upstream those changes > so we can have an option. > >> * libraries that are usable from upstream, but of which we require a >> version so recent that it's not included in major distributions (e.g. >> this used to be the case for PCRE2, it's probably still the case for >> some XCB code). > > Those two are necessary. But as a counter example, libdouble-conversion was > needed at a recent version, but could be disabled, if certain other system > functions were present. Unfortunately, they're not on Linux. > >> This opens the can of worms of defining which distributions to include >> in this definiton (for Linux, I'd include only LTS distributions: latest >> Debian stable, RHEL latest+latest devtoolset, latest Ubuntu LTS, ...; >> also, on non-Linux, one has to check things like vcpkg / choco on >> Windows and homebrew on macOS). > > Right, those are points for consideration. > >> On an orthogonal level, we also need to classify the usage of our library >> >> * we can't build without it >> * we can build without it, but this would disable this feature of >> importance X > > That's my point above. If we can't build without it, then it's necessary. If > we can build without it, we could disable it. > > For example, we can build without XCB. Do we want to? On the other hand, > which > distribution doesn't have it? > >> Should we build this sort of matrix? >> >>> 1) Third-party bundled should be opt-in, not opt-out. That is, the system >>> library always takes precedence, if found. >> >> Isn't this already the current behaviour of Qt's configure scripts? > > No. > >>> 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. >> One week before the Qt release or one week before the RC? In other words >> if a library gets an update after the RC is released, and the update >> isn't related to any security issue, what do we do? > > One week before release. That is, if there's a new release by upstream the > same day we released an RC, then we will need a new RC. If it's updated after > the RC is released and the released RC is not going to be rev'ed by other > reasons, then we don't update. > > Regardless of reason why upstream released. They're fixing bugs And introducing new ones, potentially including security bugs. I think just updating to a new version regardless of reasons is a bad idea. A delay of the release because of an 3rd-party update also has the potential to create a cascading required update effect. Take an example for Qt Creator: If we are about to release Qt Creator with LLVM/Clang 6.0, and LLVM/Clang 6.1 is released, this has good chances to introduce bugs. Aside from that, updating the binaries that we ship is an effort, since they are profile optimized etc etc. If instead LLVM/Clang 7.0 should be released, Qt Creator might not even compile anymore. The probability that some functionality is broken increases even more. After we fix all these issues (it’s 1-2 weeks later now than the original schedule), a new version of sqlite is released. > and not all > security-worthy bugfixes are noted as such. > >>> 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. >> >> This requires a commitment above my powers.. > > I know. That's why I am bringing this to QtCS. > > I am setting the bar high enough so that ne
Re: [Development] QtCS 2018: Third-party and security policy
On Monday, 11 June 2018 10:56:42 CEST EXT Eike Ziller wrote: > If we are about to release Qt Creator with LLVM/Clang 6.0, and LLVM/Clang > 6.1 is released, this has good chances to introduce bugs. Aside from that, > updating the binaries that we ship is an effort, since they are profile > optimized etc etc. If instead LLVM/Clang 7.0 should be released, Qt Creator > might not even compile anymore. The probability that some functionality is > broken increases even more. After we fix all these issues (it’s 1-2 weeks > later now than the original schedule), a new version of sqlite is released. Good point about chasing a moving target. -- 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] QtCS 2018: Third-party and security policy
Hi, I've been creating https://codereview.qt-project.org/#/c/233962/2 to pin down what I assume is consensus so far. This is an update to QUIP-4 (https://quips-qt-io.herokuapp.com/quip-0004.html), which regulates how we handle Third-Party Components in Qt. I also added a paragraph that all newly reported known security vulnerabilities in Third-Party Modules should go through the Qt Project security mailing list. Kai PS: Notes from the session at the Qt Contributor Summit are available at https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security > -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Thiago Macieira > Sent: Monday, June 11, 2018 1:18 PM > To: development@qt-project.org > Subject: Re: [Development] QtCS 2018: Third-party and security policy > > On Monday, 11 June 2018 10:56:42 CEST EXT Eike Ziller wrote: > > If we are about to release Qt Creator with LLVM/Clang 6.0, and > > LLVM/Clang > > 6.1 is released, this has good chances to introduce bugs. Aside from > > that, updating the binaries that we ship is an effort, since they are > > profile optimized etc etc. If instead LLVM/Clang 7.0 should be > > released, Qt Creator might not even compile anymore. The probability > > that some functionality is broken increases even more. After we fix > > all these issues (it’s 1-2 weeks later now than the original schedule), a > > new > version of sqlite is released. > > Good point about chasing a moving target. > > -- > 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
Re: [Development] QtCS 2018: Third-party and security policy
On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: > PS: Notes from the session at the Qt Contributor Summit are available at > https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security Thanks Kai. Do we have a volunteer to trial out vcpkg and explain to the rest of us how it would work for Qt? Will it be invisible to our users and ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. -- 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] QtCS 2018: Third-party and security policy
On 05.07.2018 16:48, Thiago Macieira wrote: On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: PS: Notes from the session at the Qt Contributor Summit are available at https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security Thanks Kai. Do we have a volunteer to trial out vcpkg and explain to the rest of us how it would work for Qt? Will it be invisible to our users and ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ I'm not sure if this is what people had in mind (e.g. installing dependencies during configure), but it works at the moment for what I've tested it for. Mårten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2018: Third-party and security policy
El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: > On 05.07.2018 16:48, Thiago Macieira wrote: > > On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: > >> PS: Notes from the session at the Qt Contributor Summit are available at > >> https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security > > > > Thanks Kai. > > > > Do we have a volunteer to trial out vcpkg and explain to the rest of us > > how it would work for Qt? Will it be invisible to our users and > > ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. > > I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ > > I'm not sure if this is what people had in mind (e.g. installing > dependencies during configure), but it works at the moment for what I've > tested it for. I understand this as: at configure time download 3rdparty code. From a distro's point of view, if the download can be disabled that's a pretty nice thing to have, because it would mean (and please do correct me if I'm wrong) that Qt tarballs will not bundle 3rdparty code. Or will bundle less of it. -- 1: Una computadora sirve: * Para tratar de dominar el mundo, un caso conocido de esto fue el de Skinet 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/ 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] QtCS 2018: Third-party and security policy
On 13.07.2018 16:49, Lisandro Damián Nicanor Pérez Meyer wrote: El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: On 05.07.2018 16:48, Thiago Macieira wrote: On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: PS: Notes from the session at the Qt Contributor Summit are available at https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security Thanks Kai. Do we have a volunteer to trial out vcpkg and explain to the rest of us how it would work for Qt? Will it be invisible to our users and ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ I'm not sure if this is what people had in mind (e.g. installing dependencies during configure), but it works at the moment for what I've tested it for. I understand this as: at configure time download 3rdparty code. That's how the current POC works, but it can/likely will change. And then you could use vcpkg to download your dependencies first and just let configure deal with picking up the libraries (for the most part). Mårten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2018: Third-party and security policy
El viernes, 13 de julio de 2018 11:56:44 -03 Mårten Nordheim escribió: [snip] > > I understand this as: at configure time download 3rdparty code. > > That's how the current POC works, but it can/likely will change. And > then you could use vcpkg to download your dependencies first and just > let configure deal with picking up the libraries (for the most part). Except we can't run vcpkg, that's why I asked if the download/vcpkg use can be disabled. -- A child of five could understand this. Fetch me a child of five. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ 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] QtCS 2018: Third-party and security policy
On 13.07.2018 18:43, Lisandro Damián Nicanor Pérez Meyer wrote: El viernes, 13 de julio de 2018 11:56:44 -03 Mårten Nordheim escribió: [snip] I understand this as: at configure time download 3rdparty code. That's how the current POC works, but it can/likely will change. And then you could use vcpkg to download your dependencies first and just let configure deal with picking up the libraries (for the most part). Except we can't run vcpkg, that's why I asked if the download/vcpkg use can be disabled. Ah, sorry. Yeah, it'll be voluntary to use it Mårten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2018: Third-party and security policy
El viernes, 13 de julio de 2018 14:55:59 -03 Mårten Nordheim escribió: > On 13.07.2018 18:43, Lisandro Damián Nicanor Pérez Meyer wrote: > > El viernes, 13 de julio de 2018 11:56:44 -03 Mårten Nordheim escribió: > > [snip] > > > >>> I understand this as: at configure time download 3rdparty code. > >> > >> That's how the current POC works, but it can/likely will change. And > >> then you could use vcpkg to download your dependencies first and just > >> let configure deal with picking up the libraries (for the most part). > > > > Except we can't run vcpkg, that's why I asked if the download/vcpkg use > > can be disabled. > > Ah, sorry. Yeah, it'll be voluntary to use it That sounds just great :-) -- Mi experiencia me dice que lo que la gente quiere y necesita -en Indonesia, en Turquía, en Italia, en los Estados Unidos, en Brasil, en la Argentina o donde sea- es básicamente lo mismo. La gente quiere comida en la mesa, una vivienda básica, un gobierno que funcione, que en las fuerzas de seguridad haya personas confiables, a las que no tengan que tenerles miedo, educación y salud. ¡La gente de todo el mundo quiere lo mismo! Padre Thomas Michel, jesuita, especialista en diálogo interreligioso, en una entrevista de Elisabetta Piqué para La Nación, 27/09/2006. http://www.lanacion.com.ar/844069 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ 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] QtCS 2018: Third-party and security policy
13.07.2018, 17:57, "Mårten Nordheim" : > On 13.07.2018 16:49, Lisandro Damián Nicanor Pérez Meyer wrote: >> El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: >>> On 05.07.2018 16:48, Thiago Macieira wrote: On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: > PS: Notes from the session at the Qt Contributor Summit are available at > https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security Thanks Kai. Do we have a volunteer to trial out vcpkg and explain to the rest of us how it would work for Qt? Will it be invisible to our users and ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. >>> >>> I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ >>> >>> I'm not sure if this is what people had in mind (e.g. installing >>> dependencies during configure), but it works at the moment for what I've >>> tested it for. >> >> I understand this as: at configure time download 3rdparty code. > > That's how the current POC works, but it can/likely will change. And > then you could use vcpkg to download your dependencies first and just > let configure deal with picking up the libraries (for the most part). Is it possible to use it for MinGW? -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2018: Third-party and security policy
Hi, It’s possible to develop apps with mingw against a vcpkg build. The vcpkg packages themselves cannot be built with mingw yet. I think that is a missing feature. Simon > On 16. Jul 2018, at 18:29, Konstantin Tokarev wrote: > > > > 13.07.2018, 17:57, "Mårten Nordheim" : >>> On 13.07.2018 16:49, Lisandro Damián Nicanor Pérez Meyer wrote: >>> El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: On 05.07.2018 16:48, Thiago Macieira wrote: > On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: >> PS: Notes from the session at the Qt Contributor Summit are available at >> https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security > > Thanks Kai. > > Do we have a volunteer to trial out vcpkg and explain to the rest of us > how it would work for Qt? Will it be invisible to our users and > ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ I'm not sure if this is what people had in mind (e.g. installing dependencies during configure), but it works at the moment for what I've tested it for. >>> >>> I understand this as: at configure time download 3rdparty code. >> >> That's how the current POC works, but it can/likely will change. And >> then you could use vcpkg to download your dependencies first and just >> let configure deal with picking up the libraries (for the most part). > > Is it possible to use it for MinGW? > > -- > Regards, > Konstantin > > ___ > 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
