Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

composefs: Don't verify checksum if !target-fsverity #3330

Closed
cgwalters opened this issue Oct 30, 2024 · 0 comments · Fixed by #3331
Closed

composefs: Don't verify checksum if !target-fsverity #3330

cgwalters opened this issue Oct 30, 2024 · 0 comments · Fixed by #3331
Labels
area/composefs Issues related to composefs bug difficulty/medium medium complexity/difficutly issue

Comments

@cgwalters
Copy link
Member

A long time ago we changed rpm-ostree to default to adding composefs metadata. I hadn't noticed at the time how expensive that is if the build system doesn't have verity enabled which is going to be the common case, which is its own issue. But build time performance here isn't as relevant as client side, and the semantics.

In #3326 I changed things so we only add the verity digest in the generated composefs if we have it.

In the original version of that patch that broke checkout --composefs in the !verity case when we have an expected digest in the commit (as every rpm-ostree generated commit will have).

Obviously bigger picture we have a mess here because the bootc based testing isn't using this flow as it's doing a client side commit and deployment from that.

In the immediate short term I think I want to back out adding the composefs metadata to rpm-ostree by default, but that's a different thing.

On the ostree side here I think we should just stop checking the generated composefs when we're !verity because there's no integrity here.

I'm thinking we should never do "add fsverity if it exists" into the composefs as that previous PR was doing; either it's enabled or it's not, and half-measures are broken.

@cgwalters cgwalters added bug difficulty/medium medium complexity/difficutly issue area/composefs Issues related to composefs labels Oct 30, 2024
cgwalters added a commit to cgwalters/ostree that referenced this issue Oct 30, 2024
Fixes a regression from the previous commit; in
the case where the target repo doesn't have composefs in
signed mode there's no reason to verify the digest
at checkout time because we aren't verifying it at
boot time either.

The regression is in cases that use rpm-ostree e.g.
where as of recently we unconditionally add the composefs
digest, but for e.g. FCOS we aren't deploying with fsverity
enabled.

Closes: ostreedev#3330

Signed-off-by: Colin Walters <[email protected]>
cgwalters added a commit to cgwalters/ostree that referenced this issue Nov 4, 2024
Fixes a regression from the previous commit; in
the case where the target repo doesn't have composefs in
signed mode there's no reason to verify the digest
at checkout time because we aren't verifying it at
boot time either.

The regression is in cases that use rpm-ostree e.g.
where as of recently we unconditionally add the composefs
digest, but for e.g. FCOS we aren't deploying with fsverity
enabled.

Closes: ostreedev#3330

Signed-off-by: Colin Walters <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/composefs Issues related to composefs bug difficulty/medium medium complexity/difficutly issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant