[opensuse-packaging] Packaging Godot

newer
Re: [opensuse-packaging] Packaging...

older
[opensuse-packaging] No Leap repos...

cunix

26 Aug 2018 26 Aug '18

18:00

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). 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. [...] cunix [1] around line 130 of https://build.opensuse.org/package/view_file/home:cunix:branches:games:tools... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Show replies by date

Simon Lees

27 Aug 27 Aug

00:31

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

cunix

22:43

Simon Lees: [...]

...

...
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.

Thanks Simon, the idea was to replace the Godot bundled fonts (and perhaps other parts) with files from an already accepted and reviewed openSUSE package. Benefit from a godot maintainer's point of view would have been, that we don't have to "evaluate" this third party code anymore but can rely on the qualified work done by other openSUSE packagers. Additionally godot would get an automatic rebuild if the "copied" openSUSE package produced an update but the needed Godot release takes longer or doesn't include the most recent third party source. But you're right that these fonts won't be available for other installed software and so it might not be worth to do this copy voodoo. cunix -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ludwig Nussel

07:46

cunix wrote:

...

[...] 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).

In general it's neither advisable to bundle CA certificates nor ssl libraries. Firefox is a bit special as it basically is the reference for the system CA certificates. By installing p11-kit-nss-trust which replaces mozilla-nss-certs Firefox would also load the system wide certs. In case of godot looks like it's using openSSL. Not sure why they are jumping through hoops to make godot read some built in CA bundle. Game developers are hardly in the CA business so if I were them I'd stay away from that as far as possible :-) 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. If you make that a build time configure option you could even try to get the change upstream. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Max Mitschke

18:04

The current build of Godot is set to use openSUSE’s openssl library. The "thirdparty/certs/ca-certificates.crt" file is used to generate a C-header file to be compiled into the program. The ca-certificates.crt file was pulled from an install of Fedora. See: * https://github.com/godotengine/godot/blob/master/editor/SCsub#L65 * https://github.com/godotengine/godot/blob/master/editor/editor_builders.py#L... With cunix’s method, Godot would be updated whenever the ca-certificates packages were updated. As Simon Lees said, we will have to open up a ticket with the security team to get their opinion. Max Mitschke

...

On Aug 27, 2018, at 3:46 AM, Ludwig Nussel wrote:

cunix wrote:

...
[...] 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).

In general it's neither advisable to bundle CA certificates nor ssl libraries. Firefox is a bit special as it basically is the reference for the system CA certificates. By installing p11-kit-nss-trust which replaces mozilla-nss-certs Firefox would also load the system wide certs.

In case of godot looks like it's using openSSL. Not sure why they are jumping through hoops to make godot read some built in CA bundle. Game developers are hardly in the CA business so if I were them I'd stay away from that as far as possible :-) 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. If you make that a build time configure option you could even try to get the change upstream.

cu Ludwig

-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

cunix

22:50

[Full quote to push previous message to Rémi, who might not be subscribed] Ludwig Nussel:

...

cunix wrote:

...
[...] 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).

In general it's neither advisable to bundle CA certificates nor ssl libraries. Firefox is a bit special as it basically is the reference for the system CA certificates. By installing p11-kit-nss-trust which replaces mozilla-nss-certs Firefox would also load the system wide certs.

Thanks for this pointer Ludwig! Me should try it.

...

In case of godot looks like it's using openSSL. Not sure why they are jumping through hoops to make godot read some built in CA bundle. Game developers are hardly in the CA business so if I were them I'd stay away from that as far as possible :-)

Can't speak for upstream but this might be related to godot's use of so called "templates". These are used to to export a game project into single binaries that should run out of the box on various platforms.

...

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.

Thank you very much for figuring this out! You're obviously the expert here. We should try if this can be a solution. But I've to admit that i do not know the innards of the Godot source code and all the openSSL pitfalls. If users are really better off with a patch from a packaging guy who isn't really brave and confident enough, beyond scratching the surface and twisting some existing build options, to fiddle with this security critical part of the code, I'm not sure. Additionally this won't be lasting, as it seems Godot will switch with version 3.1 to mbedtls.

...

If you make that a build time configure option you could even try to get the change upstream.

While i would prefer to get this option from upstream, you're absolutely right ;)

...

cu Ludwig

cunix -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ludwig Nussel

28 Aug 28 Aug

07:15

cunix wrote:

...

Ludwig Nussel: [...]

...
In case of godot looks like it's using openSSL. Not sure why they are jumping through hoops to make godot read some built in CA bundle. Game developers are hardly in the CA business so if I were them I'd stay away from that as far as possible :-)

Can't speak for upstream but this might be related to godot's use of so called "templates". These are used to to export a game project into single binaries that should run out of the box on various platforms.

I can see the motivation for them bundling the CA certs. Especially when they also bundle the SSL lib there is no easy way anymore to talk to the system's CA cert store (if there is any at all). That still doesn't mean it's a good idea :-)

...

...
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.

Thank you very much for figuring this out! You're obviously the expert here. We should try if this can be a solution.

But I've to admit that i do not know the innards of the Godot source code and all the openSSL pitfalls. If users are really better off with a patch from a packaging guy who isn't really brave and confident enough, beyond scratching the surface and twisting some existing build options, to fiddle with this security critical part of the code, I'm not sure.

Well, explaion the issue upstream and ask them to help with the actual code :-)

...

Additionally this won't be lasting, as it seems Godot will switch with version 3.1 to mbedtls.

I am not familiar with mbedtls but usually the problem and solution looks similar with all such libs, just different function names. In the worst case you'd have to specify the path to some legacy location yourself at build time. Allowing to pass a path at build time should be next to trivial for upstream to implement. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

cunix

23:18

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 ;) 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. [...] [1] The two diffs @ https://build.opensuse.org/package/show/home:cunix:branches:games:tools/godo... cunix -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ludwig Nussel

29 Aug 29 Aug

11:25

cunix wrote:

...

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?

Yes. With that you don't need to BuildRequire ca-certificates anymore. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

2076

Age (days ago)

2079

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

cunix
Ludwig Nussel
Max Mitschke
Simon Lees

[opensuse-packaging] Packaging Godot

tags

participants (4)