gardencmp
Group inheritance: Rotate keys on unavailable child groups
The problem
When kicking someone out form an extended group we iterate over all the child groups to rotate their keys.
This way new coValues created with these groups are encrypted with a new key unavailable to the removed members.
It may happen that when a member is removed someone else has extended the group and not synced up the changed yet.
In that case the account is still correctly kicked out from that child group, but it still have access to the readKey because it hasn't been rotated.
This means that, even if Jazz hides the new information to that account, they could potentially be albe to decrypt the information.
Proposed solution
We could add a "auto-healing" system where the admins rotate the read keys on the child groups when they discover that the current parent key haven't been revealed to the child group.
Repro steps
We have a test that reproduces this issue here: https://github.com/garden-co/jazz/blob/9dd93667342ebb41007a7141d00b8416026b1c40/tests/e2e/tests/Sharing.test.ts#L285
