Repository navigation
fix: verify all image candidates before release promotion - #237
Conversation
Upgrade Jackson to 2.21.7 and align owner releases at 1.0.1. Preserve HIGH/CRITICAL scans and existing immutable deployment policy. Publish digest-only candidates, verify all nine signed evidence sets, then promote tags through one serialized workflow. Reject historical tag collisions and incomplete release manifests.
CI image scans exposed fixed libexpat and pcre2 HIGH CVEs in cached Alpine upgrade layers. Bypass only final-stage cache in Verify and Publish so apk upgrade executes again; retain builder caches and scan thresholds.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 21b1865626
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| tags = [f"sha-{source_sha[:7]}"] | ||
| if candidate["version"]: | ||
| tags.append(f"v{candidate['version']}") |
There was a problem hiding this comment.
On the next main push where any Maven service retains its current service.version.*, this always plans the same v<version> tag. The workflow passes metadata-action labels into every build, and those labels include commit-specific org.opencontainers.image.revision and time-specific org.opencontainers.image.created values (metadata-action documentation), so even an otherwise unchanged service normally receives a new digest. The check at lines 302–304 then rejects the existing version tag because it points to the previous digest. Since all seven versioned services are built on every run, every later release would require bumping all seven versions rather than only the changed service; skip promotion of an already-owned unchanged version tag or otherwise prevent unchanged services from blocking the complete release.
Useful? React with 👍 / 👎.
| ISSUER = "https://token.actions.githubusercontent.com" | ||
| DIGEST = re.compile(r"^sha256:[0-9a-f]{64}$") | ||
| SHA = re.compile(r"^[0-9a-f]{40}$") | ||
| VERSION = re.compile(r"^[0-9]+\.[0-9]+\.[0-9]+(?:[-+][0-9A-Za-z.-]+)?$") |
There was a problem hiding this comment.
When a service uses a valid SemVer value with build metadata, such as 1.0.2+hotfix, this regex accepts it and the promoter later constructs v1.0.2+hotfix verbatim. Docker tag references only allow the pattern [\w][\w.-]{0,127}, so buildx imagetools inspect fails with an invalid reference before any promotion (container reference grammar). Either reject + versions at this boundary or sanitize the version into a valid, collision-safe Docker tag as metadata-action previously did.
Useful? React with 👍 / 👎.
| docker = os.environ.get("DOCKER_BIN", "docker") | ||
| planned = [] | ||
| for candidate in candidates: | ||
| tags = [f"sha-{source_sha[:7]}"] |
There was a problem hiding this comment.
When two main commits share the same first seven hexadecimal characters, both releases plan the identical sha-xxxxxxx tag. The first release permanently assigns that tag, and the second then hits the different-digest rejection at lines 302–304, blocking the complete release even though its full source SHA is distinct and valid. Because these tags are now deliberately immutable, derive the tag from the full SHA (or another collision-resistant identifier) rather than a seven-character prefix.
Useful? React with 👍 / 👎.
1 participant
Problem
Seven backend candidates contain Jackson 2.21.4 with five fixed HIGH vulnerabilities. Existing publication assigns release tags before scans and signed evidence finish.
Changes
Verification
./mvnw -B -Punit test), 3,271 tests, zero failures/errors, 16 skipped. First attempt failed on mismatched owner release versions; the final rerun includes the fix.Delivery
Merged at bc50511. Main CI 37361248796 and Docker Publish 37361248376 succeeded. All nine candidates passed real scans, signatures and SBOM/provenance verification before complete release promotion. Downloaded release evidence/source hashes verified; registry readback confirms nine sha-bc50511 and seven v1.0.1 tags match candidate digests, while sixteen historical sha-c3194bc/v1.0.0 digests remain unchanged. No production deployment.
Refs DAV-65