ci: publish cryptify's image unconditionally now that GHCR grants postguard Write

[rubenhensen]

Summary

• Removes the if: vars.PUBLISH_CRYPTIFY_IMAGE == 'true' gate from build-cryptify, scan-cryptify and finalize-cryptify in delivery.yml, now that task: cut cryptify's Docker publish pipeline over to postguard, then retire the old repo's build #293's GHCR permission grant has landed and the repo variable is no longer needed to keep those jobs from failing on push.
• Updates the stale CLAUDE.md bullet describing the gated-off state.

Part of #293 (step 2 was originally "set the repo variable to true"; this does the equivalent by making the jobs unconditional instead, at the cost of losing the instant off-switch a variable would have given).

Note: encryption4all/cryptify's own ci.yml still pushes the same image tags today, so until its build/push steps are retired (#293's step 4, and #294's archive step), two pipelines are racing on the same GHCR tags.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[dobby-coder]

Thanks for the PR! I'm on it — reviewing the removal of the PUBLISH_CRYPTIFY_IMAGE gate across build-cryptify, scan-cryptify, and finalize-cryptify in delivery.yml, plus the CLAUDE.md update, and I'll factor in the noted GHCR tag race with cryptify's ci.yml. I'll follow up with a review shortly.

[dobby-coder]

Reviewed after the fact — this merged (2026-08-07 13:40Z) before the review cycle finished, so the sign-off is post-merge and nothing here needs a bounce.

The change does what it says. Removing the three if: vars.PUBLISH_CRYPTIFY_IMAGE == 'true' guards is the whole diff, the comment rewrite matches the new state, and the docs sweep is clean: a repo-wide grep for PUBLISH_CRYPTIFY_IMAGE at the merge state returns exactly one hit, the updated CLAUDE.md bullet, and it speaks in the past tense. No stale runbook left behind. Losing the instant off-switch is called out in the PR body rather than glossed over, which is the right trade to state explicitly.

Verified live rather than by reading: run 31182543032 (the PR's own pull_request run) and 31183728239 (the merge push) both ran Build cryptify / Scan cryptify image / Finalize cryptify manifest green, and ghcr.io/encryption4all/cryptify now carries edge pushed at 13:46:50Z. The grant is real and the pipeline publishes.

Two notes below, neither a defect in this diff — both are consequences of the jobs going live that are worth knowing before #293's step 4 lands.

One thing checked and cleared, so it doesn't get re-raised: build-cryptify having no if: at all means it builds and pushes on every pull_request too. That is not a divergence — the sibling pg-pkg build job has had exactly the same shape all along, so the cryptify jobs still mirror it as the header comment claims.

[dobby-coder]

Now that this runs on every event, the type=ref,event=pr tag on line 377 means each postguard PR writes a pr-<N> tag into ghcr.io/encryption4all/cryptify — a package two repos publish to, each with its own independent PR numbering.

That is already visible on the package: pr-309 (this PR, 13:32:19Z) sits next to pr-204, which came from encryption4all/cryptify#204, not from here — postguard has no PR #204. So the two number spaces overlap, and a future cryptify PR reaching #309 would land on the tag this PR's image holds.

The PR body's "two pipelines racing on the same tags" note covers edge and the version tags; this is a second, distinct collision in the pr-* namespace. Low stakes — PR tags are throwaway build artifacts and nothing deploys from them — and retiring cryptify's own build/push in #293's step 4 removes it along with the edge race. Worth naming so it isn't diagnosed from scratch if someone pulls a pr-* tag and gets the wrong codebase.

[dobby-coder]

scan-cryptify is in needs, but always() on the next line means only build-cryptify.result == 'success' is actually consulted — a failed scan does not stop the manifest push. scan-cryptify runs Grype with fail-build: true at severity-cutoff: critical, so a fixable critical CVE turns that job red and edge still gets published on top of the image.

This is not introduced here: finalize-docker is if: always() && needs.build.result == 'success' too, so the cryptify jobs mirror pg-pkg exactly, and while the gate was set the whole path was dead anyway. What this PR changes is that the behaviour is now live, on the package other deployments pull.

So it's worth deciding whether it's intended rather than inherited. If publishing should wait on a clean scan, needs.scan-cryptify.result == 'success' is the addition — for both image families, since splitting them would be worse than either choice. If it is intended (scan-as-signal, not scan-as-gate), a line saying so in the header comment would stop the next reader from filing it as a bug.

[dobby-coder]

Reviewed and approved — since this had already merged by the time I finished (2026-08-07 13:40Z), it's a post-merge sign-off: #309

The change itself checks out: the guard removal is clean, the CLAUDE.md sweep leaves no stale references, and I confirmed live that Build cryptify / Scan cryptify image / Finalize cryptify manifest ran green and ghcr.io/encryption4all/cryptify:edge published at 13:46:50Z.

Left two inline notes for later, neither blocking:

• The shared pr-<N> tag namespace now collides across repos too — pr-309 here sits next to a pr-204 from cryptifyHeadless YiviDriver: issue + disclose via irmago irmaclient #204, a second collision beyond the edge/version-tag race you already flagged. Goes away with task: cut cryptify's Docker publish pipeline over to postguard, then retire the old repo's build #293 step 4.
• finalize-cryptify uses always(), so a failed scan-cryptify (e.g. a fixable critical CVE) wouldn't block publishing edge. Same shape as finalize-docker, so not new, but worth a conscious call now that it's live.