| 1 |
On Thu, Aug 12, 2021 at 5:53 AM Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> Hello, everyone. |
| 4 |
> |
| 5 |
> TL;DR: I'd like to propose that stabilizations are done via blockers of |
| 6 |
> security bugs instead of security bugs themselves, i.e. as any other |
| 7 |
> stabilizations. |
| 8 |
> |
| 9 |
> |
| 10 |
> Right now we're often performing security-related stabilizations via |
| 11 |
> security bugs. This has a few problems, that are: |
| 12 |
> |
| 13 |
> 1. Stabilization-related activity causes unnecessary mail to the widely |
| 14 |
> subscribed security alias. That is, subscribed people get notified of |
| 15 |
> package list changes, NATTkA results, every arch doing its work. |
| 16 |
> However, in reality the security team only cares about stabilization |
| 17 |
> being started, stalled or finished -- and for that, getting the usual |
| 18 |
> 'dependent bug added/closed' mail should be sufficient. |
| 19 |
> |
| 20 |
> 2. NATTkA has no good way of distinguishing irrelevant security bugs |
| 21 |
> from security bugs where something went wrong (and NATTkA doesn't use |
| 22 |
> persistent state by design). The most important problem is that -- |
| 23 |
> unlike regular stablereqs -- security bugs aren't supposed to be closed |
| 24 |
> after stabilization. It can't really distinguish a security bug 'left |
| 25 |
> open' from a security bug with incorrect package list. |
| 26 |
> |
| 27 |
> 3. Proxied maintainers without editbugs can't actually CC arches on |
| 28 |
> security bugs since the bugs are assigned to security@. |
| 29 |
> |
| 30 |
> |
| 31 |
> To resolve these problems going forward and establish consistent |
| 32 |
> behavior in the future, I'd like to propose to disable 'package list' |
| 33 |
> fields on security bugs and instead expect regular stabilization bugs to |
| 34 |
> be used (and made block the security bugs) for stabilizations. While I |
| 35 |
> understand that filing additional bugs might be cumbersome for some |
| 36 |
> people, I don't think it's such a herculean effort to outweigh |
| 37 |
> the problems solved. |
| 38 |
> |
| 39 |
> In the end, consistency is a good thing and we've introduced a dedicated |
| 40 |
> stabilization category to reduce the spread of stabilization bugs all |
| 41 |
> around the place. |
| 42 |
|
| 43 |
I love this. |
| 44 |
|
| 45 |
It sounds (from IRC) like you're on board with the idea of having |
| 46 |
nattka add kw:security to appropriate stabilization bugs. |
| 47 |
|
| 48 |
Could nattka also do something to the security@-assigned but itself to |
| 49 |
indicate that all security-supported architecture have been handled? |
| 50 |
Something like leaving a comment or fiddling with the security |
| 51 |
whiteboard. |
| 52 |
|
| 53 |
It would be nice to be able to resolve the security@-assigned but |
| 54 |
before non-security-supported architectures are handled. |
| 55 |
|
| 56 |
To do that, I think we'd want to change what's required for the "clean |
| 57 |
up" step. Since today the "clean up" step is dropping the vulnerable |
| 58 |
package versions from the tree, it is dependent on |
| 59 |
non-security-supported architectures completing the stabilization bug. |
| 60 |
I think we'd like to break that dependence. |
| 61 |
|
| 62 |
I suggest that we redefine the "clean up" step to be: drop |
| 63 |
security-supported architectures' keywords from vulnerable versions. |
| 64 |
That would allow the security@-assigned bug to be resolved before |
| 65 |
non-security-supported architectures are finished with stabilization. |
Archives