coreos/rpm-ostree

Roundtripping a commit via oci image looses the commitmeta which makes signed ostree break

Closed this issue · 4 comments

I created an oci image based on an automotive image that used signed composefs, when I rebased to it everything works, but on reboot the signatures fails:

[    0.419101] ostree-prepare-root[528]: ostree-prepare-root: Error loading signatures from repo: No commitmeta for commit 24e46035399c03969d5e6f610425a9adfc7a9959507fe9c32f6ccd12b3467573

Seems the detached metadata is lost somewhere along the way, which means that the signature is not available in the deployed repo.

This is an issue for https://github.com/ostreedev/ostree-rs-ext/ but basically this is currently expected behavior, because we always create a local merge commit. Arguably this is a bug.

The vision with the ostree-container stuff is that we start to sign containers, not ostree commits.

But, yes. In the end, we can change the logic in https://github.com/ostreedev/ostree-rs-ext/blob/main/lib/src/container/store.rs to not make a merge commit. We were doing that originally, but for derived images today we need to synthesize a local one. (Until we get to ostreedev/ostree-rs-ext#388 )

That said, changing the store code to not make a merge commit by default is probably doable, the main thing would be switching to storing the container metadata (manifest/config) in detached commitmeta or somewhere else.

This is an issue for https://github.com/ostreedev/ostree-rs-ext/ but basically this is currently expected behavior, because we always create a local merge commit. Arguably this is a bug.

Do you want me to move it?

The vision with the ostree-container stuff is that we start to sign containers, not ostree commits.

Well, at boot time in the initrd we need to validate something that has the composefs digest. This could be something else, but i'm not sure what is available at boottime?

Do you want me to move it?

Yeah let's, it's unrelated to rpm-ostree.

Well, at boot time in the initrd we need to validate something that has the composefs digest. This could be something else, but i'm not sure what is available at boottime?

This is a larger discussion but basically I think actually where we need to get to is actually that the manifest and config at least (and possibly, for a manifest listed image all the manifests) are part of a composefs instead of living externally so they can be runtime trusted easily.