JSON serialization of `ImageConfiguration` is non-deterministic

[allisonkarlitskaya]

Sometimes you get

        "Labels": {
            "maintainer": "cockpit-devel@lists.fedorahosted.org",
            "containers.composefs.fsverity": "6c8fb1443b014c416e3ebddd8c75307182661f9093f83d3700499e7601aecb61"
        }

sometimes you get

        "Labels": {
            "containers.composefs.fsverity": "6c8fb1443b014c416e3ebddd8c75307182661f9093f83d3700499e7601aecb61",
            "maintainer": "cockpit-devel@lists.fedorahosted.org"
        }

ie: probably we ought to sort by key before writing the JSON. Or maybe use an inherently-sorted type. Or at least ordered.

[cgwalters]

In ocidir we use https://docs.rs/olpc-cjson/latest/olpc_cjson/ by default (ref code) but... bootc-dev/ocidir-rs#10

[champtar]

Would it be acceptable to just replace all HashMap with BtreeMap ?
Then we can use serde_json directly without specific formatter

[cgwalters]

ie: probably we ought to sort by key before writing the JSON.

Note this crate isn't in direct control over how values are serialized, that's the responsibility of the specific serde serializer implementation (e.g. yaml/rust/bincode).

Would it be acceptable to just replace all HashMap with BtreeMap ?

Yeah it would probably Just Work for the default use case but this came up in serde-rs/json#309 (comment) and I think the conclusion here is that use cases that care about bit-for-bit reproducibility need to specify their own formatter. And for that I think we can discuss in bootc-dev/ocidir-rs#10

[allisonkarlitskaya]

It's worth noting that oci-client defines its own OciDescriptor type where the annotations are in a BTreeMap instead of a HashMap....