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
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.
The text was updated successfully, but these errors were encountered:
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]>
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]>
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.
The text was updated successfully, but these errors were encountered: