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/ _______________________________________________ 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
