chore(deps): bump Glyndor/.github/.github/workflows/main-guard.yml from 1.2.0 to 1.13.0

[dependabot]

Bumps Glyndor/.github/.github/workflows/main-guard.yml from 1.2.0 to 1.13.0.

Release notes

Sourced from Glyndor/.github/.github/workflows/main-guard.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.

v1.12.0

go-ci: an optional per-package coverage floor

New input per-package-coverage-threshold, defaulting to 0, so nothing changes for a caller until it opts in.

An aggregate threshold on a module whose packages differ in risk rewards covering the easy ones. authcore ran at 91% against a gate of 90 while its OIDC client sat at 87.7% and the package persisting its Ed25519 keys at 85.7% — the two with the most attack surface were the two thinnest, paid for by a fully covered clock helper.

uses: Glyndor/.github/.github/workflows/go-ci.yml@<sha> # v1.12.0
with:
  coverage-threshold: 90
  per-package-coverage-threshold: 90

Failing packages are named individually with an ::error:: annotation, and the per-package table lands in the job summary.

Adopt it when every package already clears the floor — that locks in a state that holds instead of demanding new work. Before relying on it, check the per-package numbers are not an artefact of helpers being exercised from a sibling package: comparing an isolated profile against -coverpkg=./... is the measurement, and on authcore it moved packages by +0.5 and +0.0.

go-fuzz: the corpus persists between runs

... (truncated)

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)
• 045903b feat: per-package coverage floor, and a fuzz corpus that persists (#106)
• 41d31f1 feat: make a stalled cron fail a check, and keep fuzz reproducers (#105)
• b0da280 docs: generate a page per reusable, with the check names it emits (#104)
• 8857ed7 ci: record why there is no Dependabot cooldown (#103)
• b159fa2 ci: re-register Dependabot and record why the file is the switch (#102)
• f7491b3 docs: list powershell-ci, release-verify and workflow-lint, and pin the examp...
• 7099f8a chore: bump the actions group with 2 updates (#100)
• c372b79 docs: drop the em dashes and diagram how a reusable change propagates (#99)
• Additional commits viewable 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 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)