Do verification on the stratisd side for Clevis configs to avoid hanging

[jbaublitz]

Related to latchset/clevis#241

[mulkieran]

This all makes sense to me. My only concern is that it might be possible to pass a config that causes a stack overflow during the recursive execution of all_tang_configs_have_thp. I think there should be some way to prevent that from happening.

[jbaublitz]

That is arguably already possible in other parts of the code given that we take a similar recursive approach when parsing Clevis tokens from disk to provide the reconstructed config to the user over the D-Bus. How would you recommend approaching preventing this in both cases? Adding a parameter to limit the number of recursions we can reach?

[mulkieran]

That is arguably already possible in other parts of the code given that we take a similar recursive approach when parsing Clevis tokens from disk to provide the reconstructed config to the user over the D-Bus. How would you recommend approaching preventing this in both cases? Adding a parameter to limit the number of recursions we can reach?

Until now, we weren't recursively exploring the config, we were essentially passing it directly through to Clevis. But now that we're recursively exploring something that is sent over the D-Bus, I think that the additional caution is warranted. I'm not sure if parsing the Clevis tokens from disk is analogous, but it may well be.

A recursion limit would be fine, I think.

[jbaublitz]

I've added the recursion limit.

[packit-as-a-service]

Cockpit tests failed for commit 524efe0. @martinpitt, @jelly, @mvollmer please check.

[jbaublitz]

@martinpitt Is this a known issue with cockpit? It seems to be affecting all new PRs with stratisd. @mulkieran believes this is not a problem in our master branch.

[mulkieran]

Looks good.