QtCS25 - Qt & Cybersecurity: Difference between revisions
No edit summary |
No edit summary |
||
Line 20: | Line 20: | ||
Should we move critical functions outside of files into critical files, when most other functions are normal? | Should we move critical functions outside of files into critical files, when most other functions are normal? | ||
General consensus | |||
General consensus - yes. | |||
But the file granularity stays, not at function level. | 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). | |||
[[Category:QtCS2025]] | [[Category:QtCS2025]] |
Revision as of 14:24, 8 May 2025
Session Summary
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.
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).