TODO

[ezzatron]

• Produce request objects from consumer config
• Support permission name patterns in permissions rules
• Require verified commits by default?
• Consider linting of probably-unexpected behaviors?

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

[ezzatron]

Key understanding:

When requesting tokens, it matters which consumers (repos and accounts) will gain access to which resources (other repos and accounts), but it doesn't matter what repo requests the token to be created.

When requesting the creation of secrets it matters which requesters (repos) can modify secrets in which targets (repos and accounts), but it doesn't matter what the content is (assuming token access rules are satisfied as per the 1st paragraph).