Fix revocation setup#4047
Conversation
Signed-off-by: Patrick St-Louis <patrick.st-louis@opsecid.ca>
Signed-off-by: Patrick St-Louis <patrick.st-louis@opsecid.ca>
|
ff137
left a comment
ff137
left a comment
There was a problem hiding this comment.
Well done! I'm trusting that this solution fixes the endorsement case (can't test it myself), but the changes make sense. Good job on figuring it out
There was a problem hiding this comment.
LGTM 👍
It would be nice to have some type of integration test coverage for this, but seeing as we only have BDD tests for the endorsement tests currently and we are somewhat trying to decommission these I think it ok to just move ahead with the unit tests.
esune
left a comment
esune
left a comment
There was a problem hiding this comment.
Good work! 👍🏻
This sure was a tricky one to diagnose
|
Does this need to be backported to the LTS branches -- either or both? |
|
@swcurran I think the LTS branch won't need this as the revocation update itself wasn't backported (which I think is okay) |
5 participants
There were inconsistencies with the new revocation setup when used in conjunction with the author/endorser model. This also affects similar interactions such as webvh witnessing.
It was boiled down to the rotation steps, expecting the new revocation registry to be available right away. This fix ensures the current active registry is properly decommissioned and sets the backup as active, while creating a new backup registry.