Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support: execution from hashref disabled/broken vs GitHub Actions Security Best Practice? #712

Closed
3 tasks done
HariSekhon opened this issue Feb 18, 2022 · 5 comments
Closed
3 tasks done
Assignees

Comments

@HariSekhon
Copy link

HariSekhon commented Feb 18, 2022

Checklist

  • I am using the latest version of this action.
  • I have read the latest README and followed the instructions.
  • I have read the latest GitHub Actions official documentation and learned the basic spec and concepts.

Describe your question

Why is execution from the main branch latest hashref disabled/broken when this is the GitHub Actions Security Best Practice to pin 3rd party github actions to an immutable hashref?

I've already seen issues #84 and #98 but there wasn't any reason given in those tickets other than using v2 / v3 tags, but this contradicts GitHub's own security recommendations to not use tags for 3rd parties, see this doc section:

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions

Is it intentional to break execution from main branch hashref or is this a mistake, and if intentional, why?

Update: I had assumed that the latest main hashref would contain the fixes in v3, but for now I'll try using peaceiris/actions-gh-pages@068dc23d9710f1ba62e86896f84735d869951305 which is the v3 tag's current hashref for immutability.

Relevant links

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions

Relevant log output

No response

Additional context.

No response

@HariSekhon HariSekhon added the support User support label Feb 18, 2022
@peaceiris
Copy link
Owner

peaceiris commented Mar 5, 2022

Update: I had assumed that the latest main hashref would contain the fixes in v3, but for now I'll try using 068dc23 which is the v3 tag's current hashref for immutability.

I have left a comment on an issue somewhere in the past, but I couldn't find it, so I'll restate it here. Our project builds and provides build assets only when creating a release. This is to prevent the user from executing this action with a specific branch (like main). For example, if we maintain build assets in the main branch and users use this action as follows, a major release including breaking changes will break the CI workflow of the users silently.

- name: Deploy
  uses: peaceiris/actions-gh-pages@main  # Bad example!
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public

In this project, a major tag (e.g. v3) is guaranteed to contain no breaking changes. But, we recommend using a tag or a commit hash for the stability of your workflows.

- name: Deploy
  uses: peaceiris/actions-gh-pages@v3.8.0 # tag: Better (Dependabot uses this type)
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public
- name: Deploy
  uses: peaceiris/actions-gh-pages@068dc23d9710f1ba62e86896f84735d869951305  # commit hash of v3.8.0: Best!
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public

Our project builds and provides build assets only when creating a release.

See the next script.

mkdir ./lib
npm run build
git add ./lib/index.js
git commit -m "chore(release): Add build assets"
npm run release -- --release-as "${RELEASE_TYPE}" --preset eslint
git rm ./lib/index.js
rm -rf ./lib
git commit -m "chore(release): Remove build assets [skip ci]"

@github-actions
Copy link
Contributor

github-actions bot commented Jun 2, 2022

This issue has been marked as inactive.

If you still encounter this or it has changed, add a comment to provide further information.

@HariSekhon
Copy link
Author

@peaceiris thanks for the reply, I also figured out after posting this that instead of taking the SHA of the latest trunk branch, I could use the SHA of a release instead to achieve the same effect while still using a SHA instead of a tag, as per GitHub Actions Security Best Practice.

Thanks for the reply here, closing.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 6, 2022

This issue has been marked as inactive.

If you still encounter this or it has changed, add a comment to provide further information.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 6, 2022

This issue has been LOCKED because of it being resolved!

The issue has been fixed and is therefore considered resolved.
If you still encounter this or it has changed, open a new issue instead of responding to solved ones.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 6, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants