Re: [gentoo-dev] [RFC] Security Bug Assignment Change

[John Helmert III]

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