chore: run owfeed v0.5.4

.github/workflows/intake.yml

@@ -29,7 +29,7 @@ jobs:
 
       # No `version:`: since owfeed v0.5.3 setup installs the release it is pinned
       # at, so this line is the whole pin and a dependabot bump moves the binary too.
-      - uses: owfeed/owfeed/setup@v0.5.3
+      - uses: owfeed/owfeed/setup@v0.5.4
 
       - name: Read the request and answer it
         env:

.github/workflows/pr.yml

@@ -117,7 +117,7 @@ jobs:
     # tagged with, so this line is the whole pin. It used to be a second pin
     # beside it, and dependabot moved only this one -- the feed ran feed.yml@v0.5.1
     # with an owfeed v0.4.5 binary from #65 until this line was fixed.
-    uses: owfeed/owfeed/.github/workflows/feed.yml@v0.5.3
+    uses: owfeed/owfeed/.github/workflows/feed.yml@v0.5.4
     with:
       dry-run: true
       pre-build: for d in packages/*/; do ./tools/fetch.sh "$d"; done

.github/workflows/publish.yml

@@ -38,7 +38,7 @@ jobs:
     # tagged with, so this line is the whole pin. It used to be a second pin
     # beside it, and dependabot moved only this one -- the feed ran feed.yml@v0.5.1
     # with an owfeed v0.4.5 binary from #65 until this line was fixed.
-    uses: owfeed/owfeed/.github/workflows/feed.yml@v0.5.3
+    uses: owfeed/owfeed/.github/workflows/feed.yml@v0.5.4
     # So the publish job can read OWFEED_SIGN_KEY and OWFEED_USIGN_KEY from the
     # `feed` environment. They are environment secrets, not repository ones --
     # the scheduled update job and every pull-request check are outside that scope

RUNBOOK.md

@@ -69,8 +69,8 @@ A merge or a push made with `GITHUB_TOKEN` raises no `push` event either, which
 dispatched rather than triggered. `workflow_dispatch` is the documented exception in both cases:
 those events always create runs.
 
-**How owfeed gets here.** `owfeed/owfeed/setup@v0.5.3`, pinned to a release. In `pr.yml` and
-`publish.yml` the pin is the `uses: .../feed.yml@v0.5.3` line alone: that workflow installs the
+**How owfeed gets here.** `owfeed/owfeed/setup@v0.5.4`, pinned to a release. In `pr.yml` and
+`publish.yml` the pin is the `uses: .../feed.yml@v0.5.4` line alone: that workflow installs the
 owfeed release it is tagged with, so do not add `owfeed-version:` back. The action downloads
 one binary and checks it against the build attestation from owfeed's own release workflow before
 running it — not against a checksum from the same release, which whoever replaced the binary could

RUNBOOK_ru.md

@@ -71,8 +71,8 @@ Push или мерж под `GITHUB_TOKEN` тоже не поднимает со
 вручную, а не по триггеру. `workflow_dispatch` — задокументированное исключение в обоих случаях:
 такие события всегда создают запуск.
 
-**Как сюда попадает owfeed.** `owfeed/owfeed/setup@v0.5.3`, пин на релиз. В `pr.yml` и
-`publish.yml` пин — одна строка `uses: .../feed.yml@v0.5.3`: этот workflow ставит тот релиз owfeed,
+**Как сюда попадает owfeed.** `owfeed/owfeed/setup@v0.5.4`, пин на релиз. В `pr.yml` и
+`publish.yml` пин — одна строка `uses: .../feed.yml@v0.5.4`: этот workflow ставит тот релиз owfeed,
 которым помечен сам, поэтому `owfeed-version:` обратно не добавляйте. Action скачивает один
 бинарь и сверяет его с build-аттестацией из релизного workflow самого owfeed до запуска — не с
 контрольной суммой из того же релиза, которую тот, кто подменил бинарь, подменил бы заодно. Раньше

STATUS.md

@@ -25,7 +25,7 @@ it is the last time the URL has to move.
 | | Evidence |
 |---|---|
 | Feed updates reaching a router | Upstream released 0.14.10 → the update bot opened #51 with the pins recomputed → a maintainer approved the held check and merged it → `Publish` → the served 25.12 index carries `0.14.10-r1`, read from a router. That was the path before #61; the row below is the same journey without a person |
-| Publishing through owfeed's reusable workflow | `publish.yml` calls `feed.yml@v0.5.3` with `secrets: inherit`; a probe (at v0.5.0) measured that a called job's `environment: feed` resolves against this repository, and the signing secrets reached it at their real length |
+| Publishing through owfeed's reusable workflow | `publish.yml` calls `feed.yml@v0.5.4` with `secrets: inherit`; a probe (at v0.5.0) measured that a called job's `environment: feed` resolves against this repository, and the signing secrets reached it at their real length |
 | An author signature inside every package | `signing.author-keys: ./keys` in `owfeed.yml`, one EC public half pinned per package; an unsigned package is dropped from the index (OWF407) and `tools/check-tree.sh` then fails the publish, so a green publish is the evidence |
 | Automatic-update tier rules | Six scenarios exercised in a real git repository: manifest/minor merges, major bump holds, `binaries` holds, no `SIG_KEY` holds, a diff touching `SIG_KEY_ID` holds, the daily ceiling holds |
 | Verify before read | `tools/fetch.sh` checks the signature before parsing, and cross-checks `repo` and `tag` inside the manifest — the signature says *who*, never *what about* |

examples/gitlab-ci.yml

@@ -19,7 +19,7 @@ stages: [build, release]
 variables:
   # Pin a release. The tool that signs what you publish should move when you change
   # this line, not whenever owfeed is pushed to.
-  OWFEED_VERSION: "v0.5.3"
+  OWFEED_VERSION: "v0.5.4"
 
 build:
   stage: build