On 15.4.2022 4.38, John Helmert III wrote: > 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.
Is there a specific group that has this problem? E.g. inactive developers, proxied maintainers, (dead) projects? Like is this actually a wide-spread problem? > > 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. p.g.o already has a "security" tab for maintainers, but the bug listing is pretty ineffective already as-is. > > 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 I don't mind either way as long as it's really fixing a problem. Just got familiar with the new workflow after most recent change... Anyway hope things have gotten better since sending this e-mail, but I fear (assume) people who had these problems aren't actively reading the mailing list either. -- juippis
OpenPGP_signature
Description: OpenPGP digital signature
