Also this won’t work with any bots that can auto merge when CI checks pass, e.g. renovate and dependabot, whereas a locked branch will work.
On Tue, 5 Sep 2023 at 17:48, Tim Jacomb <timjaco...@gmail.com> wrote: > Why not lock the branch instead? > That means it won’t break review approvals in the meantime and things like > enabling auto merge for when the release block is over > > On Tue, 5 Sep 2023 at 17:13, 'wfoll...@cloudbees.com' via Jenkins > Developers <jenkinsci-dev@googlegroups.com> wrote: > >> Dear plugin maintainers, >> >> *Context* >> In situations where the security team is collaborating with plugin >> maintainers on a coordinated release, the artifacts are staged and >> commits/tags are pushed to a designated private repository. >> >> However, challenges arise when multiple maintainers are simultaneously >> working on the same plugin. Coordinating these efforts becomes crucial. If >> another maintainer merges pull requests or releases a new version of the >> plugin while a coordinated security release is pending, it necessitates >> re-staging the artifacts. Depending on the timing of such occurrences in >> relation to the release schedule, it can create unnecessary urgency and >> often result in time wasted. >> >> *Objectives* >> We want to have a way to inform the plugin maintainers while not >> revealing specific details about the advisory in advance. >> >> *Current solution* >> We've implemented an automation solution for your convenience. You can >> now trigger this automation by simply commenting "/block-release" in the >> SECURITY ticket assigned to you. This action will reduce GitHub permissions >> for contributors to "Triage”. At the same time, a GitHub advisory will be >> created, with contributors included as "Collaborators," allowing them to >> view the advisory and receive a notification. >> >> >> Once the release is completed, the security team will promptly remove the >> block. You can also initiate the removal by commenting "/unblock-release" >> in the same SECURITY ticket. >> >> *Known limitations* >> >> - Our automation cannot prevent all incidents but aims to cover most >> cases. >> - For vulnerabilities affecting multiple plugins, the security team >> has to be involved to widen the scope of the block. >> - Some corner cases like users with "org owner" permissions in GitHub >> or Administer permission on ci.jenkins.io are still able to perform >> actions that could make the staged artifacts no longer valid. >> >> >> *Browser extension option* >> If you’re a GitHub “org owner” and want to easily see if there is a >> pending advisory in the current repository you are browsing, you may find >> this browser extension valuable: >> https://github.com/Wadeck/extension-jenkins-security. >> >> This automation was tested already multiple times in a closed beta way, >> and now we are opening the beta to anyone interested. After some iterations >> we will call it GA but still welcome any feedback. >> >> Wadeck Follonier >> >> Jenkins Security officer >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jenkinsci-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/2ffd0261-6682-4c67-b5ca-0f29c97ecbadn%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/2ffd0261-6682-4c67-b5ca-0f29c97ecbadn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieTRxdjibCfVJfCaAbf5Scw%2BuNx_VsZ-T8HVL5nnmfDJA%40mail.gmail.com.
