Add COMPOSER_AUTH env variable to workflows

[Potherca]

Proposed Changes

Because of the amount of GitHub API calls composer does, the CI runs into a rate limit. This causes jobs to fail or be aborted. Adding the GITHUB_TOKEN as auth method should avoid these rate limits.

Related Issues

• CI: investigate adding "retry" logic #196

[jrfnl]

Reviewed:

1. While I'm not sure it will solve all the issues (the most recent ones point to an issue with powershell ?), I totally agree that this should help.
2. Do we really need it in all workflows though ? Or only in the integrationtest.yml file ? (which is the only one which has been giving us trouble)
3. Is setting it via env: COMPOSER_AUTH the right way to set this ? Or should we leverage the setup-php action for this ? (which can set the Composer authentication up persistently)
   Ref: https://github.com/shivammathur/setup-php#github-composer-authentication

[Potherca]

Accidentaly pressed the "Request Review" button again. Sorry!

[Potherca]

From what I could see, the error in the powershell were triggered by composer, caused by the rate limit:

Run shivammathur/setup-php@v2
"C:\Program Files\PowerShell\7\pwsh.exe" D:\a_actions\shivammathur\setup-php\v2\src\scripts\run.ps1

...
==> Setup Tools
✗ composer 403: rate limit exceeded
Error: The process 'C:\Program Files\PowerShell\7\pwsh.exe' failed with exit code 1

https://github.com/PHPCSStandards/composer-installer/actions/runs/3845986458/jobs/6550770322#step:3:27

The fix was proposed in ramsey/composer-install#182 (comment) but sadly this change does not seem to fix the rate limit issue so another approach seems needed. I'll take a look at the setup-php docs.

I just added it to all workflows that do a composer install/update just to be safe (as I have no idea how the rate limit between GitHub / Composer / GHA.

Leaving this for now.

[Potherca]

@jrfnl I'm inclined to merge this as-is (as it shouldn't do any harm) or close it, and resolve any other items discussed here later (if at all).

[jrfnl]

I'm inclined to merge this as-is (as it shouldn't do any harm) or close it, and resolve any other items discussed here later (if at all).

@Potherca In principle, I'm fine with that, though I do have two niggly questions:

• Could always providing the github-oauth have security implications ?
• We're not limiting the workflows to only run in this repo (excluding forks), so could this "leak" the GITHUB_TOKEN to forks ?

Other than that, this probably should be rebased before merging. It also looks like one workflow was missed - linting.yaml -, though that may be deliberate as that workflow uses only docker containers ?

[Potherca]

Good questions!

Some basic points, before answering the individual questions:

1. When you enable GitHub Actions, GitHub installs a GitHub App on your repository. The GITHUB_TOKEN secret is a GitHub App installation access token.
2. At the start of each workflow job, GitHub automatically creates a unique GITHUB_TOKEN secret to use in your workflow.
3. The token's permissions are limited to the repository that contains your workflow.
4. The GITHUB_TOKEN expires when a job finishes or after a maximum of 24 hours.

^{Dource: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication}

So, to answer the questions, in order:

• Could always providing the github-oauth have security implications ?

  • It shouldn't... That is to say, using HTTPS means the token isn't broadcast in the clear and the receiver (packagist) is a trusted party. However, if either ramsey/composer-install, Composer, or Packagist are compromised, then Yes. We would be compromised together with all other users of those services. The impact would be limited to the repository, for the duration of its validity (see 3. and 4.).

    This scenario could be mitigated by setting "Workflow permissions" (in the "Actions permissions" settings to read-only. Assuming we don't do any writing in the actions this should not break our CI/CD.

• We're not limiting the workflows to only run in this repo (excluding forks), so could this "leak" the GITHUB_TOKEN to forks ?

  • No. The secrets.GITHUB_TOKEN in the fork would only work for that repo. (see 1. and 2.) As it is a secret it will not be shown in the action's output. This can be validated by adding a - run: echo ${{ secrets.GITHUB_TOKEN }} to any action.

• Other than that, this probably should be rebased before merging.

  • Done.

• It also looks like one workflow was missed - linting.yaml -, though that may be deliberate as that workflow uses only docker containers ?

  • That is correct. As it does not do a composer install, it does not require a token

[jrfnl]

@Potherca Thanks for that additional context. I've seen some interesting scenario's floating around about vulnerabilities and GHA, so yes, let's err on the side of caution and limit those workflow permissions.

[Potherca]

@jrfnl FYI: I've just set the "Workflow permissions" for the GITHUB_TOKEN in this repo to read-only. So if the build starts randomly breaking (YOLO) this might be good to know.

[jrfnl]

@jrfnl FYI: I've just set the "Workflow permissions" for the GITHUB_TOKEN in this repo to read-only. So if the build starts randomly breaking (YOLO) this might be good to know.

Thanks and should be straight-forward to check by triggering a build for each workflow (which I've done just now). I'll check in a couple of hours if the builds have passed and if so, I'll merge this PR.