Secret-passing mechanism

[gouttegd]

Workflows sometimes need to have access to some informations that are too sensitive to be written down in the custom $ont.Makefile (or any other file committed to the repository). For example, a GitHub token (to make a GitHub release and push release artefacts), an OpenAI token (for workflows that use OpenAI services, like the new I18N stuff), etc.

For now, whenever the need to pass a sensitive information arises, we devise custom solutions. For example, the need to pass a GitHub token is handled by specific code inside the run.sh launcher script.

It would be useful to have a generic mechanism to pass sensitive information from the user’s machine to the ODK container – a mechanism that could be implemented once and for all and would not need to be modified explicitly every time we have a new sensitive piece of information to pass.

[gouttegd]

Random thoughts:

Scope limitation. It is not within the scope of this putative mechanism to protect sensitive informations against an attacker on the user’s machine. The user’s machine is assumed to be safe. If it is not – if an attacker has access to it, physically or remotely, then the user is screwed and there’s nothing the ODK can do.

So requiring that at some point an information must be stored in plaintext in a local file would be fine. Passing information on the command line would be fine. We are not concerned about the possibility that an attacker could read the shell’s history log and retrieve past commands with secrets in them – if the attacker can do that, the user has already lost.

The most important concern is ensuring that sensitive informations do not end up being committed to the repository.

Not for execution in GitHub Actions. The mechanism would be intended for local use on the local machine. It would not be intended to pass sensitive informations for when a workflow is run as part of a GitHub Action. GitHub already provides a way to do just that – “secrets“ –, we don’t need another one.

Common method to access both ODK secrets and GitHub secrets? Since GitHub already provides a way to pass secrets to workflows in GitHub Actions, it would be nice if we could have a single method to access a secret regardless of where a particular workflow is run – locally or in a GitHub Action. That is, we somehow declare that a workflow needs a particular secret (say, OPENAI_API_KEY), and when the workflow runs locally (with the user calling sh run.sh make my_workflow) the secret is passed to the ODK container using the mechanism we are envisioning here, and if/when the same workflow is run as part of a GitHub Action, the secret is obtained through GitHub’s “secrets“ system. (Absolutely no idea right now how we could do something like that or if it is even feasible, but would be neat.)