[Development] Proposing QUIP-23: Qt-Security header in source code files

[Volker Hilsheimer]

> On 11 Jul 2024, at 13:26, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
> 
> 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,


This is primarily about code that deals with untrusted input, yes.


I can think of two aspects where it would be useful to express the impact a bug in code might have:

* for ourselves, as described: changes to code that is by design exposed to untrusted data should come with some extra scrutiny.


This could be triggering relevant fuzz-tests, static analyser runs, or just flagging the respective review in gerrit.


* for our users: can we document what users can expect from Qt when exposing our code to untrusted input?

Think about the shared responsibility model in AWS [1]

[1] https://aws.amazon.com/compliance/shared-responsibility-model/

Making a Qt application secure is a shared responsibility between us and the application developer, even if the division won’t be nearly as simple. The question is the same: what are our responsibilities, what guarantees do we make; and what responsibilities does the application developer have?

For many APIs, application code provides the data (perhaps indirectly), e.g. to QDateTime::fromString. In that case we can assume that the application had at least some chance to scrub the input, or at the very least control where that string comes from (perhaps a file on disk). For other APIs, Qt processes the data without the application seeing it (eg. network protocol, loading an image etc from file).

To document the respective expectations and responsibilities on a higher level, we need start with understanding and documenting what the code does. The header helps us with that, and at the same time enables some degree of automation.


Volker