QtCS25 - Qt & Cybersecurity

Session Summary

The CRA is starting to be a hot topic for a lot of customers. We're trying to use this as a vehicle to actually improve the processes and tools for the Qt Project. Let's discuss where we are, and what are the next steps.

Session Owners

Kai Köhne

Alexandru Croitor - notes

Notes

Qt security score markers in files.

One conclusion: mark all files in library code, but not examples or tests. Mark with insignificant when it is so, so we don't need to question it in the future.

Tooling could scan the markers, to warn on creation of new files without the marker (perhaps from Bots)

Benefit: it's easier to have it in files, than in abandoned gerrit changes, because its close to the files, and abandoned changes are hard to fine

Should we move critical functions outside of files into critical files, when most other functions are normal?

General consensus - yes.

But the file granularity stays, not at function level.

We should have reasoning for insignificant marker as well, to avoid re-discussion in the future.

Discussion about wording about what is and isn't security-relevant (for example about security boundaries of qtsvg).

Is there any feedback on the UI team security reviews in Oslo? Is there anything useful for everyone else to know? Guidelines? Should be in intranet.

Started with a lot of files that were critical, but then reduced the amount, and adjusted the docs, saying that we need to trust the input.

If the protocol is documented as not being security-safe, then the Qt data parser is not security-critical, but we should document that it's because of what the protocol says.