[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] possible additional tag for GLEP66: Pending
From:       Thomas Deutschmann <whissi () gentoo ! org>
Date:       2020-12-23 14:47:39
Message-ID: 7093d597-ce39-125b-9759-c009880a6336 () gentoo ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic