Enable fsverity conditionally in post-deploy (remove ex-integrity.composefs
)
#3202
Labels
area/composefs
Issues related to composefs
difficulty/low
Not extremely difficult
reward/medium
Fixing this will be notably useful
See #3165 (comment)
Basically cae4ceb wants to get rid of
ex-integrity.composefs
. To complete that picture let's change the deployment operation to walk over the objects and match the fsverity enablement to the composefs configuration.maybe
, then try to enable fsverity, but don't hard error if we can'tyes
, then enable fsverity, or error if we can'tThis would all be a bit more elegant if we changed the deploy logic to walk the ostree commit in memory instead of doing a checkout and read the composefs config that way. Longer term we want to do something like that anyways because we can avoid creating the hardlink tree that way, which would make things even more efficient.
The other angle to take on this is moving the composefs config into commit/container metadata outside of the image. I'd really like to eventually get to a world where composefs is opt-out instead of opt-in too...but ostree so far has had a very conservative backcompat setup.
The text was updated successfully, but these errors were encountered: