The trade-off is more than "limited" from my PoV. Knowing we are publishing an advisory in general means that if you want to look for vulnerabilities, you have to search in 1800+ plugins, i.e. there is no advantage to know it. With the information we provide, meaning the popularity of the plugin, we still limit the scope to 100s of plugins. If a branch is locked, that could provide information to some actors to look deeply in that plugin in particular. With such scope, the search is a lot simpler.
The locking being visible makes the "any reason" not really an argument from my PoV. Usually you apply branch protection but you do not lock your main/master branch completely. By watching the repositories, anyone is able to see changes and thus can act on them. Also, the branch locking alone, will not provide a big defense against incident, if we let the maintainers with their admin permission, as they can just imagine it was an error from another maintainer and just decide to unlock the branch. > you weren't involved in the actual security fix That's the idea with the advisories, to inform co-maintainer, even if they have not opened any SECURITY ticket. That information is available on the repository as well. The only caveat is the current GitHub UI does not display advisories in the tab, you have to use the proposed extension or any other mechanism for that. Adding the branch protection mechanism as an option of the locking could be interesting to dig deeper. At this point I have not looked at that part of the API (https://docs.github.com/en/rest/branches/branch-protection). I would like to get more opinions on the topic before investing time on it as the current version seems to be satifsactory for the beta testers. On Wednesday, September 6, 2023 at 1:51:18 PM UTC+2 timja...@gmail.com wrote: > On Wed, 6 Sept 2023 at 12:42, 'wfoll...@cloudbees.com' via Jenkins > Developers <jenkin...@googlegroups.com> wrote: > >> Last time we tested, the branch locking has the problem to be visible for >> anyone. This means that you can guess which plugin will receive an advisory >> soon. > > > It could be locked for any reason, and personally I would say the > trade-off of the _very_ limited information is worth it here. > > >> The feature usage is up to the maintainers, like it's too limited for >> them, they can just communicate with their co-maintainers to ensure the >> master/main branch will not updated and no other releases are done. >> > > I have multiple times merged pull requests on plugins that are staged, > with or without co-maintainers, it's really not something that's easy to > keep track of when you maintain more than one plugin, especially when it > happens a week or two after staging, and even more especially when you > weren't involved in the actual security fix. > > >> For the bots, that's pretty interesting, I haven't thought about the >> fully automatic flow there. >> >> On Tuesday, September 5, 2023 at 11:51:58 PM UTC+2 timja...@gmail.com >> wrote: >> >>> 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 <timja...@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 <jenkin...@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-de...@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-de...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/52394464-6d3e-4f35-a188-9c88d5ad7d92n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/52394464-6d3e-4f35-a188-9c88d5ad7d92n%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/54d366cb-452e-40a0-a6b3-c802cd4ab9ccn%40googlegroups.com.
