Bug#953105: gtk-update-icon-cache does not produce reproducible results on 32-bit architectures

[Simon McVittie]

On Thu, 05 Mar 2020 at 18:35:45 -0500, Daniel Kahn Gillmor wrote:
> But if the different arches assume different memory data structures once
> the file is mmapped, then shipping such a file in an arch:all package
> might be dangerously wrong.

>From the code, it looks like the different architectures use the same
in-memory data structures. The lack of reproducibility is from not caring
about reproducibility, not from not caring about portability.

It's all done with fixed-size integers, fixed endianness (network byte
order), "pointers" that are offsets relative to the start of the mmapped
buffer, and a hard-coded hash function (which I'm guessing was the string
hash function used in GLib/GTK 1, but it's hard-coded in the icon cache
implementation so that it will continue to work even if GLib changes
its hash function).

> Those are structured in a well-documented
> way, and libmagic can even detect them.  Can we do the same for a gtk
> icon cache?

It's somewhat well-structured, but not documented except in the code,
and doesn't have a "magic number" that libmagic could use. Recognising
them by filename is going to be the least-bad way.

    smcv