chore(security): remove GitHub Actions caching to prevent cache poisoning

[abretonc7s]

Description

Context

This PR updates our GitHub Actions workflows to use artifacts instead of caching for better control over build outputs. The changes affect the lint-build-test.yml and publish-release.yml workflows.

Changes

• Removed cache: yarn configurations from all Node.js setup steps in lint-build-test.yml
• Updated publish-release.yml workflow to:
  • Replace caching mechanism with GitHub Artifacts for build outputs
  • Upgrade GitHub Actions to newer versions (checkout@v4, setup-node@v4)
  • Remove the npm publish dry-run step for a more streamlined release process
  • Implement proper artifact handling between jobs using upload-artifact@v4 and download-artifact@v4

Implementation Details

This change replaces the GitHub Actions caching mechanism with artifacts for managing build outputs between jobs. This provides more explicit control over how build artifacts are handled and transferred throughout the workflow.

Performance Considerations

Build times may slightly increase without caching, but the artifact implementation ensures efficient transfer of build outputs between jobs. We can monitor and optimize if needed.

Breaking Changes

None. This is an internal workflow change that doesn't affect the published packages or their consumers.

Testing Instructions

1. Create a test release to verify the complete workflow
2. Monitor build times to assess performance impact
3. Verify that build artifacts are properly transferred between the release and publish jobs

Related Issues

#3925 - Remove usage of GitHub action caching from critical workflows

[chakra-guy]

LGTM

[paulmillr]

I don't understand this.

If files are cached, surely their checksumms are verified after downloading. If so it doesn't matter if it's cached or not, so it can be cached for perf reasons. No?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.05%. Comparing base (62331c6) to head (7b07fc8).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1209   +/-   ##
=======================================
  Coverage   74.05%   74.05%           
=======================================
  Files         182      182           
  Lines        4351     4351           
  Branches     1066     1066           
=======================================
  Hits         3222     3222           
  Misses       1129     1129           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[NicholasEllul]

@paulmillr behind the scenes setup-node is using GitHub's action cache to perform the caching/restoration of dependencies.

When a cache is to be restored, it is downloaded into a temp directory, and then extracted. This extraction happens relative to the GITHUB_WORKSPACE directory (generally the repository's root), and will override any existing files that have the same path.

This means that if someone were to poison the cache to include a malicious package.json, yarn.lock, or any other file that is known to exist, it would overwrite the legitimate copy with the poisoned one upon extraction (in addition to restoring dependencies as expected).

[paulmillr]

@NicholasEllul that sounds idiotic and is a real security issue. Why does GitHub allow it?

[NicholasEllul]

@paulmillr Originally when a security researcher had reported the issue to them, GitHub had dismissed it (Blog post). However, the issue has since been seen exploited in the wild, and people have started to create more noise around it. Per their comment, it sounds like they are exploring how this can be improved. Until then, we do not consider it safe to use action cache in publishing workflows.