| 1 |
On 15.4.2022 4.38, John Helmert III wrote: |
| 2 |
> Hi all! Currently all security bugs are assigned to security@g.o, |
| 3 |
> always. This can easily lead to some confusion about who needs to do |
| 4 |
> something about a given bug; right now this is generally tracked by |
| 5 |
> whiteboard magic strings that probably not many people outside of the |
| 6 |
> Security Project understand [1] and this has been a source of |
| 7 |
> confusion around security bugs for a long time. |
| 8 |
|
| 9 |
Is there a specific group that has this problem? E.g. inactive |
| 10 |
developers, proxied maintainers, (dead) projects? Like is this actually |
| 11 |
a wide-spread problem? |
| 12 |
|
| 13 |
> |
| 14 |
> To make it abundantly clear who needs to take action for a given bug, |
| 15 |
> I propose we move away from the dogma of security@ always being |
| 16 |
> assigned to security bugs, and instead assign bugs to whoever needs to |
| 17 |
> take action for the bug. For example, on security bugs that need a |
| 18 |
> package bumped or cleaned up, the package maintainer would be |
| 19 |
> assigned. For bugs needing a GLSA, security@ would be assigned. |
| 20 |
> |
| 21 |
> As a nice side effect, this would be a step towards making security |
| 22 |
> bug state discernable outside of the human-maintained and oft-stale |
| 23 |
> whiteboard. In the long term, a maintainer's security bugs could be |
| 24 |
> more easily tracked via things like packages.g.o. |
| 25 |
|
| 26 |
p.g.o already has a "security" tab for maintainers, but the bug listing |
| 27 |
is pretty ineffective already as-is. |
| 28 |
|
| 29 |
> |
| 30 |
> As far as bug handling goes, I see two obvious (though rathor minor) |
| 31 |
> sticky points: |
| 32 |
> |
| 33 |
> - Who do we assign bugs to when a bug is in stabilization |
| 34 |
> state? The stabilization bug will always be assigned to the |
| 35 |
> maintainer, but the security bug will be neither actionable by the |
| 36 |
> maintainer nor security@ until the stabilization is finished. |
| 37 |
> |
| 38 |
> - Rarely, we have a security bug that affects multiple packages with |
| 39 |
> different maintainers (e.g. a package and its -bin variant). Under |
| 40 |
> this scheme, we would have to always separate bugs by package |
| 41 |
> maintainer. |
| 42 |
> |
| 43 |
> I'm not proposing any change to the Bugzilla product or component, so |
| 44 |
> security bugs will still be able to be exhaustively enumerated this |
| 45 |
> way, but any tooling that relies on security bugs always being |
| 46 |
> assigned to security@ would have to be changed. |
| 47 |
> |
| 48 |
> What do you all think? |
| 49 |
> |
| 50 |
> [1] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html "Severity Level" section |
| 51 |
|
| 52 |
I don't mind either way as long as it's really fixing a problem. Just |
| 53 |
got familiar with the new workflow after most recent change... |
| 54 |
|
| 55 |
Anyway hope things have gotten better since sending this e-mail, but I |
| 56 |
fear (assume) people who had these problems aren't actively reading the |
| 57 |
mailing list either. |
| 58 |
|
| 59 |
-- juippis |
Archives