Gentoo Archives: gentoo-dev

From: John Helmert III <ajak@g.o>
To: gentoo-dev@l.g.o
Cc: security@g.o
Subject: [gentoo-dev] [RFC] Security Bug Assignment Change
Date: Fri, 15 Apr 2022 01:38:47
Message-Id: YljMl3bOFG71/
1 Hi all! Currently all security bugs are assigned to security@g.o,
2 always. This can easily lead to some confusion about who needs to do
3 something about a given bug; right now this is generally tracked by
4 whiteboard magic strings that probably not many people outside of the
5 Security Project understand [1] and this has been a source of
6 confusion around security bugs for a long time.
8 To make it abundantly clear who needs to take action for a given bug,
9 I propose we move away from the dogma of security@ always being
10 assigned to security bugs, and instead assign bugs to whoever needs to
11 take action for the bug. For example, on security bugs that need a
12 package bumped or cleaned up, the package maintainer would be
13 assigned. For bugs needing a GLSA, security@ would be assigned.
15 As a nice side effect, this would be a step towards making security
16 bug state discernable outside of the human-maintained and oft-stale
17 whiteboard. In the long term, a maintainer's security bugs could be
18 more easily tracked via things like packages.g.o.
20 As far as bug handling goes, I see two obvious (though rathor minor)
21 sticky points:
23 - Who do we assign bugs to when a bug is in stabilization
24 state? The stabilization bug will always be assigned to the
25 maintainer, but the security bug will be neither actionable by the
26 maintainer nor security@ until the stabilization is finished.
28 - Rarely, we have a security bug that affects multiple packages with
29 different maintainers (e.g. a package and its -bin variant). Under
30 this scheme, we would have to always separate bugs by package
31 maintainer.
33 I'm not proposing any change to the Bugzilla product or component, so
34 security bugs will still be able to be exhaustively enumerated this
35 way, but any tooling that relies on security bugs always being
36 assigned to security@ would have to be changed.
38 What do you all think?
40 [1] "Severity Level" section


File name MIME type
signature.asc application/pgp-signature