Open Contribution

Open Contribution is one of several recommended access models for Flutter-Global repositories. It’s best for inner source repositories used by many teams with contributions from many users. It allows all Flutter-Global members to use the repository code. It reduces the effort to contribute with default write access. It’s easy to setup. However, general write access means threat analysis of your review, approval, and CI workflow is critical to reduce risk.

Access Permissions

• Grant the all-flutter-global team write permission.
• Grant a maintainer team admin permission.

To do this in a Codebase Governor repository file:

# enforce no admins other than owner & maintainers
admins: {}

# allow contribution from any member of Flutter-Global
contributors:
  teams:
    - all-flutter-global

Contributor Protection

Choose a branch protection setup from Audited Source, Reviewed Source or Multiple Team Source. If not sure – use Reviewed Source which requires a contributor to raise a pull request for approval by a maintainer. This requires branch protection – add this to your Codebase Governor repository file:

branch-protections:
  - patterns:
      - "main"
    parameters:
      required-reviews-count: 1
      requires-codeowner-reviews: true

To ensure maintainers must approve pull requests, add a CODEOWNERS file in the root directory of your repository referencing the capability maintainer team:

# replace 'example-name' with your capability name:
*       @Flutter-Global/maintainers-cap-example-name

Threat Analysis

This access model involves wide read and write permissions. Your threat analysis should consider:

• Leaked Secrets : The wide visibility of the repository means wide exposure of a secret committed by mistake.
• Leaked Content : The wide visibility of the repository means wide exposure of any sensitive intellectual property contained within it (e.g. pricing algorithms).
• GitHub Action Workflow Edits : Any user with write access can edit your GitHub Action workflows in a feature branch to improve them – or to attack them. If using secrets in the workflow use GitHub environments to restrict secret access.
• GitHub Package Permissions : If you use SemVar tags or publish packages to GitHub Packages consider what you want a contributor to be able to do. You may want to consider GitHub tag protection or limit your package permissions.

If the risk is too high – consider Requested Contribution instead.