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.

[tylermilner]

After generating a project from this template (using copier), I was about to open another issue/discussion for this (luckily I searched first 😅).

I get not wanting to be prescriptive about what system is used for secrets management and deployment, but I don't think that making the project insecure by default is the right answer.

The project readme barely mentions anything regarding this (which is a stretch to even infer that the .env will not be automatically ignored by source control):

You can (and should) pass these as environment variables from secrets.

By the same logic, there are also a lot of source control technologies that one might consider using (e.g. Subversion, Mercurial, etc.), yet this project assumes that you're using Git (i.e. generates a .git directory, .gitattributes, .gitignore, etc. as part of the output). If we were truly trying to be tool agnostic, a Git repo wouldn't be auto-generated/provided when creating a project using this template.

So, if we are going to assume you're using Git, we should at least go ahead and have the generated project be set up with some sort of standard secure secrets managements mechanism. Having the .env in the .gitignore seems like the bare minimum (and is a very common practice). My vote is to have a .env.example that gets auto-copied to .env as part of the copier template generation process (with corresponding manual steps for those forking the repo), and have the generated .env already be part of the .gitignore.

We should be taking an approach of being secure by default rather than expecting users to notice and adopt it themselves. At the very least, this should be explicitly called out in the readme and be part of the initial setup steps to have users address it themselves before they potentially push their code to a remote.