You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I'm Diogo and I'm back (see #3151 and #2973). At the issue #2973 I suggested you to set minimal permissions to your workflows. Now I'm coming back to suggest a modification that would provide extra safety for the workflows that yet require dangerous permissions (e.g., contents: write).
Is your feature request related to a problem? Please describe.
Your workflows clang-format-fix.yml and release-files.yml are using dangerous permissions while running external dependencies pinned only by tag. Those patterns could be dangerous because if any of those actions get hijacked (and at the end they're all repositories and are susceptible to attacks like any other), an attacker could change the code that your tags point to, gaining access to your secrets and/or write permissions to your repository.
Describe the solution you'd like
A simple solution for this problem would be to hash-pin those sensitive actions, pointing the actions to the very specific commit of that release. It follows and example of the change:
- uses: r-lib/actions/pr-fetch@v1
would become
- uses: r-lib/actions/pr-fetch@11a22a908006c25fe054c4ef0ac0436b1de3edbe # v1.3.1
And this would enforce that your action is always running at the expected code.
The only downsize of this solution is that it gets trickier to manually update the version of the actions as they get out-of-date, but that can be solved by using a Dependency-Update-Tool (like dependabot or renovatebot). They can be configured to send PRs updating the dependencies on the pace that is most convenient for you (which can also be "never", and you'd only get PRs in case of security updates). For the case of the hash-pinning, the PRs would still keep a comment with the human-readable version used =).
Conclusion
As it's a very simple change, I'll take the liberty to raise a PR and making it easier for you to evaluate the changes. Please let me know if you have any questions or concerns.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi, I'm Diogo and I'm back (see #3151 and #2973). At the issue #2973 I suggested you to set minimal permissions to your workflows. Now I'm coming back to suggest a modification that would provide extra safety for the workflows that yet require dangerous permissions (e.g., contents: write).
Is your feature request related to a problem? Please describe.
Your workflows clang-format-fix.yml and release-files.yml are using dangerous permissions while running external dependencies pinned only by tag. Those patterns could be dangerous because if any of those actions get hijacked (and at the end they're all repositories and are susceptible to attacks like any other), an attacker could change the code that your tags point to, gaining access to your secrets and/or write permissions to your repository.
Describe the solution you'd like
A simple solution for this problem would be to hash-pin those sensitive actions, pointing the actions to the very specific commit of that release. It follows and example of the change:
And this would enforce that your action is always running at the expected code.
The only downsize of this solution is that it gets trickier to manually update the version of the actions as they get out-of-date, but that can be solved by using a Dependency-Update-Tool (like dependabot or renovatebot). They can be configured to send PRs updating the dependencies on the pace that is most convenient for you (which can also be "never", and you'd only get PRs in case of security updates). For the case of the hash-pinning, the PRs would still keep a comment with the human-readable version used =).
Conclusion
As it's a very simple change, I'll take the liberty to raise a PR and making it easier for you to evaluate the changes. Please let me know if you have any questions or concerns.
Thanks!
The text was updated successfully, but these errors were encountered: