Re: [Development] Security-relevant 3rd party components bundled with Qt
> On 7 Oct 2022, at 22:08, Robert Löhning via Development > wrote: > > Am 20.09.22 um 14:47 schrieb Volker Hilsheimer: >> Hi, >> Some of the 3rd party components we bundle in Qt are directly involved in >> code paths that are designed to process untrusted data. Following up on the >> situation with freetype [1] and the discussion we had during summer [2], it >> would help know which of the 3rd party components we bundle today have a >> security relevant surface. All components process data, but many only >> process data that the application developer has full control over (for >> example, we explicitly state that you should not load any untrusted QML code >> or content [3]). Those that are designed to process data from anywhere are >> the ones that are most interesting here. >> Those components should then be watched closer, and always get updated to >> the latest version, perhaps even for patch releases. To that end, I’ve >> started to collect a list of such components on >> https://wiki.qt.io/Third_Party_Code_in_Qt >> and would appreciate if you could have a look and add missing components to >> that page, esp if you are in charge of some of them. I’ve included a column >> that describes what kind of patches we apply when we update the 3rd party >> code (and this is perhaps a good opportunity to see if all of those are >> still necessary). >> In the line of the previous discussion [1], we can then start investigating >> our options for those 3rd party components; for instance, can we build them >> some of them as shared libraries so that they can be easily updated? On >> which platforms are some of them available as system libraries or SDKs, and >> do we test that those work in CI? >> Thanks, >> Volker >> PS: Given the nature of Qt WebEngine, we can probably skip that particular >> repository in this exercise. >> [1] https://lists.qt-project.org/pipermail/development/2022-July/042795.html >> [2] https://lists.qt-project.org/pipermail/development/2022-July/042729.html >> [3] https://doc.qt.io/qt-6/qtqml-documents-networktransparency.html >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > > Hi, > > thank you for this initiative Volker. > > Would it make sense to add a column to that table containing the contact info > of the respective 3rd party component's maintainer(s) and/or bug tracker? > It's awkward to have found an issue and not know whom to tell about it. Sure, add what you think is useful. > By the way: If anybody knows how to reach a maintainer of libtiff, please let > me know. http://www.libtiff.org specifies t...@remotesensing.org as the mailing list address, and names a few individuals. Based on https://www.asmail.be/msg0054916394.html it would seem that you found that already though. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
Sounds like an excellent plan. Ciao Mathias Am 12.10.2022 um 12:35 schrieb Volker Hilsheimer via Development: On 11 Oct 2022, at 22:11, Thiago Macieira wrote: On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development wrote: Speaking as co-maintainer of CMake, we have effectively required #pragma once to build CMake itself since August 2017, we officially codified this as policy in September 2020, and we will soon be writing a clang-tidy plugin to enforce this in our CI. We have not received any complaints about it. Just my $0.02. Thanks for the information. This confirms what we already knew that all systems and compilers where Qt would be compiled do support it. However, neither Qt Creator nor CMake are libraries. They are not comparable. Thanks all for sharing your insights and digging up the previous discussions as well. The summary of all this then seems to be: - ok to use '#pragma once’ in headers that are not designed to be included by Qt users, i.e. in tools, applications, examples and demos, tests - for everything else, in particular for public and, for consistency’s sake - private headers in Qt, we continue to use conventional include guards Rationale: #pragma once is not well enough defined and not part of the standard, and we cannot make any assumptions about how Qt is installed, used as part of a larger SDK etc. So best to stay conservative. If that’s not entirely off, then I’d like to put this into https://wiki.qt.io/Coding_Conventions [1], preempting perhaps a new thread on this topic in a few years. Volker [1]: And since that page seems rather outdated - e.g. we do use dynamic_cast in Qt today, and the suggestion to normalize signals and slots should rather suggest to make connections via PMF syntax - perhaps it’s time to move this to a QUIP where we can discuss and review such changes in gerrit. I won’t have time to do that for a while (perhaps ditto for https://wiki.qt.io/Qt_Coding_Style), but perhaps someone else wants to give this a shot. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
Am 11.10.2022 um 21:20 schrieb Kevin Kofler via Development: "locking you down to a vendor" is a funny argument when the Wikipedia article: https://en.wikipedia.org/wiki/Pragma_once cannot name a single compiler that does not support #pragma once, and 20 that do. Yes, it is supported in a way, that each compiler recognizes this #pragma and does something compiler specific with it, but what exactly a compiler does with it, how each compiler determinates identity is purposefully not listed in that table. Well, and that's exactly the problem: Nobody really can tell, what any compiler does with the pragma and if behavior might change with the next micro patch version. I am pretty sure, absolutely nobody on this list would object the use of #pragma once, if compiler vendors would have documented somewhere, what exactly #pragma once means, what identity means, how it is recognized, how it is to be implemented. If #pragma once would be a well documented and properly implemented industry standard really nobody could object its use, as Qt and its users could rely on the spec and ask tooling and compiler vendors to fix their software if it doesn't match this specification. Still: It isn't. We basically are discussion the use of a feature that's entirely undefined and totally in the void. Doing so is something for religion, not for engineering. Ciao Mathias ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
> On 11 Oct 2022, at 22:11, Thiago Macieira wrote: > > On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development wrote: >> Speaking as co-maintainer of CMake, we have effectively required #pragma >> once to build CMake itself since August 2017, we officially codified >> this as policy in September 2020, and we will soon be writing a >> clang-tidy plugin to enforce this in our CI. We have not received any >> complaints about it. Just my $0.02. > > Thanks for the information. This confirms what we already knew that all > systems > and compilers where Qt would be compiled do support it. > > However, neither Qt Creator nor CMake are libraries. They are not comparable. Thanks all for sharing your insights and digging up the previous discussions as well. The summary of all this then seems to be: - ok to use '#pragma once’ in headers that are not designed to be included by Qt users, i.e. in tools, applications, examples and demos, tests - for everything else, in particular for public and, for consistency’s sake - private headers in Qt, we continue to use conventional include guards Rationale: #pragma once is not well enough defined and not part of the standard, and we cannot make any assumptions about how Qt is installed, used as part of a larger SDK etc. So best to stay conservative. If that’s not entirely off, then I’d like to put this into https://wiki.qt.io/Coding_Conventions [1], preempting perhaps a new thread on this topic in a few years. Volker [1]: And since that page seems rather outdated - e.g. we do use dynamic_cast in Qt today, and the suggestion to normalize signals and slots should rather suggest to make connections via PMF syntax - perhaps it’s time to move this to a QUIP where we can discuss and review such changes in gerrit. I won’t have time to do that for a while (perhaps ditto for https://wiki.qt.io/Qt_Coding_Style), but perhaps someone else wants to give this a shot. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] [Announce] Qt Creator 9 Beta released
2022-10-12
Thread
List for announcements regarding Qt releases and development via Announce via Development
We are happy to announce the release of Qt Creator 9 Beta! https://www.qt.io/blog/qt-creator-9-beta-released -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Announce mailing list annou...@qt-project.org https://lists.qt-project.org/listinfo/announce ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 goodies (was: Using '#pragma once' instead of include guards?)
Henry Skoglund (11 October 2022 22:18) wrote: > Sometime in the far future when Qt requires c++20 things might > improve: we could use std::source_location::filename > (https://en.cppreference.com/w/cpp/utility/source_location/file_name ) Nice. I'm a bit surprised file_name() returns a char* rather than a std::filesystem::path, but it'll do. It's also nice to see source_location has a function_name() that can finally unify the disparate ways of getting that information. More things to look forward to when we eventually get to C++20 ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers
> On 26 Sep 2022, at 09:11, Volker Hilsheimer wrote: > > Hi, > > > I would like to nominate Christian and Andy as co-maintainers for Qt SQL. > > Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t > responded to any of my emails, including one from two weeks ago where I > explicitly informed him that he will be removed as maintainer if he doesn’t > respond (as per the recent addition to the governance model [1], I cc’ed Alex > Blasche as a second maintainer in that email). > > Christian and Andy have already agreed to take on the responsibility > together. they both have a long history of working with the module, and as we > support a number of SQL drivers in Qt it’s good to have more than one person > looking after things. > > > Volker > > [1] https://codereview.qt-project.org/c/meta/quips/+/423766 This change is now in effect at https://wiki.qt.io/Maintainers#Qt_Maintainers Congratulations Christian and Andy, and thanks a lot for stepping up! Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
