[Release/Supply chain] Establish reproducible exact-head artifacts and provenance

[seonghobae]

Buyer / acquisition gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 has CI, dependency review, SBOM and security workflows, but a fresh repository search found no dedicated release/provenance workflow, no artifact-attestation path, and no existing mightyETL issue owning reproducible release artifacts or provenance verification. The commercial loop's release policy is therefore stronger than the executable repository release evidence currently visible.

Status: planned.

This is a supply-chain/release-product gap, not permission to publish an artifact immediately. Current blockers such as #151 licensing, #121 source-identity controls, #162/#164 non-vacuous coverage, required security/review evidence, and protected-head integration remain independent prerequisites and must not be bypassed.

Product decision

A release is an explicit protected-head operation. mightyETL must not treat a green pull-request synthetic merge, an arbitrary workflow run, a locally built binary, or an SBOM by itself as releasable provenance.

The target release boundary is:

exact protected source head
→ deterministic validated package/container build
→ dependency/license/security/coverage/migration/compatibility acceptance
→ SBOM + artifact digest
→ provenance/attestation bound to source/workflow/commit
→ verification
→ version/tag/release publication
→ post-publication artifact verification

No release workflow should be opened merely to manufacture attestation while the product cannot yet pass its protected release prerequisites.

Current GitHub-native feasibility

GitHub's current official artifact-attestation documentation provides a supported implementation path rather than requiring an invented signing service:

• actions/attest@v4 can create artifact attestations for build outputs and container images;
• attestation jobs require explicit least privilege such as id-token: write, contents: read, and attestations: write for the documented GitHub-native path;
• SBOM attestations are supported;
• consumers can verify provenance with gh attestation verify;
• attestation statements bind build evidence such as repository/workflow/commit identity and must be verified rather than treated as proof merely because an attestation exists.

Primary documentation:

• https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds
• https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/about-artifact-attestations
• https://docs.github.com/en/rest/orgs/attestations

Use the current supported GitHub mechanism or a separately justified equivalent at implementation time; reverify versions and semantics before writing the workflow. Never copy an example action/version unpinned into protected release authority.

Required RCA before implementation

Inventory the actual distributable surface and establish one authoritative release contract:

1. Which outputs are commercially supported: Maven artifacts, runnable JARs, container images, compose bundle, migration files, API/event contracts, or another package?
2. Which artifact is the canonical installable unit for standalone operation and which artifacts compose the modular MSA profile?
3. How are versions synchronized across the root reactor, service artifacts, containers, machine-readable contracts, database migrations and CHANGELOG?
4. Can two clean builds from the same exact protected source produce byte-identical artifacts? If not, identify every nondeterministic input and decide whether reproducibility means byte identity or a rigorously bounded reproducible-build contract with normalized metadata.
5. Which dependency/container/license/NOTICE obligations must ship with each output? [Acquisition diligence] Establish explicit repository licensing and copyright policy #151 is an explicit legal/product prerequisite; do not invent a license.
6. Which database migrations and rollback/forward-recovery procedures must be included and rehearsed for a version?
7. Which compatibility matrix applies to Java, PostgreSQL, Kafka/Debezium, connector/runtime dependencies and supported deployment profiles?
8. What rollback means after an irreversible database or external-side-effect boundary?
9. Which workflow/ref is authorized to publish: protected branch/tag only, never an arbitrary PR ref or synthetic merge.
10. How tag/version publication is made race-safe so the attested digest, release tag and released bytes cannot refer to different source heads.

Bounded remediation options

Preferred architecture

After prerequisites are integrated, create one protected release workflow whose source is an exact immutable integrated ref and whose jobs are separated by authority:

• build/test authority — read-only source checkout bound to the release SHA; execute the same full CI/security/coverage/package/migration/compatibility acceptance required by repository policy or consume immutable accepted evidence only when identity equivalence is provable;
• package authority — produce canonical artifacts with deterministic metadata and explicit digests;
• SBOM/license authority — create/validate SBOM and required LICENSE/NOTICE/provenance inventory without fabricating legal rights;
• attestation authority — obtain only the minimal GitHub/OIDC permissions needed to attest the already-built immutable digest; no source mutation;
• publication authority — publish only an already-validated/attested digest from the exact expected source/tag; fail closed if the protected ref or release identity changes;
• verification authority — independently verify the published artifact digest and attestation after publication.

Acceptable alternative

Use another maintained provenance/signing system only if it provides equivalent or stronger source/workflow/artifact identity, secret handling, verification, revocation/incident handling and acquisition evidence, and its operational dependency is explicitly accepted by ADR.

Reject

• publishing from pull_request synthetic merge revisions;
• signing/attesting a mutable filename without digest binding;
• producing provenance before tests/security/coverage and then replacing the artifact;
• reusing an SBOM from another head/base;
• letting a model-executing job hold release credentials merely for convenience;
• long-lived static signing secrets when supported OIDC/ephemeral identity can meet the requirement;
• latest-only container publication as release identity;
• changing branch protection or required gates to make a release workflow pass;
• claiming reproducibility because one build succeeded;
• publishing before [Acquisition diligence] Establish explicit repository licensing and copyright policy #151 has an explicit owner-approved licensing posture.

TDD / release acceptance

Before production release automation, add fail-first workflow/package contracts proving the protected repository currently lacks the required boundary. Final acceptance must prove at minimum:

1. workflow can run only from the intended protected immutable release identity and records the exact source SHA;
2. PR synthetic merge/event ref cannot enter the publication path;
3. package/container manifests and application version agree with the release version;
4. clean supported-environment builds produce the declared reproducibility result, with nondeterministic inputs either eliminated or explicitly normalized and tested;
5. generated artifact digest is captured before attestation and publication;
6. SBOM corresponds to that exact artifact/source and includes available license metadata;
7. required LICENSE/NOTICE files are present in every distributable once [Acquisition diligence] Establish explicit repository licensing and copyright policy #151 is resolved;
8. all exact deterministic tests, non-vacuous 100% owned-production coverage, dependency review, SAST/security, secret scanning, SBOM, migration/rollback, compatibility and operator acceptance gates pass on the exact release source;
9. machine-readable OpenAPI/AsyncAPI artifacts, once feat(api): add machine-readable HTTP and CDC contracts #157 integrates, are versioned and match the released runtime behavior;
10. database migrations are ordered, upgrade-rehearsed and accompanied by an explicit rollback or forward-recovery boundary;
11. provenance/attestation is generated for the immutable digest with minimal permissions and no model/reviewer credential reuse;
12. gh attestation verify or an equivalent independent verifier succeeds against the published artifact and expected repository identity;
13. tampered bytes, wrong repository/workflow identity, wrong source SHA and wrong release version fail verification;
14. publication is expected-head/digest safe and cannot silently release another actor's newer branch/tag state;
15. post-publication verification fetches the actual released artifact/container digest rather than trusting the upload response;
16. failure before publication leaves no partial release; failure after publication has a documented incident/yank/revoke/supersede procedure appropriate to the package channel;
17. CHANGELOG/release notes contain only behavior integrated on the exact protected source and never active_pr claims;
18. qualifying independent non-author review and release approval satisfy live governance without self-approval or synthesized identities.

Reproducibility evidence

Do not reduce reproducibility to one checksum assertion. The test plan should identify and control, where applicable:

• compiler/JDK and Maven versions;
• dependency and plugin resolution;
• timestamps, archive ordering and file modes;
• generated manifests/build metadata;
• container base-image digests and build context;
• architecture/platform variance;
• generated API/event/schema artifacts;
• migration file contents/order;
• environment-dependent configuration that must remain outside artifacts.

Record the exact reproducibility model and any residual nondeterminism in canonical release/provenance documentation.

Documentation / traceability

Issue #159 already requires a discoverable release/provenance authority. The integrated release slice must update or explicitly index:

• PRD/TRD release requirements;
• Architecture deployment/release authority;
• Security/Threat Model for supply-chain compromise and credential boundaries;
• Test Strategy for reproducibility/verification;
• Operability runbook including rollback/yank/incident response;
• migration/compatibility authority;
• licensing/NOTICE authority from [Acquisition diligence] Establish explicit repository licensing and copyright policy #151;
• CHANGELOG/versioning rules;
• ADR for release/provenance architecture;
• traceability from requirement → workflow → test → artifact → attestation → release.

Sequencing

Do not open the release workflow implementation while an exact release cannot satisfy its prerequisites. Re-evaluate after #121 source-identity controls, #162/#164 non-vacuous coverage, #151 licensing posture, machine-readable contract integration as applicable, and the relevant product/security stack have stabilized on protected history. A waiting release issue never blocks unrelated product/security work.

[seonghobae]

Fresh reproducibility evidence from exact-source CI sharpens item 4 without changing sequencing. PR #148 CI run 31315338962, Ubuntu job 93249548594, explicitly checked out and verified exact source e935d5ebb4c9cca7e77fff5889b759eff00d4fcb; the full reactor then passed. During that exact-source build Maven emitted Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent! for etl-service, cdc-service, config-server, eureka-server, and zuul-gateway. The same run also reports a platform-dependent build warning before test-resource copying where applicable.

This is a concrete reproducibility input, not proof of differing bytes: the resource plugin is relying on the runner's default charset instead of an explicit project/build encoding. When #165 becomes executable, the RED should include a clean-build contract that detects/default-charset dependence, followed by an explicit UTF-8 project/build resource encoding (or another documented canonical encoding) and cross-environment artifact comparison. Keep this issue planned; do not open release publication/attestation work ahead of its existing protected-head/licensing/security prerequisites.

[seonghobae]

2026-08-10 source-backed release-surface inventory

Fresh protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 inspection narrows the unanswered artifact question without opening a release implementation prematurely:

• root Maven coordinates are still com.xtrmetl:xtrmETL:1.0-SNAPSHOT with packaging=pom;
• the reactor contains five JAR modules: etl-service, cdc-service, config-server, eureka-server, and zuul-gateway;
• the repository Dockerfile accepts ARG SERVICE and builds one selected service JAR into /app/app.jar on eclipse-temurin:25-jre;
• default Compose builds repository images for eureka-server, etl-service, cdc-service, and zuul-gateway, but does not currently instantiate config-server;
• Compose is therefore an MSA/local-stack composition surface, not evidence of one canonical standalone release artifact;
• current image references include mutable/non-digest identities such as maven:3.9.13-eclipse-temurin-25, eclipse-temurin:25-jre, postgres:16-alpine, confluentinc/cp-zookeeper:7.6.0, confluentinc/cp-kafka:7.6.0, and openzipkin/zipkin:2; a reproducible release cannot rely on those tags as immutable artifact identity;
• protected source contains no production release workflow that publishes the reactor JARs, service images, Compose bundle, migrations, or API/event contracts as a versioned verified release.

Implication: the release ADR/implementation must explicitly choose supported distributables rather than infer them from current dev topology. A defensible first target is likely a versioned set of service JAR/image artifacts plus a versioned Compose/deployment bundle, with config-server either deliberately included and acceptance-tested or explicitly excluded from the supported deployment profile. This is planning evidence only; #151 licensing, #121 exact-source authority, #162/#164 non-vacuous coverage, security/review, and protected integration remain prerequisites.

Additional acceptance requirement exposed by this inventory: release tests must fail when a supposedly reproducible/publishable container still depends only on a mutable base-image tag rather than the reviewed immutable identity policy. Do not pin guessed digests or claim byte reproducibility until the actual supported artifact set and builder/runtime image policy are approved.

[seonghobae]

2026-08-10 reproducibility evidence — platform-default resource encoding

Fresh hosted CI evidence adds a concrete nondeterminism/input-control item to this release issue.

On current PR #184 integration-tree CI (31345440443, macOS job 93326388060), Maven repeatedly emits for ETL, CDC, Config Server, Eureka and gateway resource processing:

[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!

A protected-source search finds no canonical project.build.sourceEncoding declaration. The current GitHub runners happen to use UTF-8, but that is environment coincidence, not a reproducible-build contract; another supported build environment can select a different default encoding for filtered resources.

Classification / bounded next remedy

• execute_now once root-POM writer conflicts clear: add a fail-first reactor/build contract for explicit source/resource/reporting encoding, then define UTF-8 at the canonical Maven root so every module inherits it; verify resource copies and tests on the supported OS matrix.
• defer_until_trigger now: fix(security): move Jackson to fixed 2.21.5 baseline #160 and other active shared-POM/quality work must be rechecked before touching the root Maven authority. Do not create a competing root-POM PR simply to silence a warning.
• reject: suppressing Maven warnings, relying on current runner locale, or claiming reproducibility because the current three hosted OS images all happen to use UTF-8.

The release acceptance should therefore include an explicit build/resource encoding invariant alongside JDK/Maven/plugin/base-image/timestamp/archive-order inputs. This is repository-owned reproducibility work and does not depend on choosing the outbound license in #151.