On Fri, Jan 20, 2023 at 04:47:05PM +0000, Gary Buhrmaster wrote:
On Fri, Jan 20, 2023 at 3:48 PM Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> I think in practical terms that makes sense but our tools don't really help.
I agree, and that seems to be an artifact of
the single Fedora component in RHBZ, which
treats Fedora as one thing.
I supposed (in theory again) that there could
be a master bugzilla for the CVE which depends
on child bugzillas for each impacted Fedora
release, and would get (auto) closed only when
all the child bugzillas are resolved (either by
updates or the Fedora release aging out).
Alternatively, an entirely different bugzilla for
each Fedora release (but as Fedora is just
a single component, unlike each RHEL
which has different components for each
version, I don't think that works).
I think that sort of thing indeed reflects reality better, but at the
cost of much more complexity. Maintainers already dislike the amount of
bugs to deal with, having tons more doesn't sound too appealing... at
least to me.
> So I guess what I'm asking is if there is a specific policy
around this? If not, should there be?
I think there should be at least an agreed
upon best practice, which needs to be
explicitly documented somewhere (maybe
it is, but I don't recall seeing it, so I am
not following it).
I'm not sure we can have any specific policy.
CVE's are all over the map. Sure we have priorities and 'scores' but
even then, they often are not quite right or don't apply the same way to
the way Fedora has packaged the software.
I think we can perhaps have a 'rule of thumb'/SHOULD type of advice:
* If it's high or critical, do consider updating stable releases if you
can.
* If you decide not to update stable releases, please add a comment to
the bug noting that and close it.
So, as with much of Fedora, we fall back
to depending on (usually volunteer)
packagers to do the right thing (which works
out well most of the time because packagers
such as yourself are contentious about
doing the right thing).
yeah, I think this is just too complex an area for us to have a detailed
policy.
kevin