![](https://seccdn.libravatar.org/avatar/a4139df10120ce151e457fd1faff018d.jpg?s=120&d=mm&r=g)
On 27/08/2018 03:30, cunix wrote:
Rémi Verschelde: [...]
I don't think there's much left that can be unbundled in a realistic way. As mentioned, I'm both the upstream maintainer and a RPM packager, and I'm very familiar with unbundling policies.
While Max and me continue trying to package Godot in a form acceptable for Factory, a few other questions arose, i hope Godot experts and Factory policy interpreters can help us with.
Please correct me if my assumption is false, that Godot currently isn't able to consider certificates at run time with trust settings determined from the users machine to verify server certificates used for transport encryption.
Instead, Godot uses a static list of trusted certificates, hardwired during build. This list is bundled in the Godot source code.
While there is no explicit option to unbundle these trusted roots, we were able to replace the Godot "bundle" with an openSUSE "bundle" [1], derived from the "ca-certificates-mozilla" package.
This way i expect the Godot package to get rebuild automatically on obs, if "ca-certificates-mozilla" gets some sort of update.
Questions are:
1. Is such a "replacement" enough and acceptable for Tumbleweed inclusion, or is it undesired and a reason to "decline"?
2. Is this "unbundling" or should we still include a "Provides bundled(ca-certificates-mozilla)" in the spec file?
3. Is it perhaps unacceptable from a security point of view to have a package in the openSUSE distribution, that doesn't use the users system trust settings but is configured to always rely on the openSUSE defaults? (Firefox does something similar but offers a UI to change them).
If you create a bugzilla ticket assigned to security-team@suse.de they will be able to answer the question for you there.
4. Should we take the same approach for some other parts of Godot? For example it might be possible to replace the bundled fonts with their openSUSE counterparts. This will be static as well and not using installed fonts dynamically as far as the fonts in /thirdparty/fonts are concerned.
If it can be done in such a way that means you can use the existing files in /usr/share/fonts its probably worth it, if they would just be splitout and in there own format that no other application can make use of I can't see the point. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B