[Full quote to let the list gain from Rémi's insights] Rémi Verschelde:

@cunix: I'm not subscribed to the openSUSE packaging ML, so I'll let you forward my answer if it doesn't pass through moderation.

Regarding unbundling fonts, I advise not to bother with it for the following reasons:

- The main reason for unbundling fonts in distros is so that all packages can share the same fonts instead of bundling their own, thus reducing the install size on disk by avoiding duplication of data. There's no security risk, so it's much lower priority than unbundling libraries (especially as disk space is cheap).

- One could argue that it allows to use the latest and greatest version of the fonts as packaged on the system instead of the one upstream bundles, but that also implies that we're using a version of the font that upstream did not test - unless the downstream packagers are very experienced with the software they're packaging, it could lead to some issues if the system font is not compatible with the application for whatever reason.

In Godot's case more specifically:

- Godot is designed to be self-contained and portable, so it doesn't rely on anything being installed on the system (apart from the most common system libraries). When packaging for a Linux distro, this is usually not what we want, so we can unbundle more libraries and fonts if needed and hardcore paths to the latter in the binary. It loses its portability but nobody is meant to take /usr/games/godot or /usr/bin/godot to send it to their friends. That said, it means that fonts are compiled into the binary by the buildsystem, so to unbundle them, you have to disable that and also add code to load system fonts (potentially adding a new dependency on fontconfig to Do It Right™). That's non negligible work, for a low priority policy IMO as mentioned above.

- A more compelling reason for *not* unbundling fonts is that, unless you also build all export templates for all platforms (Linux (portable!), macOS, Windows, Android, iOS, HTML5, UWP) with the exact same fonts and provide those to openSUSE users, users of your package would have a different font when testing their game in the openSUSE-packaged editor and when shipping their games with the upstream-provided export templates. And that would be quite bad for the user experience. The same rationale applies to any kind of downstream patching of the editor that would introduce incompatibility with upstream-provided export templates. It *can* be done, but then you'd have to build and package all export templates too, which requires cross-compiling toolchains for the above-mentioned platforms and several hours of build for all those binaries.

- Finally, Godot's fonts are hand-picked to ensure that we have all the symbols we want, especially the now-deprecated DroidSansFallback.ttf and DroidSansJapanese.ttf, which Google stopped distributing, but which is the best we could find to cover most Asian and Arabic symbols with a reasonably sized font (3.6 MB and 1.1 MB respectively).

Thank you so much for this comprehensive explanation Rémi! You convinced me to leave the provided fonts untouched and i hope this will be acceptable for Factory.

2018-08-29 1:18 GMT+02:00 cunix <cunix@gmx.net>:

...

Ludwig Nussel: [...]

...

...

...

Anyways, as you can see in modules/openssl/stream_peer_openssl.cpp there even is a commented call to SSL_CTX_load_verify_locations() "for testing". Pretty close. Replace that with a call to SSL_CTX_set_default_verify_paths(), reduce the built in bundle to not contain any certs at all and you are done. godot will then rely on openssl to read the system wide cert store. [...] Well, explaion the issue upstream and ask them to help with the actual code :-)

Thank you again very much for holding my hand Ludwig!

After some experiments i implemented your suggestion in one patch and added a second one to wrap a build option around it [1]. The bundled certs are removed in the spec file. Does this reflect your ideas?

At least after local compiling that seems to work but we have to test an obs version more in depth.

Because there might be consequences from this patch I'm not aware of or certificates might be in use in other parts of Godot that aren't covered by this solution, i don't feel really comfortable taking full responsibility for it. Rémi, do you want to comment? Please ;)

The certificates bundle is mainly used for the Asset Library, to connect to https://godotengine.org/asset-library, so if that works with [1], that seems good to me.

I tried to connect to the Asset Library from within a patched Godot after deleting the bundled certificates during build, once with a build where "system certificates" was enabled (a) and once disabled (b). The system was configured to only trust the "DST Root CA X3" root CA for the "Let's Encrypt" intermediate CA. (a) showed content, (b) didn't.

Before merging it upstream, we'll likely want to make sure that it works reliably on all distros, and also on other platforms.

Hopefully that can be tested automatically in some way? Access to other platforms i don't have.

For the reference, Godot's certs bundle is also derived from the Mozilla certs data like most distros ship. But it's indeed synced manually so it can get outdated and require a rebuild against a new version, so an option to use the system one would be nice to have.

Yes. In my opinion a major reason for openSUSE preferring to have this option is, that this will reflect the configuration of a user's system dynamically and isn't limited to the default trust settings of neither Mozilla nor the (openSUSE) Distribution.

...

Whether this will survive the switch to mbedtls and if this is something upstream might be interested in, I'm not sure but future will tell.

Should be quite similar for mbedTLS. For upstream reviews, it would be better to start with a patch against the master branch (thus mbedTLS), and only then another one for the 3.0 branch (OpenSSL) once the former is approved.

I might look into this because we would have to do it for version 3.1 anyhow but don't want to promise anything right now. If Godot is accepted for Factory the incentive will probably increase ;)

...

[...]

[1] The two diffs @ https://build.opensuse.org/package/show/home:cunix:branches:games:tools/godo...

cunix

Librement,

Rémi

Thank you again for this detailed help! cunix  -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org