fix: error on decoding unordered keys#58
Conversation
DAG-CBOR requires map keys to be sorted. The decoder now errors if that's not the case. A test case that existed before this became a DAG-CBOR library was removed, as it contains keys in the wrong order.
|
Oh, are you sure you want to do this on decode? I've stopped short of doing this anywhere, decided that this wasn't a good reason to reject decode, just a good thing to do on encode. There exists in the wild a lot of data with unordered keys. Most notably is the Filecoin pre-genesis block which is ancient dag-cbor, but also all of those schema-driven dag-cbor blocks that obey a struct key order rather than ordering them. cbor-gen for instance I think never got any map sorting in it, thankfully it doesn't get used much for maps since we just do arrays for chain data, but there are maps around that it's generated. |
|
My thought was, why not being as strict as possible, so that if anyone creates their own generators, also get failures from other libraries reading the data. If anyone complains, I could always relax things. Though
Is a good point, which is something that might actually be something that breaks. |
|
How hard is opt-out with this tooling? In go-ipld-prime it's not too hard to make a custom decoder that you turn strict off on, it helps justify opting in to strictness if you can fairly easily opt out. Although one challenge is how deep these components end up being in the stacks they're used in. At the bottom of something like Kubo, getting a strictness error means that turning strictnesss off is a blunt instrument, so we do need to carefully weigh the default decisions. Key ordering is one that I don't think I want to pull the trigger on, I'd rather opt-in to that rather than forcing an opt out. |
2 participants
DAG-CBOR requires map keys to be sorted. The decoder now errors if that's not the case.
A test case that existed before this became a DAG-CBOR library was removed, as it contains keys in the wrong order.