You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project
Godot currently bundles the Mozilla SSL certificate bundle. While this works fine, we can do better in terms of binary size and security.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The benefits of using the system's certificate bundle are:
Smaller binary sizes, since the no longer needs to be embedded into all Godot binaries.
As of writing, the Mozilla certificate bundle is 201 KB. Removing it should allow binaries to be about 200 KB smaller (uncompressed).
Better security and future-proofing for binaries, since Godot will now follow the OS' policies in terms of SSL certificates (new CAs, revocations, …).
More predictable behavior on a given platform, since a SSL certificate considered valid in other applications like a web browser will also be considered valid in Godot.
The downsides are:
Less predictable behavior between platforms, although this is uncommon with common certificate authorities out there (including Let's Encrypt). It's technically possible for a SSL certificate to be considered valid on one platform and invalid on another.
More complex code to handle loading SSL certificates on each operating system. This is especially the case on Linux where certificate bundle paths vary across distributions.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
On Linux, we should probably merge all the certificate bundles that can be found at the standard paths (attempted in a predetermined order).
If this enhancement will not be used often, can it be worked around with a few lines of script?
This is about reducing the editor and export templates' binary sizes and improving security.
Is there a reason why this should be core and not an add-on in the asset library?
See above.
The text was updated successfully, but these errors were encountered:
More complex code to handle loading SSL certificates on each operating system. This is especially the case on Linux where certificate bundle paths vary across distribution.
Well, I think it's going to be far more complex on other OSes.
AFAIK to get the certificates:
On Windows you must use the system certificate store and possibly convert it.
On iOS/macOS I have no idea, but it's likely something similar.
EDIT:
We probably don't need converting, but adding a function to create the certificate from the various parameters instead of the PEM, and then call it (after getting the params) from the OSs implementation. Still, quite some work. Probably something that should be done in OS btw.
Ideally X509Certificate (or Crypto) will have a function load_certificate_from_parameters(...) and then have an OS.parse_system_certs() implemented by each OS. OSes that does not have that implemented could still bundle the certs at build time.
Describe the project you are working on
The Godot editor 🙂
Describe the problem or limitation you are having in your project
Godot currently bundles the Mozilla SSL certificate bundle. While this works fine, we can do better in terms of binary size and security.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The benefits of using the system's certificate bundle are:
The downsides are:
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
On Linux, we should probably merge all the certificate bundles that can be found at the standard paths (attempted in a predetermined order).
If this enhancement will not be used often, can it be worked around with a few lines of script?
This is about reducing the editor and export templates' binary sizes and improving security.
Is there a reason why this should be core and not an add-on in the asset library?
See above.
The text was updated successfully, but these errors were encountered: