1. You upload some sort of payload in a store (be it local or remote) to a certain output hash.
2. You push a fetcher derivation trying to fetch from a certain URL having the CA of step 1 (wrong ca).
3. The builder uses the cached FOD in the local/remote store instead of trying to verify the FOD.

Agreed, this is more of an UX-like posoning. Also agreed, it's CA-specific, not FOD specific.

What I'm trying to say, is that CA and non CA derivations are behaving quite differently on the build graph. I'd be nice to have a way to distinguish those from the validpath boundary.

1. You upload some sort of payload in a store (be it local or remote) to a certain output hash.
2. You push a fetcher derivation trying to fetch from a certain URL having the CA of step 1 (that does not necessarily reflect the ca you'd get fetching the url).
3. The builder uses the cached FOD in the local/remote store instead of trying to verify the FOD.

Agreed, this is more of an UX-like posoning. Also agreed, it's CA-specific, not FOD specific.

What I'm trying to say, is that CA and non CA derivations are behaving quite differently on the build graph. I'd be nice to have a way to distinguish those from the validpath boundary.

human-readable can actually be a drawback for formats specifically designed to be non-malleable, precisely because they invite opening in a text editor and appending some keys in whatever order.

fwiw, https://preserves.dev/ is well-designed, has a superset of JSON types, and has both a textual format and a binary format with a rigidly-defined canonical representation for the latter. however it's also a bit obscure and won't have as wide library support as alternatives so I can understand not going with it. the Spritely/Agoric/Cap'n Proto standardization effort OCapN uses it as Syrup, which is a separate canonical-but-made-up-of-printable-characters serialization of it https://github.com/ocapn/syrup#pseudo-specification.

more well-known alternatives:

• deterministic CBOR serialization, buuuut there are like three versions of it so caveat emptor https://www.imperialviolet.org/2022/04/17/canonsofcbor.html
• canonical s-expressions
• bencode
• …ASN.1 BER? 🙃

also, if you don't actually need a flexible/extensible format, defining your own very simple rigid serialization isn't a sin when you want cryptographic canonicity. (just make sure it's actually non-ambiguous and preferably can't be corrupted into another valid message by truncation, especially if you might be concatenating multiple messages.)