contributing/development/compiling/compiling_with_script_encryption_key

[giscus[bot]]

contributing/development/compiling/compiling_with_script_encryption_key

The export dialog gives you the option to encrypt your PCK file with a 256-bit AES key when releasing your project. This will make sure your scenes, scripts and other resources are not stored in pl...

https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling_with_script_encryption_key.html

[Morokiane]

The environment key is set in only the current terminal session. Once the terminal is closed it is gone.

[Calinou]

If you want it to be persistent, you need to add it to your ~/.bashrc/~/.profile or use setx on Windows. However, persistent storage in those files is discouraged for secrets, as this increases the risk of leaking them (e.g. if you upload your dotfiles to a public Git repository). If you really need to do this, consider storing them in a dedicated file and making sure this file is in your .gitignore so it's not committed to your dotfiles manager.

Something like this:

export SOME_SECRET
SOME_SECRET=$(cat "$HOME/.config/secret.key")

And make sure .config/secret.key is not committed to version control.

[Bastiasa]

The encryption is secure in web exporting? Because I want to make a online multiplayer game and I'm worry about the private key I have in raw GDScript.

[Xevion]

Uh, no. It's not secure.

Of course, the key needs to be stored in the binary, but if it's compiled, optimized and without symbols, it would take some effort to find it.

RTFM, as in, read this page, fully.

[garf]

There is no information on how to compile export templates. Or it means that I have to compile the entire engine?

[Calinou]

Information on compiling export templates is available here: https://docs.godotengine.org/en/stable/contributing/development/compiling/index.html

The process is the same as compiling the editor, except you change the target=editor SCons option (the default if none is passed) to target=template_debug (for a debug export template) or target=template_relese (for a release export template).

[hardaker]

Notes:

1. To manually change the templates in your export settings, you'll need to need to turn on the "advanced options" in the upper right of each thing you want to export.

2. As mentioned in the documentation for windows signing, the encrypted PCK file can't be embedded inside the binary. But this is also true for linux -- ie, if you want to encrypt the PCK it generally can't be embedded and is not specific to windows.

[hardaker]

3. To test that encryption was actually applied to files you care about, use the strings command to look for keywords from your code or directory structure. EG: strings file.pck | grep my_function_name (or my_file.tscn).

[kiswarday]

Why is not the PCK encryption functionality included by default? I understand not everybody needs that and "...the key needs to be stored in the binary...", but with an option in the settings, it should be possible to enable/disable it without recompile

[hardaker]

Because the only way something can be decrypted is if they decryption key is available. So because the user themselves doesn't know it, it must be hidden away inside the compiled running application. Thus you're actually distributing both an encrypted PCK file and an application that knows the key and can thus decrypt it as it loads.

Now, as people have pointed out above, this isn't "really secure" because the key is extractable from the application. It makes it harder to steal, but certainly not impossible.

In short: DRM of any kind is hard and it's always just a cat-and-mouse game between people wanting to steal software and people that want to develop and distribute it.

[garf]

But this is still not the only solution. It still could be possible to use a default approach for an encryption, that would still make it a bit more complex to decrypt. And additionally allow a custom-compiled template, if you really want to play this cat-mouse game better.
It is exactly what it is now. I doubt that many people change anything in the template to encrypt it, so it might as well be just a default checkbox in the editor instead.

[jinyangcruise]

This will not work if you use official, precompiled export templates. It is absolutely required to compile your own export templates to use PCK encryption.

Does this mean that we should use the exact same version of Godot source code to compile the export templates? For example, if the game is developed by Godot v4.5-dev5 then we should use v4.5-dev5 source code to complie the export templates?
Another question, is that necessary to compile our own Godot? Or just compiling the export templates is enough? For example, using Official build of Godot v4.5-dev5 and custom export templates is good? Or using custom build of Godot v4.5-dev5 and custom export templates?

[Calinou]

Does this mean that we should use the exact same version of Godot source code to compile the export templates? For example, if the game is developed by Godot v4.5-dev5 then we should use v4.5-dev5 source code to complie the export templates?

Yes, you should try to use the same version whenever possible. Differing patch versions (e.g. 4.4.1 and 4.4) might work, but any discrepancy in the major or minor version won't work as the PCK file is catered for a specific engine major.minor version.

Another question, is that necessary to compile our own Godot? Or just compiling the export templates is enough?

You only need to compile custom export templates. You can keep using official editor binaries.

[koolibali]

does this consider game assets if not what about them ?

[Calinou]

The PCK file contains game assets, so it will encrypt them too.

[Real-EdgeLord]

I have compiled export templates and the engine for multiple platforms, windows linux and android and the results are not exactly perfect (Using Godot 4.4.1)

1 - do i need to do this to an android build considering that I will have to use a keystore key to make a release build ... or that does not cover everything ?
2 - compiling export templates for x86 for Linux cause a bunch of errors
/usr/include/features-time64.h:20:10: fatal error: bits/wordsize.h: No such file or directory
did not change anything in the code and i can still build the engine and export templates for everything else including windows x86 ... also there are other errors but i did not bother with them
3 - the Linux x64 encrypted build simply did not work in my case the build kept giving

Error: Couldn't load project data at path ".". Is the .pck file missing?
If you've renamed the executable, the associated .pck file should also be renamed to match the executable's name (without the extension).

note that the windows build worked just fine ( trying runing it on bottles it did not work in fact but when i switch to windows it took a bit and then the application worked )

i did mess around with the name (renamed the elf, made sure it is the same as the project name, change the names of both to a, kept them the exact same name exported with, made the export name simple ... nothing)

[Real-EdgeLord]

just tested building export templates at 4.5.1 for linux x86 ... same problem