Ensure Trusted Code Checkout in GitHub Actions Workflow

[UlisesGascon]

Description

This pull request addresses a potential security issue in our GitHub Actions workflow by ensuring that the code being checked out is from a trusted source. The changes include:

Conditional Ref Checkout:

• Modified the Git Checkout step to conditionally use the pull request commit SHA (github.event.pull_request.head.sha) only if the event is a pull request.
• For other events, it defaults to using github.ref.

Validation

No local validation was done. This is related to the OSSF Scorecard

Related Issues

See: #6979

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run npm run format to ensure the code follows the style guide.
• I have run npm run test to check if all tests are passing.
• I have run npx turbo build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Sep 16, 2024 7:55am

[ovflowd]

@UlisesGascon waiting for you to address the code review changes :)

[RedYetiDev]

For what it's worth, I don't see any security risks with the current setup. If the PR SHA is available, it will be used; otherwise, github.ref (which points to the main branch in this case) will be utilized.

The PR SHA can be trusted in this case, as it points to the SHA at the event triggering the workflow execute, meaning that there is no possibility for a race-condition.

[ovflowd]

For what it's worth, I don't see any security risks with the current setup. If the PR SHA is available, it will be used; otherwise, github.ref (which points to the main branch in this case) will be utilized.

The PR SHA can be trusted in this case, as it points to the SHA at the event triggering the workflow execute, meaning that there is no possibility for a race-condition.

I agree here; the Github object is reserved; although you can trigger GitHub Actions with custom WebHook payloads, we don't have any configured here. And if that ever happened, this change would be ineffective regardless.

I'm neutral to the change, but I don't believe it is needed.

[UlisesGascon]

For what it's worth, I don't see any security risks with the current setup.

+1 I just want to see if we can remove the warnings from the scorecard 🫤

[ovflowd]

For what it's worth, I don't see any security risks with the current setup.

+1 I just want to see if we can remove the warnings from the scorecard 🫤

I am starting to question the real value of the scorecard if it is dumb enough to not recognise false positives.

[ovflowd]

LGTM -- for the sake of our scorecard 🤷

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟢 98	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 100	🟢 100	🟢 100	🟢 91	🔗
/en/about/previous-releases	🟢 98	🟢 100	🟢 100	🟢 92	🔗
/en/download	🟢 100	🟢 100	🟢 100	🟢 91	🔗
/en/blog	🟢 100	🟢 100	🟢 100	🟢 92	🔗

[github-actions]

Unit Test Coverage Report

Lines	Statements	Branches	Functions
	90.54% (594/656)	76.29% (177/232)	94.57% (122/129)

Unit Test Report

Tests	Skipped	Failures	Errors	Time
131	0 💤	0 ❌	0 🔥	5.228s ⏱️