chore(deps): bump the actions group with 4 updates

[dependabot]

Bumps the actions group with 4 updates: Glyndor/.github/.github/workflows/shell-ci.yml, Glyndor/.github/.github/workflows/dco.yml, Glyndor/.github/.github/workflows/line-limit.yml and Glyndor/.github/.github/workflows/workflow-lint.yml.

Updates Glyndor/.github/.github/workflows/shell-ci.yml from 1.12.0 to 1.13.0

Release notes

Sourced from Glyndor/.github/.github/workflows/shell-ci.yml's releases.

v1.13.0

shell-ci and workflow-lint: the shellcheck download is verified

These two were the only places in this repository that trusted the transport. Both fetched the shellcheck tarball over HTTPS and piped it straight into tar, which extracts the bytes as they arrive — there was never a point at which anything could have been checked. Every other tool here comes through a registry that vouches for what it hands over: Go's sumdb, crates.io, PyPI.

The tarball now lands in a file and is verified with sha256sum -c before extraction.

New input shellcheck-sha256, defaulting to the hash of the pinned v0.11.0 tarball, so nothing changes for a caller that does not override the version:

uses: Glyndor/.github/.github/workflows/shell-ci.yml@<sha> # v1.13.0
with:
  shellcheck-version: "v0.11.0"
  shellcheck-sha256: "8c3be12b05d5c177a04c29e3c78ce89ac86f1595681cab149b65b97c4e227198"

If you pin shellcheck-version yourself, set shellcheck-sha256 alongside it. The two travel together on purpose: a version bump without its hash now fails the install instead of quietly downloading something unverified. No caller in the org overrides the version today, which is why this is a minor and not a major.

What the hash does and does not buy is worth stating plainly. koalaman publishes no checksum file and no signatures with the release — seven tarballs and nothing else — so this pins the artefact I measured rather than one upstream attests to. It detects a replaced or re-uploaded asset. It does not detect an upstream that was malicious from the start.

Verified by running the install script the way a runner does, as a standalone script rather than inside an && list, where errexit is ignored: the correct hash extracts and reports 0.11.0, a wrong hash exits 1 with nothing extracted and the directory left empty.

This repository stops linting itself to a weaker standard

actionlint.yml, the self-CI, ran bare actionlint, whose embedded shellcheck pass then fell back to whatever floating version the runner image ships — exactly what the workflow-lint reusable installs a pinned one to avoid. It now installs and verifies the same pinned binary and passes it through -shellcheck.

Also

The docs generator no longer reads its blocks through a secrets lookup, which had CodeQL reporting the generated pages as clear-text storage of secret data. The pages it produces are unchanged.

Commits

• e61aaf0 ci: verify the shellcheck download instead of trusting the transport (#108)
• d604dd8 fix: read the documented workflow_call blocks without a secrets lookup (#107)
• See full diff in compare view

Updates Glyndor/.github/.github/workflows/dco.yml from 1.12.0 to 1.13.0

Release notes

Sourced from Glyndor/.github/.github/workflows/dco.yml's releases.

v1.13.0

shell-ci and workflow-lint: the shellcheck download is verified

These two were the only places in this repository that trusted the transport. Both fetched the shellcheck tarball over HTTPS and piped it straight into tar, which extracts the bytes as they arrive — there was never a point at which anything could have been checked. Every other tool here comes through a registry that vouches for what it hands over: Go's sumdb, crates.io, PyPI.

The tarball now lands in a file and is verified with sha256sum -c before extraction.

New input shellcheck-sha256, defaulting to the hash of the pinned v0.11.0 tarball, so nothing changes for a caller that does not override the version:

uses: Glyndor/.github/.github/workflows/shell-ci.yml@<sha> # v1.13.0
with:
  shellcheck-version: "v0.11.0"
  shellcheck-sha256: "8c3be12b05d5c177a04c29e3c78ce89ac86f1595681cab149b65b97c4e227198"

If you pin shellcheck-version yourself, set shellcheck-sha256 alongside it. The two travel together on purpose: a version bump without its hash now fails the install instead of quietly downloading something unverified. No caller in the org overrides the version today, which is why this is a minor and not a major.

What the hash does and does not buy is worth stating plainly. koalaman publishes no checksum file and no signatures with the release — seven tarballs and nothing else — so this pins the artefact I measured rather than one upstream attests to. It detects a replaced or re-uploaded asset. It does not detect an upstream that was malicious from the start.

Verified by running the install script the way a runner does, as a standalone script rather than inside an && list, where errexit is ignored: the correct hash extracts and reports 0.11.0, a wrong hash exits 1 with nothing extracted and the directory left empty.

This repository stops linting itself to a weaker standard

actionlint.yml, the self-CI, ran bare actionlint, whose embedded shellcheck pass then fell back to whatever floating version the runner image ships — exactly what the workflow-lint reusable installs a pinned one to avoid. It now installs and verifies the same pinned binary and passes it through -shellcheck.

Also

The docs generator no longer reads its blocks through a secrets lookup, which had CodeQL reporting the generated pages as clear-text storage of secret data. The pages it produces are unchanged.

Commits

• e61aaf0 ci: verify the shellcheck download instead of trusting the transport (#108)
• d604dd8 fix: read the documented workflow_call blocks without a secrets lookup (#107)
• See full diff in compare view

Updates Glyndor/.github/.github/workflows/line-limit.yml from 1.12.0 to 1.13.0

Release notes

Sourced from Glyndor/.github/.github/workflows/line-limit.yml's releases.

v1.13.0

shell-ci and workflow-lint: the shellcheck download is verified

These two were the only places in this repository that trusted the transport. Both fetched the shellcheck tarball over HTTPS and piped it straight into tar, which extracts the bytes as they arrive — there was never a point at which anything could have been checked. Every other tool here comes through a registry that vouches for what it hands over: Go's sumdb, crates.io, PyPI.

The tarball now lands in a file and is verified with sha256sum -c before extraction.

New input shellcheck-sha256, defaulting to the hash of the pinned v0.11.0 tarball, so nothing changes for a caller that does not override the version:

uses: Glyndor/.github/.github/workflows/shell-ci.yml@<sha> # v1.13.0
with:
  shellcheck-version: "v0.11.0"
  shellcheck-sha256: "8c3be12b05d5c177a04c29e3c78ce89ac86f1595681cab149b65b97c4e227198"

If you pin shellcheck-version yourself, set shellcheck-sha256 alongside it. The two travel together on purpose: a version bump without its hash now fails the install instead of quietly downloading something unverified. No caller in the org overrides the version today, which is why this is a minor and not a major.

What the hash does and does not buy is worth stating plainly. koalaman publishes no checksum file and no signatures with the release — seven tarballs and nothing else — so this pins the artefact I measured rather than one upstream attests to. It detects a replaced or re-uploaded asset. It does not detect an upstream that was malicious from the start.

Verified by running the install script the way a runner does, as a standalone script rather than inside an && list, where errexit is ignored: the correct hash extracts and reports 0.11.0, a wrong hash exits 1 with nothing extracted and the directory left empty.

This repository stops linting itself to a weaker standard

actionlint.yml, the self-CI, ran bare actionlint, whose embedded shellcheck pass then fell back to whatever floating version the runner image ships — exactly what the workflow-lint reusable installs a pinned one to avoid. It now installs and verifies the same pinned binary and passes it through -shellcheck.

Also

The docs generator no longer reads its blocks through a secrets lookup, which had CodeQL reporting the generated pages as clear-text storage of secret data. The pages it produces are unchanged.

Commits

• e61aaf0 ci: verify the shellcheck download instead of trusting the transport (#108)
• d604dd8 fix: read the documented workflow_call blocks without a secrets lookup (#107)
• See full diff in compare view

Updates Glyndor/.github/.github/workflows/workflow-lint.yml from 1.12.0 to 1.13.0

Release notes

Sourced from Glyndor/.github/.github/workflows/workflow-lint.yml's releases.

v1.13.0

shell-ci and workflow-lint: the shellcheck download is verified

These two were the only places in this repository that trusted the transport. Both fetched the shellcheck tarball over HTTPS and piped it straight into tar, which extracts the bytes as they arrive — there was never a point at which anything could have been checked. Every other tool here comes through a registry that vouches for what it hands over: Go's sumdb, crates.io, PyPI.

The tarball now lands in a file and is verified with sha256sum -c before extraction.

New input shellcheck-sha256, defaulting to the hash of the pinned v0.11.0 tarball, so nothing changes for a caller that does not override the version:

uses: Glyndor/.github/.github/workflows/shell-ci.yml@<sha> # v1.13.0
with:
  shellcheck-version: "v0.11.0"
  shellcheck-sha256: "8c3be12b05d5c177a04c29e3c78ce89ac86f1595681cab149b65b97c4e227198"

If you pin shellcheck-version yourself, set shellcheck-sha256 alongside it. The two travel together on purpose: a version bump without its hash now fails the install instead of quietly downloading something unverified. No caller in the org overrides the version today, which is why this is a minor and not a major.

What the hash does and does not buy is worth stating plainly. koalaman publishes no checksum file and no signatures with the release — seven tarballs and nothing else — so this pins the artefact I measured rather than one upstream attests to. It detects a replaced or re-uploaded asset. It does not detect an upstream that was malicious from the start.

Verified by running the install script the way a runner does, as a standalone script rather than inside an && list, where errexit is ignored: the correct hash extracts and reports 0.11.0, a wrong hash exits 1 with nothing extracted and the directory left empty.

This repository stops linting itself to a weaker standard

actionlint.yml, the self-CI, ran bare actionlint, whose embedded shellcheck pass then fell back to whatever floating version the runner image ships — exactly what the workflow-lint reusable installs a pinned one to avoid. It now installs and verifies the same pinned binary and passes it through -shellcheck.

Also

The docs generator no longer reads its blocks through a secrets lookup, which had CodeQL reporting the generated pages as clear-text storage of secret data. The pages it produces are unchanged.

Commits

• e61aaf0 ci: verify the shellcheck download instead of trusting the transport (#108)
• d604dd8 fix: read the documented workflow_call blocks without a secrets lookup (#107)
• 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 show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions