# OCI Is Not Git -- Rethinking GitOps Source of Truth > [!info] Ported from an existing deep-read (Refactor Appendix present). CNCF/KubeCon talk; a self-described "OCI skeptic" walks through OCI-as-GitOps-source-of-truth, its genuine gap (no built-in version history), and a new tool (Kokumi) built to close it. > [!question] Lingering Questions > - Is the provenance-linking gap (no system-level connection between a derived artifact's version chain and its Git source) solved in Flux's native OCI support, or is it open across the whole OCI-GitOps ecosystem? The Q&A treats it as unresolved. > - Tag-based GitOps references reintroduce a trust dependency even with digest-level immutability — is this trust window measured or exploited anywhere in practice, or purely theoretical so far? > - Does Kokumi's parent-pointer history actually satisfy audit/compliance requirements in regulated environments, or only cosmetically resemble Git's history? > [!tip] Article Ideas > - "Formal rules vs. actual value" — this talk is one of at least four instances in the same conference batch of a pattern quietly satisfying its own checkable definition while the value that motivated the definition drops out (GitOps rules vs. GitOps value here; container isolation vs. real security boundary in the sandbox talk; self-rated severity vs. independently verified severity in the Grafana/Mythos material). Strong candidate for a standalone cross-domain synthesis piece. > - The air-gap bundle workflow (build archive → move past security gate → load into disconnected registry) as a reusable pattern write-up on its own, independent of GitOps. > [!link] Cross Reference > - [[3. Resources/Literature Notes/Vulnerability Response for Large OSS Projects -- Grafana]] — same batch, same "formal/checkable compliance vs. actual value" shape (severity score vs. response context) > - [[3. Resources/Literature Notes/Sandbox for Agentic Application With Cloud Native Stack]] — same batch; a live demo failure treated as honest data rather than glossed over, same posture as this talk's skipped second demo > - [[3. Resources/MOCs/Open Source Governance MOC]] — the SCM-tooling-vs-OCI tradeoff is a governance/tooling-adoption question > [!quote] Vocabulary > - **GitOps' four formal rules** — declarative, versioned/immutable, pulled automatically, continuously reconciled; satisfiable by both Git and OCI sources > - **Kokumi** — an open-source Kubernetes operator adding a UI/history layer (Order, Preparation, Serving CRDs) on top of OCI-as-configuration-backend, to restore version-chain history OCI lacks natively ## Bibliographic capsule CNCF/KubeCon conference talk, YouTube. Michael Crenshaw (Argo CD maintainer, Intuit) and Robin Lieb walk through why teams adopt OCI artifacts instead of Git as a GitOps source of truth, name the gap that creates (no built-in version history), and demo Kokumi, a tool built to close it. Category: video, filed under Podcasts. ## Author's thesis (as synthesized) GitOps' four formal, checkable rules are satisfied equally by Git and OCI sources, but the human workflow (review, discussion, blame, "why did this change") that actually made GitOps valuable to practitioners is covered by none of those rules — OCI genuinely wins on edge/air-gapped distribution and immutability-by-construction, but reintroduces the missing-history problem the formal rules never required in the first place. ## Key arguments (≤3) 1. **GitOps' formal rules don't capture its actual value.** The four checkable rules (declarative, versioned, pulled automatically, reconciled) say nothing about the review/discussion/blame workflow that motivated GitOps' adoption in the first place — a definitional gap between the pattern's checklist and its purpose. 2. **OCI's real advantage is working without a Git server.** At the edge or in air-gapped environments, OCI-based delivery reuses the same registry infrastructure already needed for container images, including full offline bundle transfer past a security gate — a capability Git-based GitOps can't match without standing up Git infrastructure everywhere. 3. **OCI has no built-in version history.** OCI artifacts are unrelated blobs by design; any ordering between versions is a human convention (labels, semver), not a system-level guarantee — the structural source of the "missing history" problem Kokumi tries to patch. ## Claim atoms ### GitOps was never really about the storage mechanism > [!quote] ID: rw_01kze55p3zhp0w332zmxgry7rp > "GitOps has never really been about the storage mechanism. It's been about the human interactions that happen before all of that Argo CD stuff happens." Where/why: the talk's sharpest insight — the formal definition (four rules) and the value proposition (review, discussion, blame) have quietly diverged, and neither Git nor OCI's satisfaction of the four rules addresses the divergence. ### Tag-based GitOps references reintroduce trust-based mutability > [!quote] ID: rw_01kze55p3zhp0w332zmxgry7rp > "there is an element of trust in the GitOps operator that is introduced... you do have to trust that GitOps operator is always quickly pulling from that history" Where/why: even with digest-level immutability guaranteed by the artifact system, GitOps operators conventionally track tags/branch-heads rather than pinned digests — an admission that undercuts a naive "OCI is simply more immutable than Git" framing, since the same trust gap applies to both. ### No current link between derived-artifact history and source provenance Where/why: from Q&A, explicitly unresolved — a tool like Kokumi builds its own version chain for rendered artifacts, but nothing connects that chain back to the Git source (or base OCI artifact) that produced it. An acknowledged, unsolved supply-chain traceability gap. ## Permanent candidates - **A pattern's formal rules and its actual value can diverge** — the strongest, most cross-domain claim in this talk, and explicitly recurring across the same conference batch per the deep-read's own fleeting queue. Promoted below. - The trust-based-mutability-via-tags point is a solid security observation but narrower/more implementation-specific — held back pending a concrete exploited instance rather than a theoretical one. ## Processing checklist - [x] Ported claim atoms from the existing deep-read - [x] Checked existing Permanents before creating new ones - [x] Connected into [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — tooling adoption tradeoffs and the gap between a pattern's formal compliance and its practitioner-facing value - [[3. Resources/Literature Notes/OCI Is Not Git -- Rethinking GitOps Source of Truth]] — source transcript/notes