Hello, Fedora has an approved security policy since September 2018
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 .
There are several things I'd like us to consider based on the experience from
the FTBFS policy adjustments  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 like the main idea here, but one concern I have is the categorization of these packages.
Should we consider a separate type of orphan group for these packages or even a subset.
I'm thinking about the type of package where someone contributed it, maybe updated it
once or twice, and then it has seen not activity for a long time. Now it has a security
update. This package is not critical to the system but has a reasonable number of users
who may or may not be impacted if it's removed. The original contributor is no longer
interested in maintaining it.
Then there's the type of package that is high profile for the distribution. Granted,
we are not likely to see this happen to core packages, but it might be worth incorporating
in to policy. What happens if openssh has a vulnerability and there's not currently
an active maintainer. This is not all that unrealistic given the situation unfolding with
FreeIPA and dependent Java packages (that's a different thread).
And lastly, what about packages that are currently in the orphan state but have security
I'd like to adjust the policy before I go implement some tooling
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
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.
This seems reasonable to me.
For this example a critical/high CVE would get a reminder every third
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
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).
Where do get bug severity information?
> 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.
>  https://pagure.io/fesco/issue/1935
>  https://pagure.io/fesco/issue/2244
>  https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/