Hi, Let me add a bit of a bigger picture here.
I think we all share the goal of making the Qt Framework and tools as high-quality and robust as possible. We've also been continuously investing in this, be it on the technical side or on the process side. But the world is changing, and the expectations placed upon us, especially regarding security, are growing. Nowadays, users are more than ever expecting Qt to react swiftly to security reports and be proactive in hardening our code base. This is also driven by authorities like the US government and the European Union, which have started to put legislation in place to force the software world to take security more seriously. Unfortunately, that requires also more and more paper trails, some of which are sensible, some not ... Anyhow, I think we need to revisit our processes from the security perspective. Our Open Governance Model [1], for instance, currently doesn't differentiate between different code bases. If you've been promoted to an approver once, you can approve any patch, from documentation changes in Qt WebEngine to the code in Qt Network dealing with TLS. This is very convenient and non-bureaucratic. But there's an obvious danger there that someone, by accident or due to malice, can open up holes in parts he shouldn't really wrestle with. In a similar vein, our code base has been growing over time, with different coding styles being used over the years. Continuous attempts have been made to improve the style and consistency of our code base over time, and we have various automatic checkers running that should help us migrate to a safe style [2]. But we don't use these to our fullest, also because the code base we're talking about is so huge. Finally, on the security mailing list, we often need to assess whether a particular reported bug is security-critical (and should be followed up by CVEs) or not. This is already not trivial for programs; for a framework, it's even harder because we don't know how every single application uses Qt. So, we try to be reasonable. But for me, it's quite clear we haven't really documented well enough how Qt should be used and how not. That's a lot of questions. But a lot comes down to: Can we agree on parts of Qt that are more critical and, therefore, should be subject to additional security (in terms of approvers, coding standards, fuzzing ...)? And can we then document these parts so that this understanding is also available to users? Dimitrios's proposal could be the basis for this by starting on the source level. Let's develop a common vocabulary to talk about the criticality of a file or module so that we can focus our efforts there. The paradigm behind this is that we identify which parts of Qt deal with data from untrusted sources, which is where attackers will always start. Kai PS: If you feel strongly about this, I suggest you register for the Qt CS 2025, where I hope for quite some lively discussions around this: https://www.qt.io/blog/qtcs24-sep-5-6-save-the-date [1]: Qt Governance Model: https://contribute.qt-project.org/quips/2 [2]: Test Results of various static analysis tools: https://testresults.qt.io/ ________________________________ From: Development <development-boun...@qt-project.org> on behalf of Dimitrios Apostolou via Development <development@qt-project.org> Sent: Wednesday, July 10, 2024 1:06 To: development@qt-project.org <development@qt-project.org> Subject: [Development] Proposing QUIP-23: Qt-Security header in source code files Hello list, on behalf of the Qt Company, I would like to propose a new single-line comment header for the Qt source code. The syntax is: // Qt-Security score:N reason:some-reason [labels:label1,label2] The idea is to mark files with code where bugs are more likely to cause security issues. For example code that is usually parsing input from untrusted sources, or a protocol implementation. For now we only plan to mark selected files with score 2, which vaguely translates to "contains security critical code". Here is an example use: // Qt-Security score:2 reason:data-parser The purpose is to leverage this information in our codereview system and enforce special handling of such files, for example extra scrutiny in the review process, more rigorous testing etc. Please read the QUIP at [1] and a first use of this header at [2]. [1] https://codereview.qt-project.org/c/meta/quips/+/575276 [2] https://codereview.qt-project.org/c/qt/qtbase/+/568279 All feedback is welcome, here or on the QUIP review. Regards, Dimitrios Apostolou -- 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
