github: workflows: require publicly verified release metadata - #12513
Conversation
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
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. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (9)
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe PR adds a tool to generate, validate, compare, and verify versioned Fluent Bit metadata. Build and release workflows use image digests to generate metadata, validate staged files, publish them to package and GitHub release locations, and verify public downloads. ChangesRelease metadata lifecycle
Priority: ⬆️ High Estimated code review effort: 4 (Complex) | ~60 minutes Change: Feature Sequence Diagram(s)sequenceDiagram
participant StagingReleaseWorkflow
participant StagingImageRegistry
participant release_metadata.py
participant StagingSchemaBucket
participant ReleaseBucket
participant GitHubRelease
StagingReleaseWorkflow->>StagingImageRegistry: Resolve staging image digests
StagingReleaseWorkflow->>release_metadata.py: Generate metadata from image digest
StagingReleaseWorkflow->>StagingSchemaBucket: Download versioned metadata files
StagingReleaseWorkflow->>release_metadata.py: Compare staged files with generated metadata
StagingReleaseWorkflow->>ReleaseBucket: Upload validated metadata files
StagingReleaseWorkflow->>release_metadata.py: Verify anonymous public downloads
StagingReleaseWorkflow->>GitHubRelease: Attach versioned metadata files
Merge Risk: ⚪ Minimal · up to No confirmed release-gate defect remains. The change is mergeable after normal checks; public availability should be confirmed during an actual release. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The change strengthens release metadata integrity and anonymous availability checks. However, manual recovery now requires GitHub assets that are created only after package publication succeeds, blocking that recovery route for some first-release failures. Production permissions and serving configuration remain unverified. Retained concerns
Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Resilience and Maintainability Implications
Hardening Proposals
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 2.63% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 38 functions across 4 files. (5 skipped: 5 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Official releases currently tolerate missing configuration metadata during staging and S3 promotion. This change requires both JSON variants, checks them against the exact immutable release image, and fails publication if users cannot anonymously download the validated artifacts.
Both JSON variants are also attached to each GitHub release, as requested, and their public GitHub URLs are checked after upload.
Changes
docker run --rm --platform linux/amd64 <image>@<digest> -J, without a TTY. Require nonempty strict JSON, matching release version (one optional embeddedv), Fluent Bit metadata and plugin catalogs, and equivalent variants. The processor catalog is required from 4.0; older supported metadata omits it. No JSON Schema standard$schemafield is required.https://packages.fluentbit.io/<version>/<filename>, comparing both JSON and exact bytes with the publication artifact. Bounded retries accommodate the documented hourly sync and transient errors; persistent failures identify the URL and repair steps.https://github.com/fluent/fluent-bit/releases/download/v<version>/<filename>before documentation/version-update jobs proceed.packaging/update-repos.shrecovery withAWS_SYNC=true; its final dry run remains unchanged and it does not upload metadata.Coverage: automatic tag staging, manual staging, manual official promotion, all existing release series (2.0, 2.1, 3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 5.0, 5.1), and manual package recovery. Nightly prereleases and PR/master development builds are outside the official-release guarantee. Official staging dispatch requires an explicit release version rather than defaulting to master.
Explicit overwrites and retained artifacts support safe reruns. Recovery documentation covers partial publication and expired artifacts. Partial failures can leave files/a release visible, but workflow success remains blocked. Independent cleanup jobs and action cleanup remain unchanged; manual temporary files have an EXIT cleanup trap.
Verification
Passed 20 focused tests, including a real local HTTP server: missing/empty/malformed JSON, wrong versions, missing catalogs/metadata, branch compatibility, mismatched variants, public 403/404, transient failures, successful anonymous downloads, public content/byte mismatches, GitHub URL layout, pinned generation and workflow dependency checks.
Actionlint 1.7.12 passed. A focused CI workflow runs the tests and syntax checks. Real native Fluent Bit 5.1.3
-Joutput passed validation (741,821 bytes; all six root sections). The staging image digest was resolved with the actual Buildx template. Commit-prefix lint passed every commit and the exact six-commit PR range against freshly fetched master using the CI-style environment and an isolated lint clone.End-to-end container execution was blocked by Docker daemon permissions (
permission denied ... /var/run/docker.sock; passwordless sudo unavailable). Generation is covered by subprocess assertions and real native metadata validation. Nativetests/integrationplugin scenarios and Valgrind/Leaks are not applicable to this workflow/Python change and were not run. No production release was triggered.Public evidence and rollout
Read-only probes on 2026-10-04 UTC returned HTTP 404 with S3
NoSuchKeyfor both expected v5.1.3 packages URLs. Python requests returned 403, including a control key URL: 403 alone does not establish a missing object. The GitHub v5.1.3 release API reported no assets, and both expected GitHub JSON URLs returned 404. The new verifier correctly failed against both locations:These identify historical gaps at the configured URLs, not a full historical audit. Old releases/artifacts, production infrastructure and bucket permissions were not modified. Public availability of newly published files requires the first actual release run; local success/failure behavior is verified.
No new secrets or broader ACLs are introduced. Existing scoped S3 access and public serving/sync/CDN configuration must cover these exact JSON keys. Maintenance tagging branches must adopt the helper/staging changes; promotion must use the updated default-branch workflow or an adopted maintenance copy. Old unchanged workflow refs cannot gain this guarantee through a master-only merge. Release-environment ref restrictions and serving/access repairs remain external configuration responsibilities.
Summary by CodeRabbit