TODO

[ezzatron]

• [ ] Scanning repos for config files
• [x] Parsing repo config files
• [x] Parsing host config files
• [ ] Permissions boundary logic
• [ ] Require verified commits by default
• [ ] Handle tokens for 0 repos - introduce account-level rules?

[ezzatron]

Repository name rules:

The repository name can only contain ASCII letters, digits, and the characters ., -, and _. The repository . is reserved.

[ezzatron]

Secret name rules:

Secret names can only contain alphanumeric characters ([a-z], [A-Z], [0-9]) or underscores (_). Spaces are not allowed. Must start with a letter ([a-z], [A-Z]) or underscores (_).

[ezzatron]

Organization name rules:

The name may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

[ezzatron]

Environment name rules:

Name must not contain non-printable characters or the characters "'", "\"", "`", ",", ";", "\"

[ezzatron]

Current front-runner for re-work of permissions rules schema:

permissions:
  rules:
    - description: Description goes here
      resources:
        - accounts: [account-a, account-*]
          noRepos: true
          allRepos: true
          selectedRepos: [repo-a]
      consumers: [account-b, wild-*]
      permissions:
        contents: write
        members: read
        metadata: read

[ezzatron]

Three types of token requests:

• All repos (no specific list, works for new repos)
• Specific repos (list of repos)
• No repos (empty list, used for access to accounts)

Two types of consumers:

• Individual repos (token ends up accessible to the repo)
• Accounts (token ends up accessible to all repos in the account)

Goals:

• Avoid needing to know which permissions GitHub uses for repos and which it uses for accounts so that new perms added by GitHub "just work"
• Defense in depth
• Config gets simpler to use if you don't need cross-account access

Concepts:

• When granting a permission for an account, it should not apply to any repos.
  • Effectively, account rule permission grants only apply to tokens with "no repos" permissions.
• When granting a permission for a repo, it's implicitly granted for the repo's account.
  • This is likely to be astonishing to users, but it's how GitHub works.
  • Should probably require explicit grant of account permissions when the token is for "no repos" to prevent foot-guns.
• Revoking or reducing a permission for an account will necessarily revoke or reduce it for all repos in that account.
  • This is also likely to be astonishing to users.
  • Should probably treat this as a configuration error, since it's likely to cause confusion. Can always be fixed by re-ordering rules (i.e. move the repo rule after the account rule).