[Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Sun, Jan 13, 2019 at 7:21 PM Keith Packard <keithp at keithp.com> wrote:
> > Yes:ish. It should not *normally* happen. But you may run into it in
> > uncommon situations like e.g. chrome using a statically linked version
> > of fontconfig that has a different fontconfig cache format.
>
> Hrm. I don't get the sense that we've got a solution to this problem
> yet. Given that the contents of the flatpak cannot change on the fly,
> would it be sufficient to generate a new 'salt' value for the flatpak
> each time it is changed? It might be sufficient to use the name of the
> flatpak including a version as this salt (that has the advantage of
> making the flatpak reproducible, which you probably want to encourage).

The plan was to generate a new random salt each build. We *do* in
general want to make flatpak builds as reproducible as possible,
because the magic of ostree means identical files are deduplicated on
disk and not downloaded on updates. However, if fixed set of small
files change each build that is not a huge problem.

So, in such a setup we're ok as long as the statically linked
fontconfig is new enough to respect the salt config.

However, we could run into issues if e.g. chrome statically links to
an older fontconfig. Such fonconfig versions would ignore the salt,
and miss the runtime-shipped caches, instead picking up the host
caches. It seems in that case the host cache would have a mismatching
mtime though, and we'd generate a new one, plus we'd regenerate the
host cache for the remapped dir. So this should work, at some cost in
performance.

> > Yeah, there will be two files. One static in the runtime
> > (/etc/fonts/conf.d/50-flatpak.xml), and one generated by flatpak
> > (/run/host/fontconf.xml).
>
> Sounds like we've got a plan for this part -- fix my mapping code to use
> config bits separate from the <dir> elements, then add a 'salt'
> mechanism in the config bits that stirs in some random data when
> generating the cache keys for specific directory trees.
>
> Let's figure out how we should handle the stale flatpak fonts cache
> issue. Once we've settled that, we can go implement the whole mess and
> get a new fontconfig release made in time for debian freeze.

Sounds good to me. Actually, i'm planning a flatpak stable (1.2)
release in the next few weeks, and I would like to add support for the
flatpak-side of this to the release. So, if we can just decide the
syntax for the dir remapping bits now I can add support for that. Then
we can do the runtime part when there is a fontconfig release that
supports it.