Secrets should not be versioned by default

[webpigeon]

After running the installation instructions, there appears to be two files containing secrets. Neither of which is in the gitignore and one of which is already versioned:

.env
.copier/.copier-answers.yml.jinja

Both of these files contain sensitive data that should not appear in version control histories (including tokens and passwords). These files should not be versioned for security reasons, in addition, .env contents will vary across development machines (eg, passwords for staging systems).

I suggest splitting the data into two files, one which is safe to version and one which is not.

[lalitlal]

I propose even a step farther - not having .env at all in the codebase (.env.example, sure), but rather base64 encoding the .env file into the github secrets manager for a specific environment, and loading it up during github actions.

[shippy]

Would some of this be mitigated with secret: true setting for the relevant copier.yml keys? This wouldn't copy them to .copier-answers.yml.

I too am confused as to why .env isn't in .gitignore - although I'm guessing this has to do with the somewhat non-standard decision to share .gitignore between the template and the generated project? Like, in a copier template, I would generally expect all the directories-to-be-copied to be nested under {{project_name}}, and have a separate .gitignore there.

[shippy]

...I think I see why secret: true wasn't used - .copier/update_dotenv.py relies on the presence of secrets in the answer file. One way to avoid this dependency would be to make update_dotenv.py CLI-argument friendly, and pass the secrets directly in the task definition in copier.yml.

Another option: use .env.jinja instead, and add .env to .gitignore? That way, secret values are rendered at generate time in .env, and then git init && git add -A after generation contains neither the new .env nor secrets in the .copier-answers.yml.

Edit: This option does make .copier/update_dotenv.py useless, but I don't think that's a problem - in fact, that allows the template to be used without --trust.

[tiangolo]

Indeed, the idea is that you can continue and modify the project as you see fit, storing passwords and secrets in any system you choose for deployments. But that's something I can't decide and enforce for others, just the starting point. There are many alternatives to handle this, but there's no single obvious one that would work for all use cases, so I would consider it out of scope for this project, at least for now.