Skip to content

canonical composefs, backing store path notes #2165

Open
@cgwalters

Description

@cgwalters

Chatting with Giuseppe today one thing that came up is the backing store path today in c/storage is the full-SHA (from the zstd:chunked TOC), and we don't put the expected fsverity digest in there at all.

I think for standardizing "Verified OCI" we need a canonical mapping of OCI image to composefs final merged digest, and that digest needs to include the fsverity digest. And we need to canonicalize the backing store path. I would like that to always be the fsverity digest - not anything else.

So other projects like c/storage or ostree that may have other checksums by which they wish to index can maintain that "out of band" in some way.

What this would mean though practically is c/storage would need to (if we wanted to maintain the backing store paths pointing at full-sha) create a secondary composefs at runtime based on the first one or so? Or maybe it's actually just easier to have a hardlink farm named by both fsverity digest and full-sha that we keep in sync? (i.e. objects/verity/00... and objects/fullsha/00...).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions