build(deps): bump stefanbuck/github-issue-parser from 2.0.4 to 3.0.1

[dependabot]

Bumps stefanbuck/github-issue-parser from 2.0.4 to 3.0.1.

Release notes

Sourced from stefanbuck/github-issue-parser's releases.

v3.0.1

What's Changed

• feat: add issue-body default by @​joshjohanning in stefanbuck/github-issue-parser#47

New Contributors

• @​joshjohanning made their first contribution in stefanbuck/github-issue-parser#36

Full Changelog: stefanbuck/github-issue-parser@v3.0.0...v3.0.1

v3.0.0

3.0.0 (2022-10-19)

Bug Fixes

• deps: bump @​actions/core from 1.9.1 to 1.10.0 (284e5eb)
• Ensure releases can be pinned to SHAs #23 (#39) (428eec3)

Features

• mitigating script injection attacks by passing issue body as env var (#42) (0b27d4a)

BREAKING CHANGES

• Add issue-body argument which is required from v3 onwards

To mitigate script injection attacks, github-issue-parser v3 will require workflow authors to pass the issue body as an argument. By doing so you will follow GitHub's Good practices for mitigating script injection attacks

- uses: stefanbuck/github-issue-parser@v3
  id: issue-parser
  with:
    issue-body: ${{ github.event.issue.body }} # required
    template-path: .github/ISSUE_TEMPLATE/bug-report.yml # optional but recommended

• New checkboxes parsing (#21) (1d341cb)

The previous checkbox output produced this:

 {
    "laravel": true,
    "svelte": true,
 }

whereas the new output will be an array like this

</tr></table> 

... (truncated)

Commits

• c1a559d build
• 741688b feat: add issue-body default (#47)
• de423fc docs: Add migration section
• 0b27d4a feat: mitigating script injection attacks by passing issue body as env var (#42)
• 1d341cb feat: parse checkboxes (#21)
• 284e5eb fix(deps): bump @​actions/core from 1.9.1 to 1.10.0
• 9a9657d build(deps-dev): bump jest from 29.0.1 to 29.1.2
• f87cd98 Add snyk and version badge
• 4e72cf0 doc: Add example advanced-issue-labeler (#40)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[evverx]

I happened to go over the Dependabot logs and found this weird error message:

updater | 2024/03/31 21:22:13 ERROR <job_807574419> Error processing stefanbuck/github-issue-parser (Dependabot::SharedHelpers::HelperSubprocessFailed)
updater | 2024/03/31 21:22:13 ERROR <job_807574419> error: no such commit c1a559d78bfb8dd05216dab9ffd2b91082ff5324

That commit doesn't exist in the repository so apparently the action pulls stefanbuck/github-issue-parser@c1a559d and that doesn't look right :-)

[evverx]

To judge from stefanbuck/github-issue-parser#70 (comment) 3.0.1 was created manually and didn't belong to the master branch when this PR was opened. It was then rereleased with semantic-release properly as far as I understand.

(It's kind of concerning that Dependabot happily opens PRs pointing actions to commits like that and then keeps using them)

[mrc0mmand]

To judge from stefanbuck/github-issue-parser#70 (comment) 3.0.1 was created manually and didn't belong to the master branch when this PR was opened. It was then rereleased with semantic-release properly as far as I understand.

(It's kind of concerning that Dependabot happily opens PRs pointing actions to commits like that and then keeps using them)

They should probably rename Dependabot to SCAaaS (Supply chain attack as a Service) ;)

But jokes aside, this behavior is indeed concerning.

[evverx]

This sort of thing (without Dependabot involved) was reported in https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd and in response GitHub fixed the documentation :-)

Anyway it seems it should be fine to point the action to stefanbuck/github-issue-parser@1e5bdee and wait for it to be fully compatible with SHAs. I think that action comes with issues: write only. If it was contents: write I would be concerned :-)

[mrc0mmand]

This sort of thing (without Dependabot involved) was reported in https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd and in response GitHub fixed the documentation :-)

Anyway it seems it should be fine to point the action to stefanbuck/github-issue-parser@1e5bdee and wait for it to be fully compatible with SHAs. I think that action comes with issues: write only. If it was contents: write I would be concerned :-)

I bumped the SHA to v3.1.0 in #32050. It would be great if this could be caught somewhat automagically (like you've already proposed in ossf/scorecard#2733).

[evverx]

It would be great if this could be caught somewhat automagically

Ideally it should be possible to turn off that "feature" but it isn't going to happen.

As far as I can remember it wasn't doable because of the GitHub API rate limits. The Google folks were planning to integrate it into their cron job (which doesn't help to prevent that sort of thing in the first place) but since that cron job is responsible for scanning a lot of projects it was most likely to be banned too so it all kind of stalled. It's just so deeply ingrained in GitHub so it seems it's neither fixable nor easily detectable when it happens.