QtCS25 - Qt & Cybersecurity: Difference between revisions
(→Notes) |
No edit summary |
||
| Line 2: | Line 2: | ||
''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.'' | ''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== | ==Session Owners== | ||
'' | ''Kai Köhne'' | ||
'' | ''Alexandru Croitor'' - notes | ||
==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. | |||
One conclusion: mark all files in library code, but not examples or tests, | |||
Tooling could scan the markers, to warn on creation | 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 | 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 | Should we move critical functions outside of files into critical files, when most other functions are normal? | ||
General consensus yet. | |||
But the file granularity stays, not at function level. | |||
[[Category:QtCS2025]] | [[Category:QtCS2025]] | ||
Revision as of 14:23, 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 yet. But the file granularity stays, not at function level.