[Information] Release block "Beta" program

[wfoll...@cloudbees.com]

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

[Tim Jacomb]

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

--
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.

[Tim Jacomb]

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.

[wfoll...@cloudbees.com]

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.

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.

For the bots, that's pretty interesting, I haven't thought about the fully automatic flow there.

[Tim Jacomb]

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.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/52394464-6d3e-4f35-a188-9c88d5ad7d92n%40googlegroups.com.

[wfoll...@cloudbees.com]

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.

[Jesse Glick]

On Thu, Sep 28, 2023 at 4:11 AM 'wfoll...@cloudbees.com' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

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.

FWIW the current system has been very reassuring for me. There is a constant flow of PRs on various plugins I have write access to which either fix some minor bug or unblock PCT etc., but even in cases where I have personally seen a SECURITY ticket a couple of weeks ago it is very hard to keep up with the current list of plugins with pending advisories. Seeing that I suddenly lack write permission is enough to remind me of the hazard, and prevent me from accidentally merging a PR, triggering a release, etc.