On Sat, Apr 23, 2022 at 03:49:32PM +0300, Joonas Niilola wrote: > 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?
No, I don't think so. But currently the one who is expected to act on a bug is only discernable via whiteboard, which is somewhat unique in security bugs. Removing some of that 'magic' would seem to be a good thing in any case. > > > > 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. Right, because there's not a trivial way to identify who needs to do something for a security bug. Under this new scheme, a bug would only be under a maintainer's security bug tab if they were assigned (i.e., the package needs a bump), and then removed when security@ is assigned. > > > > 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... I didn't think it was that invasive or disruptive of a 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. I don't think this is really relevant to my proposal. If we decide to implement this and people get it wrong, oh well. The situation will still gradually get better. > -- juippis
signature.asc
Description: PGP signature
