feat: git https credentials for template leak into final repo

[defreng]

Is your feature request related to a problem? Please describe.
Currently, copier does not support Git HTTPS template URLs with included credentials. At least not without leaking these credentials into the .copier-answers.yml file of the target repo.

I.e., commands like this are not a great idea, but there exists no workaround:

copier copy https://myuser:[email protected]/repo.git .

Describe the solution you'd like
It would be great if credentials for cloning the template could be passed during runtime to copier (i.e. through env variables, cli arguments or separate secret files). For example with a command like:

copier copy \
    --template-clone-username myuser
    --template-clone-password secretpw
    https://myrepos.com/repo.git .

These credentials should then not be saved in the target repo - but instead a future user running copier update must supply his own credentials again.

[pawamoy]

Or maybe Copier could detect when git is asking for credentials, and allow the user to input them. It would abort with an error if the force option (no-input option) is used.

[yajo]

Although the issue is valid, currently I just clone private templates by ssh, and I'm happy with it. Proper docs about this would be enough to fix the issue ?

[defreng]

mmh - maybe I need to clarify a bit more:

I don't think the fact that you need to put username/password into the URL when using copier is a problem in and itself - as you mentioned, @yajo , this is probably just a matter of documenting it more clearly.

The main issue I see though, is that these credentials will end up in the .copier-answers.yml of the target repo. And we all know, that you never want to commit credentials to Git 😈

Just as an example, if I use a copier command like this:

copier copy https://myuser:[email protected]/repo.git .

the username and password will end up in the .copier-answers.yml file like this:

# Changes here will be overwritten by Copier
_ssrc_path: https://myuser:[email protected]/repo.git
[...]

[yajo]

Yes, don't worry, I understood you perfectly. But if you use SSH, authentication is automatic and you don't need a password in git URL.

[defreng]

ok 😂 then this ticket is basically about allowing something similar to the SSH usecase, but when SSH is not an option.

This may happen in many cases, such as:

• Git can't be used over SSH because the port is not accessible (i.e. from a corporate network that only allows outgoing HTTP traffic via a proxy)
• When using machine authentication (for example GitLab personal access tokens or group deploy tokens), those mechanisms often only provide a username/token for HTTPS authentication

[shoeffner]

To solve this, use a credential helper as described in conan-io/docs#3683 (comment):

git config credential.helper '!f() { test "$1" = "get" && printf "username=%s\npassword=%s" "${GITLAB_USERNAME}" "${GITLAB_PASSWORD}"; }; f'

to set it up, then set your credentials as environment variables and run copier without specifying it:

export GITLAB_USERNAME=...
export GITLAB_PASSWORD=...
copier copy https://myrepos.com/repo.git .

[reitzig]

Additional use case: our Renovate setup accesses Bitbucket through HTTPS, so we have to use HTTPS with copier as well.
(Or manually exchange _source_path for local operations, meh.)

FWIW, at least copier update does prompt the user for HTTPS credentials -- multiple times. 😅

[yajo]

Interesting solutions. see also these docs:

• https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage#_credential_caching
• https://git-scm.com/docs/gitcredentials