Re: Next steps for a reproducible Fontconfig?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Thu, Jan 31, 2019 at 9:40 AM Keith Packard <keithp@xxxxxxxxxx> wrote:
> Alexander Larsson <alexander.larsson@xxxxxxxxx> writes:
> > We don't want a global salt for everything in the container.
> I guess I wonder why not? Salt + dir inside the container will always be
> unique. The place where you want to have different salt is for
> directories mapped from the host; I think those will always be in
> remap-dir clauses, if we have salt there, that should work?

It will be unique per runtime, as the default salt comes from the
runtime generated file in the sandbox.
But, if multiple apps use the same runtime they will always use the
same salt for its /app/share/fonts, even though it could differ, which
seems risky.
But worse, if the runtime changes the default salt, then the caches
built into the app will be for the wrong salt until the app is

> > In
> > reality things are more complicated than that. For example, an app may
> > bundle fonts, which will be in like /app/share/fonts, in addition to
> > the runtime fonts in /usr/share/fonts. These come from different
> > places and may individually be different in a different (or updated)
> > app, so the directories need to have different salts.
> If building the flatpak generates the font caches, then per-flatpak salt
> would make those correct.

Only as long as the runtime salt doesn't change. But its also a
robustness issue, if for whatever reason (cache version, etc) a cache
is generated for the app dir I want that to map to a uniqe cache id
rather than one shared between every app using that runtime.

> > Also, it is quite possible that some host font directory is *not*
> > remapped, but still visible to the app. For example /opt/fonts for an
> > app that has filesystem access. If for whatever reason fontconfig
> > looks at this directory it should not apply any salt for it.
> Oh, so some host directories may be visible unmapped and unknown to the
> flatpak? In that case, we'll need to enumerate all flatpak visible font
> directories separately.

What happens today is that if you host has fonts somewhere, say
/opt/fonts, and the app has --filesystem=host access, then /opt will
be visible as-is in the sandbox (along with essentially everything but
/usr and /app).

These directories are not (currently) added to the fontconfig setup in
the sandbox, so it will not be automatically picked up. But that
doesn't mean fontconfig in the sandbox can *never* see it. For
example, the app could call FcConfigAppFontAddDir() if it has a
per-app font dir option or something.

We *could* make flatpak enumerate *all* configured host font
directories and set up snippets for them. However, currently we don't,
and I don't see a huge need for this.
Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux