On 10/07/2024 19:08, Kai Köhne via Development wrote:
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.
I think a necessary prerequisite for this endeavour is to clearly define what kind of concerns are we talking about. Security is a very broad concept. Are we specifically talking about code that deals with untrusted input data?
Thank you, -- 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 - Trusted Software Excellence
smime.p7s
Description: S/MIME Cryptographic Signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
