ci: update workflow to allow to test workflow changes

[radoering]

The push trigger does not seem to work. The pull_request trigger should do.

Motivation: #159 fails because it needs a new hugo version, which has to be specificied in the workflow itself.

[github-actions]

Deploy preview for website ready!

✅ Preview
https://website-3llidfw81-python-poetry.vercel.app

Built with commit 54f6e28.
This pull request is being automatically deployed with vercel-action

[abn]

I believe this was done intentionally to prevent credentials leaking at some point.

CC @neersighted

In the meantime @radoering using a branch on the upstream remote should work.

[radoering]

I believe this was done intentionally to prevent credentials leaking at some point.

I believe this change does not increase the risk of leaking credentials.

In fact, pull_request is the more secure trigger compared to pull_request_target:

Workflows triggered via pull_request_target have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on pull_request from a branch in the same repository, but not from external forks. The reasoning behind the latter is that it is safe to share the repository secrets if the user creating the PR has write permission to the target repository already.

(from https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/)

It just does not work for forks if secrets are required, i.e. to deploy the preview.

In the meantime @radoering using a branch on the upstream remote should work.

I do not think so. #159 uses an upstream branch, but this will only work with pull_request because:

pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user supplied code.

(from https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/)

[abn]

I believe this change does not increase the risk of leaking credentials.

You are likely correct, I have not kept up with the changes in Actions on this topic. I am however surprised that the push trigger on the upstream remote branch didn't trigger with the branch context.

[abn]

@radoering come to think of it, the pull request event does not get (by default) access to secrets, correct? In that case deployment and vercel steps should fail on pull requests if this change is applied.

And if we enable access to secrets, that opens the doors for secrets being exported unintentionally.

[radoering]

I am however surprised that the push trigger on the upstream remote branch didn't trigger with the branch context.

It triggers but is always skipped because github.event.pull_request.head.repo.full_name is empty. We can probably fix this, but I do not think the push trigger makes sense because we want the action to create a comment with the preview in the PR so that pull_request makes more sense.

the pull request event does not get (by default) access to secrets, correct? In that case deployment and vercel steps should fail on pull requests if this change is applied.

The pull_request event has access to secrets when triggered from the repo itself but not when triggered from a fork. That is why it is easier to use it in a secure way compared to pull_request_target. Deployment and vercel steps will only fail if the pull_request event is triggered from a fork. However, the action will be skipped when triggered from a fork anyway because of the following condition:

(github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

See also the cited text from https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/ (emphasis added by myself) for reference:

Workflows triggered via pull_request_target have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on pull_request from a branch in the same repository, but not from external forks. The reasoning behind the latter is that it is safe to share the repository secrets if the user creating the PR has write permission to the target repository already.

To summarize the triggers with this PR:

• pull_request:
  • has no access to secrets (and will not work) when triggered from a fork
  • has access to secrets (and will work) when triggered from a branch in the repo
  • uses workflow from PR
  • is only triggered if the deploy-preview.yaml has been changed
  • is skipped when triggered from a fork (because it will not work anyway)
• pull_request_target
  • has always access to secrets (and will work), no matter if triggered from a fork or a branch in the repo
  • uses action from target (i.e. main branch) so that users cannot reveal secrets if they change the workflow in a fork
  • makes no sense if deploy-preview.yaml is changed because it uses the version from the main branch
  • is skipped if PR is not labeled as safe