> Hello, Fedora has an approved security policy since September 2018 [0]: > > > 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]. > > 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 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 bugs opened? > 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. This seems reasonable to me. > 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). 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. > > > [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/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
