Hi,
Jaco Kroon wrote:
Specifically, what I suggest is to flag the PR that fixes the issues
(ie, ebuild bump) with the usual Bug: tag, but to then at the same time
be able to pre-emptively file a PR removing the vulnerable versions, but
only once the security bug has been handled (closed).
Towards this end, I'd suggest a tag such as:
Pending: https://bugs.gentoo.org/NNNNNN — to reference a bug; the bug
needs to be closed before this PR will be considered for merging.
No, this is not really needed and will make everything more complicated.
Keep in mind that you never know what happens:
- It's possible that the initial bump wasn't enough.
- Maybe during stabilization process we will uncover the need for
an additional patch.
- It's possible that keywords will change during the process.
- It's still possible that the ebuild(s) which will be cleaned up
as part of the process changes before cleanup will happen.
- It's possible that the process hasn't finished before a new
security bug for same package was created (superseded).
But if you have created the follow ups in advance,
- this will clutter things up
- you will have to adjust things all the time
- and any additional fix up will create new notifications,
comments... someone has to check
- proxy-maintainer would have to spend time for review twice
because something could have changed between creation of
follow up PR and time when the PR will get merged
And like you said, current CI would be unable to test these follow up
PRs before new ebuild was marked stable or CI would report a lot of
NonsolvableDepsInStable problems. Sure, you could delay or re-trigger
check once stabilization has happened but I really see no benefits in
doing anything of that in advance if the chance is high that you have to
spend the same amount of time again before you can finally merge.
--
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
