| 1 |
Hi, |
| 2 |
|
| 3 |
Jaco Kroon wrote: |
| 4 |
> Specifically, what I suggest is to flag the PR that fixes the issues |
| 5 |
> (ie, ebuild bump) with the usual Bug: tag, but to then at the same time |
| 6 |
> be able to pre-emptively file a PR removing the vulnerable versions, but |
| 7 |
> only once the security bug has been handled (closed). |
| 8 |
> |
| 9 |
> Towards this end, I'd suggest a tag such as: |
| 10 |
> |
| 11 |
> Pending: https://bugs.gentoo.org/NNNNNN — to reference a bug; the bug |
| 12 |
> needs to be closed before this PR will be considered for merging. |
| 13 |
|
| 14 |
No, this is not really needed and will make everything more complicated. |
| 15 |
|
| 16 |
Keep in mind that you never know what happens: |
| 17 |
|
| 18 |
- It's possible that the initial bump wasn't enough. |
| 19 |
|
| 20 |
- Maybe during stabilization process we will uncover the need for |
| 21 |
an additional patch. |
| 22 |
|
| 23 |
- It's possible that keywords will change during the process. |
| 24 |
|
| 25 |
- It's still possible that the ebuild(s) which will be cleaned up |
| 26 |
as part of the process changes before cleanup will happen. |
| 27 |
|
| 28 |
- It's possible that the process hasn't finished before a new |
| 29 |
security bug for same package was created (superseded). |
| 30 |
|
| 31 |
But if you have created the follow ups in advance, |
| 32 |
|
| 33 |
- this will clutter things up |
| 34 |
|
| 35 |
- you will have to adjust things all the time |
| 36 |
|
| 37 |
- and any additional fix up will create new notifications, |
| 38 |
comments... someone has to check |
| 39 |
|
| 40 |
- proxy-maintainer would have to spend time for review twice |
| 41 |
because something could have changed between creation of |
| 42 |
follow up PR and time when the PR will get merged |
| 43 |
|
| 44 |
And like you said, current CI would be unable to test these follow up |
| 45 |
PRs before new ebuild was marked stable or CI would report a lot of |
| 46 |
NonsolvableDepsInStable problems. Sure, you could delay or re-trigger |
| 47 |
check once stabilization has happened but I really see no benefits in |
| 48 |
doing anything of that in advance if the chance is high that you have to |
| 49 |
spend the same amount of time again before you can finally merge. |
| 50 |
|
| 51 |
|
| 52 |
-- |
| 53 |
Regards, |
| 54 |
Thomas Deutschmann / Gentoo Security Team |
| 55 |
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |
Archives