Proto commits in project-zot/zot

These 6 commits are when the Protocol Buffers files have changed:

2026-10-02

fix(meta): stop storing signature layers in MetaDB, verify from storage (#4493) fix(meta): load signature layers from storage instead of storing them in MetaDB Every signature layer (the cosign payload or bundle, the notation envelope) was copied into the repo's RepoMeta record. That record is a single value per repo that every pull (UpdateStatsOnDownload), every signature validity run and most searches decode and rewrite in full. Its size grew with the number of signatures times the size of their layers, and the only reader of the content was signature verification. The trust store now loads a signature layer from the image store when it verifies it: - mTypes.ImageTrustStore.VerifySignatureLayer takes the layer digest in place of its content. imagetrust gets a blob getter from SetupImageTrustExtension, which is given the store controller. The getter holds no storage lock while reading, and refuses layers over 4 MiB, since those cannot be signatures. - A layer no longer in storage makes the signature untrusted, without an error. A layer that cannot be read right now keeps its previous validity, so a storage hiccup does not flip images to untrusted until the next run. - Parsing only checks that the signature layers exist (StatBlob) instead of reading them. - LayerInfo.LayerContent is gone from mTypes. The proto field stays for wire compatibility and is dropped whenever a stored repo record is read, so records written by older versions shrink the next time they are written. bbolt does not give the space back to the file system; compact or recreate meta.db to reclaim it. For one image with a cosign sign bundle, the repo record goes from 2.2 KB to 1.6 KB. A 12 MB record written by v2.1.21 (sign bundle plus an 8 MB attestation) came down to 1.6 KB after the first start of this version. refactor(meta): verify signatures outside the MetaDB write lock UpdateSignaturesValidity verified every signature of a manifest inside the write transaction that also rewrote the repo record: bbolt's single writer lock for BoltDB, the repo lock for Redis. Nothing else could write to the MetaDB (bbolt) or the repo (Redis) for the duration of the signature checks, and a verification that needs anything from the MetaDB itself deadlocked on bbolt. Read the signatures first, verify them with no lock held, then re-read the repo record and apply the results in a short write. The results are only applied to signatures that are still there with the same layers, so signatures added or deleted in the meantime are kept or stay deleted, and a repo removed in the meantime is not recreated. The verify loop the three implementations duplicated is now common.VerifyManifestSignatures and common.ApplySignaturesValidity. No change in what is verified or stored. fix(meta): don't let unavailable signature layers overwrite newer validity VerifyManifestSignatures wrote its results into the snapshot of the signatures it was given and skipped layers it could not load, so those kept their snapshot values. ApplySignaturesValidity then copied every layer of the snapshot onto the stored record, unable to tell a verified layer from a skipped one. With verification no longer holding the write lock, two runs can overlap, and a run that could not load a layer overwrote the result another run had written for it in the meantime. VerifyManifestSignatures now leaves the signatures unchanged and returns the results only for the layers it verified, keyed by signature type, signature manifest and layer digest. ApplySignaturesValidity applies exactly those, so a layer that could not be loaded keeps whatever validity is stored when the results are written back. test(meta): cover a signature verification cancelled midway A verification whose context is cancelled while it runs must fail with the context's error and leave the stored validity untouched, on every MetaDB implementation. fix(meta): keep the stored signature date when verification finds none A verified layer's result started out with the date of the snapshot it was verified from, and only replaced it when the trust store returned an expiry date. ApplySignaturesValidity then wrote that snapshot date onto the stored record, so a run that found no expiry date (an untrusted signature, a verification error) put back the date from before it started, over a date another run had stored in the meantime. A result now only carries a date when verification found one, and ApplySignaturesValidity keeps the stored date otherwise, which is what the in-place update did before verification moved out of the write lock. fix(meta): key signature layer validity by signature key too A cosign signature manifest holds one layer per signature, and every signature of the same image has the same payload, so the layers share their digest and only differ in their signature annotation. Keyed by layer digest alone, the verification results of such layers collided and the last one was written onto all of them, so a signature by an unknown key could be marked trusted, or a trusted one untrusted. Signed-off-by: Fabian Stelzer <fs@gigacodes.de>

The documentation is generated from this commit.

2026-01-30

feat: add TaggedTimestamp to ImageSummary returned by graphql API (#3731) feat(meta): add TaggedTimestamp field and preserve during re-parsing Add TaggedTimestamp field to track when image tags were created, exposed through GraphQL API. Previously, when zot restarted and re-parsed storage, ResetRepoReferences would clear all tags, causing timestamp information to be lost and reset to the service restart time for existing images. This change adds TaggedTimestamp support and modifies ResetRepoReferences to selectively preserve tags that still exist in storage, maintaining their TaggedTimestamp values. Tags that no longer exist in storage are removed as before. Changes: - Add TaggedTimestamp field to GraphQL ImageSummary schema - Update GraphQL conversion functions to populate TaggedTimestamp with fallback to PushTimestamp when unavailable - Updated ResetRepoReferences interface to accept tagsToKeep parameter - Modified ParseRepo to collect tags from storage before resetting - Updated all backend implementations (Redis, DynamoDB, BoltDB) to preserve tags in tagsToKeep instead of clearing all tags - Updated tests and mocks to match new signature This ensures TaggedTimestamp accurately reflects when tags were originally created, and exposes this information through the GraphQL API. Signed-off-by: Andrei Aaron <andreifdaaron@gmail.com>

2023-12-08

fix(proto): the size of the repo should be int64, since that is the same type used for the manifest/config/index/digest sizes it sums up. (#2120) Using int32 may result in negative size values when returned by the graphql API Signed-off-by: Andrei Aaron <aaaron@luxoft.com>

2023-11-09

fix(metadb): populate image pushTimestamp if it's 0 value (#2003) in the case of an already existing meta db without pushTimestamp field its value would be 0 until image is updated, check for zero values and update them with time.Now() so that retention logic won't remove them. Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>

2023-11-01

feat(retention): added image retention policies (#1866) feat(metaDB): add more image statistics info Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>

2023-10-30

refactor(metadb): improve UX by speeding up metadb serialize/deserialize (#1842) Use protocol buffers and update the metadb interface to better suit our search needs Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com> Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com> Co-authored-by: Ramkumar Chinchani <rchincha@cisco.com>