Keep export_presets.cfg in source control without exposing secrets

Question

The source for my Godot 4 game is public and open. With exports targeting Web, Linux, or Windows this was just fine. However, now I'm trying to target macOS with an export as well. This includes signing and notarizing the app (as I suspect Android and iOS targets would need too) with specific secrets.

These secrets should not go into the public source but, well... be kept secret. I cannot find any good documentation on how to do this. I've checked:

• The Command line tutorial
• The Exporting for macOS documentation

As well as other bits of the documentation and online search results. None of them have any definitive advice on how to handle this situation. But perhaps I've not been reading of searching precisely enough?

The closest I've come is what the .gitignore from godot-demo-projects seems to do: just ignore exports_presets.cfg and presumably have secrets inside that file. That has two major downsides for me:

1. A ton of other non-secret export settings are now no longer under source control;
2. You're one git mistake away from making your secrets public.

I must be missing something, because anyone who wants to make a notarized macOS export for a Godot game will encounter this situation. Even if your source code is private, you'd not want to have secrets in there in plaintext, right?

How do you keep export secrets safely outside of the game code repository, without giving up on all source control of non-secret export settings?

I'm happy to utilize any Godot 4 feature as I'm on the latest major release, but I reckon others might be interested in a Godot 3.x solution as well.

Answer 1

The way I currently handle this is as follows:

• The developer responsible for release keeps a local branch with the changes that add the secret details to exports_presets.cfg.
• When we want to release, that developer merges the main branch into that local branch, so he can export the release build of the game.

The shared exports_presets.cfg can have enough information to make some debug builds, which are useful for testing by other members of the team. However it does not contain enough information to make the release builds which require additional credentials.

---

On safeguards

First of all, if you automate your build process (which you can with Godot command line arguments) then you can have your build script merge in the correct way.

---

Now, if you want to prevent people from merging the wrong way, you could use Git Hooks. You want a pre-merge-commit. Which you create with a shell script called pre-merge-commit (no extension) in your .git/hooks folder. Git will honor the shebang (#!) at the start of the file.

To prevent the merge, the script must end with a non-zero exit code. Also, if Git fails to execute the script (e.g. it could not resolve the shebang) it will not merge.

Notes for the shebang in Windows:

• The path using / as folder separator character will work.
• You need to escape spaces and dots with \.
• You don't need to include the executable extension .exe.
• A path that starts with / will be relative to the installation folder of Git.

As a result #!/bin/bash and #!/bin/sh will resolve to \bin\bash.exe and \bin\sh.exe respectively, in the Git installation folder (e.g. C:\Program Files\Git\). In fact, \bin\bash.exe and \bin\sh.exe are provided with the installation of Git for Windows. So you can use either #!/bin/bash or #!/bin/sh cross platform.

Here is an example of what you want: pre-merge-commit.

---

Be aware that the Git Hooks are in the .git/hooks folder, and thus not in source control.

You might not need to deploy the Git Hooks, since only the developer that builds the game would be in the situation to make the mistakes necessary to leak the information.

However, one option to deploy them would be to use a template directory which would have to be part of the development environment on the target machines. And you could protect that with OS level security, and you want the option to boot from another device protected with a password so they don't bypass OS level security, and and you want physical security to prevent other means.

But assuming you can trust your developers, then adding a script in your repository that deploys the Git Hooks should be sufficient.

In fact, we can assume that you trust in particular the developer that has the exports_presets.cfg with extra credentials, since they have extra credentials. So probably you can trust they will run the script to build the game, and you don't need Git Hooks.