Skip to content

Conversation

@stormer78
Copy link

Description

  • Pinning serde to "=1.0.219" as the last working serde version
  • Incrementing ssi crate from 0.12.0 to 0.12.1

Other changes

No other changes

Optional section

Ideally the de/se implementations need to be refactored to work with the latest serde versions.

Tested

Tested compilation and tests, everything passed.

Serde versions > 1.0.219 are causing ssi-data-integrity-core to fail due
to the use of serde::__private::* functions which are no longer
supported

Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
@CLAassistant
Copy link

CLAassistant commented Sep 16, 2025

CLA assistant check
All committers have signed the CLA.

sbihel added a commit that referenced this pull request Sep 18, 2025
We were using private APIs from serde, which they have now protected.

I tried to copy the serde code that we were using, but it did not work
as it required redefining `Content`, which is explicitly used by traits
like with the `__deserialize_content_v1` method.

The existing code is quite complex (I intend to add some comments in
this PR), so I thought it would be good to rely on serde in a more
common way. An earlier version of this PR didn't have the
`DeserializeCryptographicSuiteMultiplexing` trait which resulted in
`AnySuite` deserialization having mismatched signatures and options.
Which is obviously what the existing code tries to avoid! So I tried to
solve the issue using this awkward back and forth between the
cryptosuite's associated types and the deserialization process, which
means many places (and more are needed) to be patched with a constraint
on the trait.

I also replaced the use of `Content` with a JSON "data model". I know
the specs don't explicitly say so, but in practice we're only dealing
with data that can be represented with JSON types.

We're definitely losing in performance and in cleanliness but what do
you think? Do you have a better idea?

Close #681
Close #682
@stormer78
Copy link
Author

Replaced with #683

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants