RFC: Exposing config hashes within a user facing tool

[KevinJW]

As part of our work in the config group, as well as the potential internal configuration files, I have been trying to think about the implications for users of having more ways to use configs and the implications of what happens when they are shared between different users. For instance:

• How would we validate that an external config is the same as an internal one.
• Would we want to be able to tell the difference between a "white space" change like line endings being switched
• What about other non-functional changes like a description change or other comments

It appears that having an ability to more easily compare the text hashes of a pair of configs would be useful at least in the internal library vs an external one, without archiving/exporting the internal config and then doing our own hash or diff.

For functional differencing, I see the minimum we should probably look to achieve is to document ways of using the existing cache IDs, but it would be nicer if we could provide the users with either a python script or perhaps more ideally a small executable (part of ociocheck ?), that could do some of this for them. (File path hashes are less useful when sharing config

I consider it more important to provide a tool if we agree that being able to determine functional equivalence is useful.

Complications

• If you reorder colour spaces in a file does it match?
• What about other items that also have an implied meaning in the order like traditional displays and views?

I'm of the opinion that we should not embed the hash with the config as we would have to add complexity to ignore the text of the hash, etc.

[doug-walker]

For reference, this feature was discussed during the 2023-07-10 TSC meeting.

Agree with what Kevin wrote above except I think it would be useful to include some sort of checksum in the config itself that could be used as a sort of "anti-tampering" mechanism for workflows that require that sort of assurance. (Obviously this is not going to be a typicaly checksum of the YAML for all the reasons Kevin mentions above, so it should be straight-forward to exclude the checksum itself from the calculation. ICC profiles have a feature like this too.)

Regarding Kevin's question about order, my view is that the order of color spaces in the YAML file should not be considered.