ci(kaniko): move alpine-jq to the maintained fork #664

2026-08-27T10:54:52Z

claude-bot commented

2026-08-27 10:54:52 +00:00

Du hattest recht, ich hatte „archiviert" als Todesurteil gelesen. Es ist eine Übergabe.

Google hat GoogleContainerTools/kaniko am 2025-06-03 archiviert — aber die ursprünglichen Autoren haben es zu chainguard-dev/kaniko geforkt und weiter released: aktuell v1.25.18, deutlich über der v1.24.0, bei der das Google-Repo endete. Die Prämisse in #552 („the version is now permanently frozen. No further security fixes will be published") stimmt damit nicht.

Also ein Image-Tausch, keine Migration. Kein buildah, kein BuildKit, kein securityContext, keine neun umgeschriebenen Build-Steps.

Die Fork veröffentlicht selbst keine Binaries, deshalb kommt das Image von gitlab-ci-utils, das aus genau dieser Fork für amd64 und arm64 mit Versions-Tags baut. Den generischen :debug-Tag habe ich bewusst nicht genommen — hier ist jede Image-Referenz gepinnt.

Geprüft, nicht gelesen. Image gezogen und laufen lassen:

-rwxr-xr-x  53039266  /kaniko/executor
Kaniko version :  v1.25.18
/bin/sh -> /busybox/sh
printf  /busybox/base64  /busybox/tr  /busybox/mkdir  /busybox/date

Gleicher Pfad, gleiche Flags, und die Utilities, an denen die Auth- und Tag-Zeilen hängen, sind alle da. Anonymer Pull funktioniert, also braucht es keine Registry-Credentials dafür.

Nur dieser eine Step. Eine Änderung an dieser Datei baut ohnehin alle Steps neu, also zeigt ein einziger Lauf den neuen Executor auf alpine-jq neben sieben unveränderten kaniko-Builds — A/B im selben Log. alpine-jq ist der kleinste Kontext hier, ein FROM und ein RUN. Die übrigen sieben plus ci-claude-refresh.yml folgen, sobald das grün ist.

Zwei Zahlen in #552 stimmen außerdem nicht: der Pin war überall v1.23.2-debug, nicht v1.24.0-debug (#551 hat Alpine gebumpt, nicht kaniko), und es sind acht Steps hier plus einer in ci-claude-refresh.yml — neun Aufrufe, nicht zehn.

Refs #552

Du hattest recht, ich hatte „archiviert" als Todesurteil gelesen. Es ist eine Übergabe. Google hat `GoogleContainerTools/kaniko` am 2025-06-03 archiviert — aber die ursprünglichen Autoren haben es zu `chainguard-dev/kaniko` geforkt und **weiter released**: aktuell **v1.25.18**, deutlich über der v1.24.0, bei der das Google-Repo endete. Die Prämisse in #552 („the version is now permanently frozen. No further security fixes will be published") stimmt damit nicht. Also ein Image-Tausch, keine Migration. Kein buildah, kein BuildKit, kein `securityContext`, keine neun umgeschriebenen Build-Steps. Die Fork veröffentlicht selbst keine Binaries, deshalb kommt das Image von `gitlab-ci-utils`, das aus genau dieser Fork für amd64 und arm64 mit Versions-Tags baut. Den generischen `:debug`-Tag habe ich bewusst nicht genommen — hier ist jede Image-Referenz gepinnt. **Geprüft, nicht gelesen.** Image gezogen und laufen lassen: ``` -rwxr-xr-x 53039266 /kaniko/executor Kaniko version : v1.25.18 /bin/sh -> /busybox/sh printf /busybox/base64 /busybox/tr /busybox/mkdir /busybox/date ``` Gleicher Pfad, gleiche Flags, und die Utilities, an denen die Auth- und Tag-Zeilen hängen, sind alle da. Anonymer Pull funktioniert, also braucht es keine Registry-Credentials dafür. **Nur dieser eine Step.** Eine Änderung an dieser Datei baut ohnehin alle Steps neu, also zeigt ein einziger Lauf den neuen Executor auf `alpine-jq` neben sieben unveränderten kaniko-Builds — A/B im selben Log. `alpine-jq` ist der kleinste Kontext hier, ein FROM und ein RUN. Die übrigen sieben plus `ci-claude-refresh.yml` folgen, sobald das grün ist. Zwei Zahlen in #552 stimmen außerdem nicht: der Pin war überall `v1.23.2-debug`, nicht `v1.24.0-debug` (#551 hat Alpine gebumpt, nicht kaniko), und es sind acht Steps hier plus einer in `ci-claude-refresh.yml` — neun Aufrufe, nicht zehn. Refs #552

claude-bot added 1 commit 2026-08-27 10:54:53 +00:00

ci(kaniko): move alpine-jq to the maintained fork

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/push/build-ci-images Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

4e040c5a2d

#552 concluded that kaniko is terminal and that the nine build steps need
migrating to buildah or BuildKit. The premise is wrong. Google archived
GoogleContainerTools/kaniko on 2025-06-03, but the original authors forked it to
chainguard-dev/kaniko and kept shipping: releases run to v1.25.18, well past the
v1.24.0 the Google repo ended on. Upstream moved, it did not die.

So this is an image swap, not a migration. Same /kaniko/executor, same flags,
nothing else in the step changes. The fork publishes no binaries of its own, so
the image comes from gitlab-ci-utils, which builds it from that fork for amd64
and arm64 with versioned tags — the generic :debug tag exists too and is
deliberately not used, since every other image reference here is pinned.

Verified by pulling the image and running it rather than by reading its README:
/kaniko/executor is at the same path and reports v1.25.18, /bin/sh is a symlink
into busybox, and printf, base64, tr, mkdir and date are all present — the
utilities the auth and tag lines depend on. Anonymous pull works, so no registry
credential is needed for it.

Only this one step moves. A change to this file rebuilds every step regardless,
so a single run puts the new executor on alpine-jq beside seven unchanged kaniko
builds and shows both in the same log. alpine-jq is the smallest context here,
one FROM and one RUN, and the remaining seven plus ci-claude-refresh.yml follow
once this is green.

Two counts in #552 are also wrong and worth correcting there: the pin was
v1.23.2-debug everywhere, not v1.24.0-debug — #551 bumped alpine, not kaniko —
and there are eight steps in this file plus one in ci-claude-refresh.yml, so
nine invocations rather than ten.

Refs #552

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

claude-bot referenced this pull request

2026-08-27 10:55:11 +00:00

kaniko is archived upstream — all CI image builds depend on an abandoned tool #552

review-bot reviewed

2026-08-27 10:58:40 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit 4e040c5a2dcd576343de40719557ac1dae963294.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Single-line functional change: .woodpecker/build-ci-images.yml's build-alpine-jq step now pulls its kaniko executor from registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug instead of the archived gcr.io/kaniko-project/executor:v1.23.2-debug, plus a 16-line comment explaining the rationale. Deliberately scoped to one of nine kaniko invocations as an A/B test before the rest follow. I verified the surrounding claims against the checkout (see below) and found no blocking issues.

🟡 Suggestions

Trust anchor moves to an unofficial third-party registry, on a mutable tag (.woodpecker/build-ci-images.yml:155). The old image came from Google's own gcr.io/kaniko-project namespace (archived, but Google-operated while it lasted). The new one is republished by an unrelated third party (gitlab-ci-utils) that isn't the upstream fork maintainer (chainguard-dev) either — it's a downstream rebuild. The PR body's manual verification (pulling the image, confirming /kaniko/executor, /bin/sh, base64, tr, mkdir, date are present) checks binary presence, but can't rule out anything else baked into the image, and a version tag like v1.25.18-debug is mutable — gitlab-ci-utils could silently repoint it later to a different image without changing the pipeline file. Since this step's GITEA_TOKEN secret is used inside the container to authenticate to the registry (line 168-169), a compromised or later-swapped image on that tag has a path to that credential (scoped to package: read+write per the file header at line 4-6, so the blast radius is limited — but not zero). Worth digest-pinning (@sha256:...) once the tag is confirmed stable, or at minimum re-verifying the digest each time before the remaining seven steps + ci-claude-refresh.yml are migrated.

Tests

No automated tests apply to Woodpecker pipeline YAML. The PR's own design is the test: only build-alpine-jq is switched, so the next push that touches this file will run the new executor next to seven unchanged kaniko builds in the same log, which is a reasonable way to validate the swap before rolling it out further. That's sufficient for this scope.

Verification notes

Confirmed in the checkout: all eight kaniko steps in build-ci-images.yml (before this change) and the one in ci-claude-refresh.yml:133 pin v1.23.2-debug, matching the PR body's correction of #552 (not v1.24.0-debug) and its step count (nine call sites total, not ten).
Confirmed the changed line is isolated to build-alpine-jq; the other seven gcr.io/kaniko-project/executor:v1.23.2-debug references in the file are untouched.
Could not independently verify the external claims (that chainguard-dev/kaniko is an active fork at v1.25.18, or that registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug exists and matches what's described) — this environment has no outbound network access. That's the one open item a maintainer should spot-check before merging, e.g. by pulling the tag themselves.

Recommendation

Looks reasonable — no blocking issues; the trust/mutability point above is worth a look before extending this to the remaining eight call sites, but doesn't block this scoped, single-step change.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `4e040c5a2dcd576343de40719557ac1dae963294`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Single-line functional change: `.woodpecker/build-ci-images.yml`'s `build-alpine-jq` step now pulls its kaniko executor from `registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug` instead of the archived `gcr.io/kaniko-project/executor:v1.23.2-debug`, plus a 16-line comment explaining the rationale. Deliberately scoped to one of nine kaniko invocations as an A/B test before the rest follow. I verified the surrounding claims against the checkout (see below) and found no blocking issues. ## 🟡 Suggestions - **Trust anchor moves to an unofficial third-party registry, on a mutable tag** (`.woodpecker/build-ci-images.yml:155`). The old image came from Google's own `gcr.io/kaniko-project` namespace (archived, but Google-operated while it lasted). The new one is republished by an unrelated third party (`gitlab-ci-utils`) that isn't the upstream fork maintainer (`chainguard-dev`) either — it's a downstream rebuild. The PR body's manual verification (pulling the image, confirming `/kaniko/executor`, `/bin/sh`, `base64`, `tr`, `mkdir`, `date` are present) checks binary presence, but can't rule out anything else baked into the image, and a version tag like `v1.25.18-debug` is mutable — `gitlab-ci-utils` could silently repoint it later to a different image without changing the pipeline file. Since this step's `GITEA_TOKEN` secret is used *inside* the container to authenticate to the registry (line 168-169), a compromised or later-swapped image on that tag has a path to that credential (scoped to `package: read+write` per the file header at line 4-6, so the blast radius is limited — but not zero). Worth digest-pinning (`@sha256:...`) once the tag is confirmed stable, or at minimum re-verifying the digest each time before the remaining seven steps + `ci-claude-refresh.yml` are migrated. ## Tests No automated tests apply to Woodpecker pipeline YAML. The PR's own design *is* the test: only `build-alpine-jq` is switched, so the next push that touches this file will run the new executor next to seven unchanged kaniko builds in the same log, which is a reasonable way to validate the swap before rolling it out further. That's sufficient for this scope. ## Verification notes - Confirmed in the checkout: all eight kaniko steps in `build-ci-images.yml` (before this change) and the one in `ci-claude-refresh.yml:133` pin `v1.23.2-debug`, matching the PR body's correction of #552 (not `v1.24.0-debug`) and its step count (nine call sites total, not ten). - Confirmed the changed line is isolated to `build-alpine-jq`; the other seven `gcr.io/kaniko-project/executor:v1.23.2-debug` references in the file are untouched. - Could not independently verify the external claims (that `chainguard-dev/kaniko` is an active fork at v1.25.18, or that `registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug` exists and matches what's described) — this environment has no outbound network access. That's the one open item a maintainer should spot-check before merging, e.g. by pulling the tag themselves. ## Recommendation Looks reasonable — no blocking issues; the trust/mutability point above is worth a look before extending this to the remaining eight call sites, but doesn't block this scoped, single-step change.

k.renner merged commit b03d0652c2 into master

2026-08-27 10:58:50 +00:00

k.renner referenced this issue from a commit

2026-08-27 10:58:50 +00:00

Merge pull request 'ci(kaniko): move alpine-jq to the maintained fork' (#664) from kaniko-replacement into master

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#664