From a17924472795c58e4d35d4ae044b9267681d2e7e Mon Sep 17 00:00:00 2001 From: Jaro-c <75870284+Jaro-c@users.noreply.github.com> Date: Sun, 26 Jul 2026 23:27:08 -0500 Subject: [PATCH 1/3] feat(go-fuzz): keep the input that caused a crash MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A fuzz find is only useful if the input survives. `go test -fuzz` writes it under /testdata/fuzz// in the workspace and the runner is destroyed moments later, so today a crash degrades into log text somebody has to retype. Uploading it on failure means the file can be dropped into the repository's testdata, which is what turns a find into a permanent regression case. The artifact name carries the job index because a func name is not unique across packages — two of authcore's modules both declare FuzzValidateAndNormalize — and artifact names must not collide. Missing files are ignored so that a build failure, which leaves no corpus entry, does not stack a second confusing error on the first. Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com> --- .github/workflows/go-fuzz.yml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/.github/workflows/go-fuzz.yml b/.github/workflows/go-fuzz.yml index 8164d46..4a9883f 100644 --- a/.github/workflows/go-fuzz.yml +++ b/.github/workflows/go-fuzz.yml @@ -57,3 +57,23 @@ jobs: PACKAGE: ${{ matrix.package }} FUZZTIME: ${{ inputs.fuzztime }} run: go test -run='^$' -fuzz="^${FUNC}\$" -fuzztime="$FUZZTIME" "$PACKAGE" + + # A crash is only useful if the input that caused it survives. `go test + # -fuzz` writes it under /testdata/fuzz// in the + # workspace, and the runner is destroyed moments later — so without this + # the find degrades into log text that somebody has to retype. With the + # file in hand, dropping it into the repository's testdata turns the crash + # into a permanent regression case. + # + # The name carries the job index because a func name is not unique across + # packages (two modules can both declare FuzzValidateAndNormalize) and + # artifact names must not collide. + - name: Upload the failing input + if: failure() + uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 + with: + name: fuzz-failure-${{ matrix.func }}-${{ strategy.job-index }} + path: ${{ inputs.working-directory }}/**/testdata/fuzz/** + # A build or vet failure also lands here and leaves no corpus entry; + # that is not worth a second, confusing failure on top of the first. + if-no-files-found: ignore From 0c615b27eb8485554ac1506e4a0509e813444a47 Mon Sep 17 00:00:00 2001 From: Jaro-c <75870284+Jaro-c@users.noreply.github.com> Date: Sun, 26 Jul 2026 23:27:08 -0500 Subject: [PATCH 2/3] feat(schedule-freshness): make a stalled cron fail a check Every other guard here is an assertion that fails loudly. A cron that stops firing is the exception: it emits nothing, and no alert reads exactly like all clear. That is not hypothetical. Every scheduled workflow in the org stopped on 2026-06-29. podup and apt came back on 07-15 because they happened to get activity and a disable/enable cycle, and I recorded the incident as resolved. Sweeping all seventeen repositories on 07-26 showed authcore, epistle, unitpm and glyndor.net had been dark for four more weeks, every one of them reporting active the whole time. It cost a real finding: authcore's GO-2026-5856 came from running govulncheck by hand, not from the weekly audit that exists to catch it. So a repository can now assert freshness from its ordinary CI, where the absence of a scheduled run turns into a red check on everyday work. It is the shape apt already uses, where ValidFor expires the archive rather than letting it serve a frozen snapshot when the pipeline stalls. The job reads run history with the workflow's own GITHUB_TOKEN. That is a scoped job token on its own rate limit, not the maintainer's credentials, which is the documented exception to the gh api ban. Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com> --- .github/workflows/schedule-freshness.yml | 93 ++++++++++++++++++++++++ docs/reusables/README.md | 1 + docs/reusables/schedule-freshness.md | 39 ++++++++++ 3 files changed, 133 insertions(+) create mode 100644 .github/workflows/schedule-freshness.yml create mode 100644 docs/reusables/schedule-freshness.md diff --git a/.github/workflows/schedule-freshness.yml b/.github/workflows/schedule-freshness.yml new file mode 100644 index 0000000..6260599 --- /dev/null +++ b/.github/workflows/schedule-freshness.yml @@ -0,0 +1,93 @@ +name: Schedule freshness (reusable) + +# Fails when a scheduled workflow has not succeeded recently enough. +# +# Every other guard in this organisation is an assertion that fails loudly. A +# cron that stops firing is the exception: it emits nothing at all, and "no +# alert" is indistinguishable from "all clear". On 2026-06-29 every scheduled +# workflow in the org stopped. podup and apt recovered on 07-15 because they +# happened to get activity and a disable/enable cycle; authcore, epistle, unitpm +# and glyndor.net stayed dark for four more weeks, all of them reporting +# `active` the whole time. It cost a real finding — authcore's GO-2026-5856 was +# caught by a hand-run of govulncheck, not by the weekly audit that exists for +# exactly that. +# +# Call this from a workflow that already runs often (normal CI) so the absence +# of a scheduled run becomes a red check on ordinary work. It is the same idea +# as apt's `ValidFor: 14d`, which expires the archive rather than letting it +# serve a frozen snapshot when the pipeline stalls. +# +# Add the check only once the schedule has fired successfully at least once — +# with no successful run on record there is nothing to measure and the job +# reports that as a failure, which for an established workflow is exactly right. + +on: + workflow_call: + inputs: + workflow: + description: >- + File name of the scheduled workflow to check, e.g. "audit.yml". + type: string + required: true + max-age-days: + description: >- + Fail when the newest successful scheduled run is older than this. + Allow about two periods, so a weekly job tolerates one miss: 15 for a + weekly schedule, 3 for a daily one. + type: number + required: true + +permissions: + contents: read + +concurrency: + group: schedule-freshness-${{ github.workflow }}-${{ github.ref }}-${{ inputs.workflow }} + cancel-in-progress: true + +jobs: + freshness: + name: schedule freshness + runs-on: ubuntu-latest + permissions: + actions: read # reading this repository's workflow-run history + steps: + # `gh api` is banned for the maintainer's own credentials — the org + # account has been suspended over raw API traffic before. A workflow is a + # different actor: GITHUB_TOKEN is a scoped job token on its own rate + # limit, which is the documented exception. + - name: Check the newest successful scheduled run + env: + GH_TOKEN: ${{ github.token }} + REPO: ${{ github.repository }} + WORKFLOW: ${{ inputs.workflow }} + MAX_AGE_DAYS: ${{ inputs.max-age-days }} + run: | + set -euo pipefail + + latest=$(gh api \ + "repos/${REPO}/actions/workflows/${WORKFLOW}/runs?event=schedule&status=success&per_page=1" \ + --jq '.workflow_runs[0].created_at // empty') + + if [ -z "$latest" ]; then + echo "::error::No successful scheduled run on record for ${WORKFLOW}." + echo "Either its cron has never fired, or the schedule was dropped." >&2 + echo "Check that the workflow still exists on the default branch, then" >&2 + echo "toggle it: gh workflow disable ${WORKFLOW} && gh workflow enable ${WORKFLOW}" >&2 + exit 1 + fi + + age_seconds=$(( $(date -u +%s) - $(date -u -d "$latest" +%s) )) + age_days=$(( age_seconds / 86400 )) + + echo "Newest successful scheduled run of ${WORKFLOW}: ${latest} (${age_days}d ago)." + + if [ "$age_days" -gt "$MAX_AGE_DAYS" ]; then + echo "::error::${WORKFLOW} last succeeded on a schedule ${age_days} days ago, over the ${MAX_AGE_DAYS}-day limit." + echo "A schedule that stops firing reports nothing, so treat this as the alert it never sent." >&2 + echo "GitHub runs crons hours late, so a small overrun right at the boundary is not the problem;" >&2 + echo "a multiple of the period is. Toggle the workflow off and on to re-register it, then check" >&2 + echo "the next scheduled fire rather than the next few minutes." >&2 + exit 1 + fi + + echo "Within the ${MAX_AGE_DAYS}-day limit." diff --git a/docs/reusables/README.md b/docs/reusables/README.md index 67b7bf4..358ac2e 100644 --- a/docs/reusables/README.md +++ b/docs/reusables/README.md @@ -24,6 +24,7 @@ which blocks every pull request until someone works out why. | [`rust-debian`](rust-debian.md) | 2 | 1 | 8 | | [`rust-fuzz`](rust-fuzz.md) | 1 | 0 | 7 | | [`rust-supply-chain`](rust-supply-chain.md) | 1 | 0 | 5 | +| [`schedule-freshness`](schedule-freshness.md) | 1 | 0 | 2 | | [`shell-ci`](shell-ci.md) | 2 | 1 | 5 | | [`workflow-lint`](workflow-lint.md) | 1 | 0 | 1 | diff --git a/docs/reusables/schedule-freshness.md b/docs/reusables/schedule-freshness.md new file mode 100644 index 0000000..ce3700c --- /dev/null +++ b/docs/reusables/schedule-freshness.md @@ -0,0 +1,39 @@ +# schedule-freshness + +Fails when a scheduled workflow has not succeeded recently enough. Every other guard in this organisation is an assertion that fails loudly. A cron that stops firing is the exception: it emits nothing at all, and "no alert" is indistinguishable from "all clear". On 2026-06-29 every scheduled workflow in the org stopped. podup and apt recovered on 07-15 because they happened to get activity and a disable/enable cycle; authcore, epistle, unitpm and glyndor.net stayed dark for four more weeks, all of them reporting `active` the whole time. It cost a real finding — authcore's GO-2026-5856 was caught by a hand-run of govulncheck, not by the weekly audit that exists for exactly that. Call this from a workflow that already runs often (normal CI) so the absence of a scheduled run becomes a red check on ordinary work. It is the same idea as apt's `ValidFor: 14d`, which expires the archive rather than letting it serve a frozen snapshot when the pipeline stalls. Add the check only once the schedule has fired successfully at least once — with no successful run on record there is nothing to measure and the job reports that as a failure, which for an established workflow is exactly right. + +## Calling it + +```yaml +# .github/workflows/ci.yml in the consuming repository +jobs: + example: + uses: Glyndor/.github/.github/workflows/schedule-freshness.yml@ # vX.Y.Z +``` + +Pin to a release commit SHA with the version in a comment. Never track a +branch: the SHA pin is what stops a change here reaching a repository +before that repository's own CI has passed on it. + +## Status checks it emits + +The name a consumer sees is ` / `, where `example` is +the caller's job id from the snippet above — a repository that names its job +`rust` sees `rust / …` instead. **These are the strings a ruleset matches**, and +a required check whose name nothing emits blocks every pull request. + +| Check | Emitted when | +|---|---| +| `example / schedule freshness` | always | + +## Inputs + +| Input | Type | Default | Required | Description | +|---|---|---|---|---| +| `workflow` | string | — | yes | File name of the scheduled workflow to check, e.g. "audit.yml". | +| `max-age-days` | number | — | yes | Fail when the newest successful scheduled run is older than this. Allow about two periods, so a weekly job tolerates one miss: 15 for a weekly schedule, 3 for a daily one. | + +--- + +Generated from `.github/workflows/schedule-freshness.yml` by `scripts/render-reusable-docs.py`. +Edit the workflow, not this page. From 86532aaf0963099b06b186a1a31381f72b0b7415 Mon Sep 17 00:00:00 2001 From: Jaro-c <75870284+Jaro-c@users.noreply.github.com> Date: Sun, 26 Jul 2026 23:29:11 -0500 Subject: [PATCH 3/3] docs(schedule-freshness): say that the caller must grant actions: read A called workflow cannot elevate beyond the permissions of the workflow that calls it, so a caller granting only contents: read makes the run fail before it starts, with no logs to explain why. I hit exactly that wiring it into authcore. Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com> --- .github/workflows/schedule-freshness.yml | 4 ++++ docs/reusables/schedule-freshness.md | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/.github/workflows/schedule-freshness.yml b/.github/workflows/schedule-freshness.yml index 6260599..b6d6031 100644 --- a/.github/workflows/schedule-freshness.yml +++ b/.github/workflows/schedule-freshness.yml @@ -17,6 +17,10 @@ name: Schedule freshness (reusable) # as apt's `ValidFor: 14d`, which expires the archive rather than letting it # serve a frozen snapshot when the pipeline stalls. # +# The caller must grant `actions: read` alongside `contents: read`: a called +# workflow cannot elevate beyond the permissions of the workflow that calls it, +# and reading run history needs that scope. Without it the run does not start. +# # Add the check only once the schedule has fired successfully at least once — # with no successful run on record there is nothing to measure and the job # reports that as a failure, which for an established workflow is exactly right. diff --git a/docs/reusables/schedule-freshness.md b/docs/reusables/schedule-freshness.md index ce3700c..8caa67f 100644 --- a/docs/reusables/schedule-freshness.md +++ b/docs/reusables/schedule-freshness.md @@ -1,6 +1,6 @@ # schedule-freshness -Fails when a scheduled workflow has not succeeded recently enough. Every other guard in this organisation is an assertion that fails loudly. A cron that stops firing is the exception: it emits nothing at all, and "no alert" is indistinguishable from "all clear". On 2026-06-29 every scheduled workflow in the org stopped. podup and apt recovered on 07-15 because they happened to get activity and a disable/enable cycle; authcore, epistle, unitpm and glyndor.net stayed dark for four more weeks, all of them reporting `active` the whole time. It cost a real finding — authcore's GO-2026-5856 was caught by a hand-run of govulncheck, not by the weekly audit that exists for exactly that. Call this from a workflow that already runs often (normal CI) so the absence of a scheduled run becomes a red check on ordinary work. It is the same idea as apt's `ValidFor: 14d`, which expires the archive rather than letting it serve a frozen snapshot when the pipeline stalls. Add the check only once the schedule has fired successfully at least once — with no successful run on record there is nothing to measure and the job reports that as a failure, which for an established workflow is exactly right. +Fails when a scheduled workflow has not succeeded recently enough. Every other guard in this organisation is an assertion that fails loudly. A cron that stops firing is the exception: it emits nothing at all, and "no alert" is indistinguishable from "all clear". On 2026-06-29 every scheduled workflow in the org stopped. podup and apt recovered on 07-15 because they happened to get activity and a disable/enable cycle; authcore, epistle, unitpm and glyndor.net stayed dark for four more weeks, all of them reporting `active` the whole time. It cost a real finding — authcore's GO-2026-5856 was caught by a hand-run of govulncheck, not by the weekly audit that exists for exactly that. Call this from a workflow that already runs often (normal CI) so the absence of a scheduled run becomes a red check on ordinary work. It is the same idea as apt's `ValidFor: 14d`, which expires the archive rather than letting it serve a frozen snapshot when the pipeline stalls. The caller must grant `actions: read` alongside `contents: read`: a called workflow cannot elevate beyond the permissions of the workflow that calls it, and reading run history needs that scope. Without it the run does not start. Add the check only once the schedule has fired successfully at least once — with no successful run on record there is nothing to measure and the job reports that as a failure, which for an established workflow is exactly right. ## Calling it