Pin workflow wsl2.yml

[HackingRepo]

Pinning the workflow wsl2.yml part of the Supply Chain Security Tracking Issue, #12905

note the wsl setup workflow the pinning matches the exact v6.1.0

[sylvestre]

Why is that better than the version?

[HackingRepo]

no that is the same version, v6.1.0 just the commit hash pinned

[HackingRepo]

@sylvestre, if you not trust me see Vampire/setup-wsl@887f39d, it is the same version for the workflow, do'nt worry

[oech3]

We absolutely believe this action and always bump when new version was released. So using commit hash does not improve anything.

[HackingRepo]

but if those actions compromised, what will say? that is the problem of using @v6.1.0 instead of a commit hash because unpinned, @v6.1.0 are mutable, but a commit hash can never change, do'nt worry dependabot will bump the commit hash, if there a good release @oech3, if new action version released dependabot will issue an update and update the commit hash

[oech3]

if those actions compromised, we install it at next update using commit hash.

[HackingRepo]

the risk is the Vampire just a maintener user, not a tech giant or an organization at least, mainteners are a very high target and if just the action compromised attackers will push malware and then will progogate to uutils.

[HackingRepo]

when a workflow compromised it is instantly wil trigger malicious code in uutils, please understand @oech3, if you do'nt understand how supply chain attack works, do'nt try to comment in the pr, view and there tons of issues open and fix them

[oech3]

So do you say that we have deadline to notice new malicious version before merging dependa bot's PR.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tail/retry (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tail/symlink (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/rm/many-dir-entries-vs-OOM is now passing!

[HackingRepo]

yes when using commit hashes, there a immutable until you merge dependabot update which change the commit hash with the new one, but when uisng a tag like v6.1.0 an attacker can point it to a malicious commit and endup malware even you not touch dependabot updates

[oech3]

Personally, wsl/devcontainer CI is not useful since it uses exactly same Ubuntu version with GitHub (no newer glibc).
I suggest to just drop them if they are not reliable.

[codspeed-hq]

Merging this PR will not alter performance

✅ 323 untouched benchmarks
⏩ 46 skipped benchmarks¹

---

_{Comparing HackingRepo:patch-1 (b62421b) with main (5a7774d)}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[kingthorin]

This is not the 7.0.0 SHA

https://github.com/actions/checkout/releases/tag/v7.0.0

[kingthorin]

This does appear to be the 6.1.0 SHA, however note version 7 is now available.

[kingthorin]

• https://github.com/Vampire/setup-wsl/releases/tag/v6.1.0
• https://github.com/Vampire/setup-wsl/releases/tag/v7.0.0

[HackingRepo]

ok it was 9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0

[kingthorin]

Instead of depending on manual PRs I'd suggest the project simply setup dependabot for GitHub actions.

.github/dependabot.yml
⬇️

# Please see the documentation for all configuration options:
# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

version: 2
updates:
  - package-ecosystem: "github-actions" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "daily"
    groups:
      dependencies:
        applies-to: version-updates
        patterns:
        - "*"

Workflows can still use SHA and document version which will both be updated by dependabot, ex:

• uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
• uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6.3.0

[HackingRepo]

however the project use renovabot, not dependabot

[kingthorin]

It can use both, plenty of other projects do.

[sylvestre]

i still don't see the value of this change, sorry :/
using hash requires more investigations then versions
and using versions has small risks (if someone is able to change the version in a project, they can do a lot of things)

[HackingRepo]

ok so, sylevestre, is i will close the pr, maybe yes, but, the project need supply chain security hygienes, like if a renovabot pr arrived, we need wait 12 hours at least to prevent the project endup integrating malware because if a rust dev crates.io account compromised, all that possible in that time, and with some crates, will lead to the malicious version, so at least at good, wait, do not fast merge renovabot prs just in minutes and other supply chain security praticses, you choose, so i will close that