Hi all! Currently all security bugs are assigned to security@g.o, always. This can easily lead to some confusion about who needs to do something about a given bug; right now this is generally tracked by whiteboard magic strings that probably not many people outside of the Security Project understand [1] and this has been a source of confusion around security bugs for a long time.
To make it abundantly clear who needs to take action for a given bug, I propose we move away from the dogma of security@ always being assigned to security bugs, and instead assign bugs to whoever needs to take action for the bug. For example, on security bugs that need a package bumped or cleaned up, the package maintainer would be assigned. For bugs needing a GLSA, security@ would be assigned. As a nice side effect, this would be a step towards making security bug state discernable outside of the human-maintained and oft-stale whiteboard. In the long term, a maintainer's security bugs could be more easily tracked via things like packages.g.o. As far as bug handling goes, I see two obvious (though rathor minor) sticky points: - Who do we assign bugs to when a bug is in stabilization state? The stabilization bug will always be assigned to the maintainer, but the security bug will be neither actionable by the maintainer nor security@ until the stabilization is finished. - Rarely, we have a security bug that affects multiple packages with different maintainers (e.g. a package and its -bin variant). Under this scheme, we would have to always separate bugs by package maintainer. I'm not proposing any change to the Bugzilla product or component, so security bugs will still be able to be exhaustively enumerated this way, but any tooling that relies on security bugs always being assigned to security@ would have to be changed. What do you all think? [1] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html "Severity Level" section
signature.asc
Description: PGP signature
