On Wed, 6 Sept 2023 at 12:42, '[email protected]' via Jenkins Developers <[email protected]> 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 [email protected] > 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 <[email protected]> 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, '[email protected]' via Jenkins >>> Developers <[email protected]> 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 [email protected]. >>>> 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifR66pw3ddhBQxP7AYhCykH6A2ONOT9YjM0%2BBo0A-KEpg%40mail.gmail.com.
