You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...).
The text was updated successfully, but these errors were encountered:
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...).
The text was updated successfully, but these errors were encountered: