FIXME: node/bindnode: add fuzz failure with dag-cbor floats

[mvdan]

(see commit message)

[mvdan]

FYI @rvagg, this is another dag-cbor Go bug. I do think we need to reach into refmt to fix this one, unfortunately. I thought filing the bug as a PR would be easier, because we record the fuzz corpus entry right here.

[mvdan]

Also FYI @warpfork.

[mvdan]

Note that the PR is green because we don't test with Go 1.18 yet, meaning that the fuzz failure is hidden.

[rvagg]

Add these to the strictness pile. They are only failures in the sense that they aren't round-tripping cleanly, but this is expected.

For the record, the two failures here are:

An int type fails with:

        fuzz_test.go:241: node reencoded as " " rather than "8\x00"

In hex, it's pushing 0x3800 through and getting round-tripped as 0x20. These are both valid -1 in CBOR, and you'd find another one at 0x390000 and another one at 3a00000000 and again at 3b0000000000000000, all -1, just represented at different sizes (compact, 8-bit, 16-bit, 32-bit, 64-bit). Our DAG-CBOR spec specifies smallest-possible for integers, so 0x20 is correct since we can cram integers under ~23 (slightly different for + vs -) into a single CBOR byte.

In the other failure, it's got a map: {String:Float} and failing with:

        fuzz_test.go:241: node reencoded as "\xa2a0\xfb00000000a1\xfb?\xc0\xc0\x00\x00\x00\x00\x00" rather than "\xa2a0\xfb00000000a1\xf900"

In hex, it's pushing a26130fb30303030303030306131f93030 and getting back a26130fb30303030303030306131fb3fc0c00000000000 after a round-trip. This time we're going the other way for floats, getting bigger. The float at the end of this string, the second value in the map, is 0.130859375 which can be represented compact in CBOR as f93030. But we've got a rule for DAG-CBOR that we represent all floats as 64-bit regardless of whether they can be represented smaller (we went the other way with floats, because ... floats). So the round-trip yields the same number, but in a double representation: fb3fc0c00000000000.

---

Working as expected, but it would be nice for a user to be able to opt-out of this sillyness and say "you give me data that wasn't encoded with a spec-compliant DAG-CBOR encoder then I don't want to trust it". Currently there's no way other than doing a round-trip and comparing bytes/CID.

[rvagg]

respect to the fuzzer for finding these two though, especially the second one

[mvdan]

The fuzzer is generic and pretty dumb, which can make it slow at discovering new code paths, but it also means it can likely discover any ugly corner if given enough time :) These were found after a total of about twenty minutes fuzzing on my laptop.

[BigLep]

2022-04-05: @rvagg will talk with @mvdan on what the next steps are. It may involve creating an issue where we accumulate the various strictness items.

[BigLep]

2022-04-19 conversation: it would be nice to do, but we don't have anyone clamoring for this. Given priorities and low resources, closing.