Repository navigation
Support base digest pinning and OCI subject linkage for adapters #899
Description
Describe the problem you're trying to solve
KitOps currently links adapters to base models via Kitfile metadata but does not record the exact base digest nor expose the relationship at the OCI level. This issue adds two enhancements to improve reliability and interoperability: capture and record the base’s immutable digest when packing adapters, and optionally set the OCI subject field in the adapter manifest to point at the base manifest digest.
Describe the solution you'd like
- Digest pinning - On kit pack for a Lora adapter, resolve the base reference (model.path) to its immutable OCI manifest digest
- Record that digest in Config/Kitfile
- OCI subject support
- When generating the adapter’s OCI manifest, optionally set the subject field to reference the base manifest digest, for example:
"subject": { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:<base-manifest-digest>" }
- When generating the adapter’s OCI manifest, optionally set the subject field to reference the base manifest digest, for example:
Activity
arnab2001 commentedon Nov 3, 2025
Willing to pick it up if its still needed
rishi-jat commentedon Mar 18, 2026
@gorkem , Started working on this. Opened a PR - #1126 for base digest pinning.
Will follow up with OCI subject linkage in a separate PR.
amisevsk commentedon Mar 24, 2026
Re-reading this issue, if a user cares about the base digest, can they not just specify the base model via its digest rather than its tag? I'm not sure this feature is adding anything useful to the project.
amisevsk commentedon Mar 24, 2026
I'm of the opinion that this issue should just be closed (cc: @gorkem)
gorkem commentedon Mar 24, 2026
I think this issue is touching the right problem but we should reconsider the solution.
The core need is real: when kit packs an adapter that references a base model by tag, we lose track of what that tag resolved to. Tags are mutable, digests are identity. We need to capture that resolution.
Docker build went through exactly this evolution. They started by encouraging users to pin digests manually in Dockerfiles (
FROM python@sha256:...), which was bad UX if all you need is to record what it was built against (not avoid tag drift). Then BuildKit added--provenancewhich automatically records the resolved digest of everyFROMimage in a SLSA provenance attestation attached to the built image. The Dockerfile stays human-readable, the build record captures the cryptographic identity. We should learn from that rather than repeat the early mistakes.I'd split this into two things instead of what's described here:
1. Manifest annotation (always-on, zero config)
On
kit pack, when we resolve a base reference, write the resolved digest as an OCI annotation on the adapter manifest:2.
--provenanceflag for full recordGenerate a provenance attestation — same pattern Docker BuildKit uses. This captures all resolved references (not just base model — datasets, code layers, everything), kit CLI version, timestamps, and optionally signer identity.