Mailinglist Archive: opensuse-packaging (104 mails)

< Previous Next >
Re: [opensuse-packaging] Packaging Godot


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@xxxxxxx 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

< Previous Next >
Follow Ups
References