Thank you for looking into this matter.
Dne 29. 01. 20 v 22:26 Miro Hrončok napsal(a):
Hello, Fedora has an approved security policy since September 2018
[0]:
> If a CRITICAL or IMPORTANT security issue is currently open
> against a package, or a security issue of lower severity has been
> open for at least 6 months, four weeks before the branch point a
> procedure similar to long-standing FTBFS will be triggered
> immediately, with 8 weeks of weekly notifications to maintainers and
> subsequent orphaning and then subsequent removal from distribution.
> This applies to all packages, not just leaf.
I have decided to have a look into this, since this has been approved
more than a year ago and nothing ever happened since. Fedora has a
very big pile of open CVE bugzillas [2].
I just wonder what is the actual state of these bugs? Which Fedora
versions they apply?
The problem with these trackers is that they are filed against "fedora"
i.e. against all maintained version. If if fix this bug in Rawhide,
should the bug be kept open? Probably. But in what state? The "fixed in"
field would be probably updated by me, but AFAIK, nobody mandates Fedora
maintainers to populate this field.
Vít
There are several things I'd like us to consider based on the
experience from the FTBFS policy adjustments [1] before I go implement
stuff:
A. It's easier to **orphan** packages soon, retire later -- this
allows the dependent package owners to notice the breakage and
possibly adopt the packages themselves if needed while gives very
little room for "cheating".
B. Getting this done on a certain point in the release schedule is
complicated and requires a lot of planning and focus -- if we miss
the window, nothing can change until the next release. We have missed
the window 3 times already.
C. Also because of the fixed date, the CRITICAL or IMPORTANT security
issues have no response time, if you get a new one at a certain point,
the package is immediately treated as problematic, while getting it 1
day later, there is a 6 month period where no action is required.
I'd like to adjust the policy before I go implement some tooling
around this.
This is vague proposal of what I think would work easier for both "the
executioner" and the affected maintainers:
1. We automatically send reminders to NEW security bugzillas (as with
FTBFS)
2. BZs that remain in NEW state for X reminders: pkg is orphaned
3. BZs that remain not CLOSED for Y months: pkg is retired (with
notifications)
Point 2 makes it so that only a couple remaining packages actually
need to survive unfixed to point 3. Hence, point 3 can happen at a
certain point in the schedule with less severe impact of points B and
C -- and if we miss the window, we still have point 1 happening.
The bugzilla reminders are sent every third calendar week (every week
is too disturbing).
Here is an initial (albeit randomly generated) proposal of X and Y:
severity CRITICAL/HIGH MEDIUM LOW
X 2 4 6
Y 2 4 6
Note that X=1 effectively means anything from 1 second to 3 weeks, X=2
means anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot
orphan packages after just 1 reminder.
I've made it so that X always equals to Y and every lower level is +2,
to make it easier to document, understand and remember, however this
is not required.
For this example a critical/high CVE would get a reminder every third
calendar week. After two reminders (that is after 3-6 weeks), if still
in NEW state, package is orphaned. The maintainer (and others) still
have extra 6 weeks to claim it.
If the bug is ASSIGNED, MODIFIED, etc., the package may be retired
after 2 months, but that only happens regularly at a certain point in
the schedule.
Similarly, a package with a medium CVE NEW bugzilla would be orphaned
after 4 reminders (after 9-12 weeks), retired at a point if still not
CLOSED after 4 months.
With low severity, that is 6 reminders (after 15-18 weeks), retired at
a point if still not CLOSED after 6 months (similarly to the current
policy).
Please share your feedback, before I proceed with this to FESCo.
If somebody would be interested in maintaining this procedure, I'd be
happy to hand over that responsibility to anybody who is willing to help.
The idea is to start with semi-automation and have something --
currently we had hoped for fully automated and we have nothing.
[0]
https://pagure.io/fesco/issue/1935
[1]
https://pagure.io/fesco/issue/2244
[2]
https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/