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.