Improve sec-approval checkboxes/workflow
Categories
(Conduit :: Lando, enhancement)
Tracking
(Not tracked)
People
(Reporter: tjr, Unassigned)
References
Details
I think there are two changes we'd like to make to the sec-approval checkboxes.
- Relax the sec-approval checkbox so it only shows in the circumstances we want to enforce sec-approval on; namely csectype-sandbox-escape + sec-high ; let it be a box users have to check
- Add a separate release-window checkbox. If the date is between
Release Candidate Go to buildandMerge Dayinclusive (I'm going to let Relman confirm this) and all ESRs are not 'unaffected' or 'wontfix' (meaning, if they are lacking status flags, or the flags say affected, etc) and it is a sec- rated bug then landing should be hard-blocked or require a scary checkbox be checked.
Comment 1•9 days ago
|
||
I think the added restrictions only need to apply to high or critical rated bugs. Anything moderate or lower can just be uplifted to ESR during the next cycle without issue.
Super scary warning should be shown after we've passed the "Security bugs uplift deadline" shown in whattrainisitnow. This is typically the Friday before RC week.
Comment 2•9 days ago
|
||
We also need help getting status flags set in a timely fashion. Our team is feeling increasingly like a single point of failure for that when we shouldn't be the ones having to do it in the first place. How can we get developers to more proactively identify affected releases and set the flags as needed when they're working on diagnosing and fixing an issue? It would take them seconds to do instead of us having to spend minutes per bug times 10, 20, or more bugs per day.
Description
•