-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revocation registry cleanups #233
Conversation
…natures 0.2.1 Signed-off-by: Andrew Whitehead <[email protected]>
Signed-off-by: Andrew Whitehead <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think RevocationStatusList
de/serialization could be more straightforward.
src/data_types/rev_status_list.rs
Outdated
#[serde( | ||
rename = "currentAccumulator", | ||
skip_serializing_if = "Option::is_none", | ||
with = "serde_opt_accumulator" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like an overkill. Serialization doesn't seem to require anything custom, so the attribute could instead be deserialize_with
. But then the custom deserialization seems to only want to achieve having multiple names for the field, which can also be done with #[serde(alias = "currentAccumulator"]
.
Depending on which should be the serialization name for the field, you might want to use #[serde(rename = "currentAccumulator", alias = "accum"]
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test json_rev_list_can_be_deserialized
might also need to be expanded to make sure that the test vector, which includes currentAccumulator
checks that des.accum.is_some()
. as skip_serializing_if="Option::is_none"
is set, it will silently fail if it can not interpret currentAccumulator
correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't trying to change the current deserialization, but it's pretty strange. It accepts values like:
{ ...
"currentAccumulator": {
"currentAccumulator": "1 000..."
}
...
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably because the visitor implements the visit_map
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So do we think that's a mistake and it's just meant to support both currentAccumulator and accum as the field name? In that case it wouldn't need any custom deserialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fairly sure that it is a mistake. It was a custom implementation because we could not change it as it was a private field within Ursa (it has been a while so there might be more to it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well... The changes are introduced in this PR, so I was honestly expecting you to know the answer to that 😅 . To me it just seemed weird so I pointed it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just moved the deserialization code around and changed it to an Accumulator value, the old implementation had the visit_map method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to just deserialize from a string, which is the format the tests use. I'm a little surprised the bitvec serialization is a list instead of hex bytes or something.
Signed-off-by: Andrew Whitehead <[email protected]>
Updates to anoncreds-clsignatures 0.2.1 and simplifies revocation registry handling.