Git: find a "better" way to handle tokens than git credential store

Mentioned in https://github.com/huggingface/huggingface_hub/issues/1043#issuecomment-1246009544.

Currently we store the user token for git commands in the git-credential-store. This is the default git storage that stores creds in plain text in a file. huggingface_hub warns the user to use it by default to avoid problems (by running git config --global credential.helper store). In a perfect world, it would be good to use the default credential helper from the user. In particular, macos users have a macosxkeychain tool by default to securely handle credentials.

Another possibility is to not store the credential in git and automatically fill the values (from python) when git requires them (in the Repository module).

Note: I am no expert on that topic so any addition is welcomed here 😃

Useful links:

• git credentials doc
• git-credential-store doc (the one we use, stores the password in plain in a file)
• git credential doc (higher-level API to abstract the store helper)

(Edit: also to mention that when a user do huggingface-cli login or notebook_login(), the token is also stored locally in plain text in the home directory ~/.huggingface/token to be reused in API calls. Changing this is out of topic for this issue)

[Wauplin]

I just made some tests with the abstract level that git uses (git credential [fill|approve|reject])

If I run:

git credential approve
url=https://huggingface.co
protocol=https
host=huggingface.co
username=hf_user
password=hf_****

It will store the credentials in the default helper defined on the user’s machine.

So what we could do is to simply change the current command (from write_to_credential_store)

git credential-store store
url=https://huggingface.co
username=hf_user
password=hf_****

with its abstract version. Same for deleting the token (currently using git credential-store erase).

---

Using the default git helper on the machine instead of store will be cleaner:

• for macos users using xkeychain by default
• for any users using a secure helper of their choice
• for any users using store (doesn’t change for them compared to the current situation)

And for users without any git helper configured (e.g. me until 1 week ago 👋), we either show a warning or help them configure a git helper though a CLI. This is already the case anyway.

---

EDIT: implemented workflow slightly differs from the one below (see description in https://github.com/huggingface/huggingface_hub/pull/1138#issue-1427111831)

Side note from @julien-c: we need to think about the case where a token is already stored in the user helper (as we do not want to overwrite an existing value).

To summarize, here is a workflow I see:

1. If huggingface-cli login:
   1. if git helper configured
      1. if a “huggingface.co” value is already stored: print a warning “A token is already stored in your git credential helper. If you want to update it, please delete it manually first.” (alternatively, prompt “Do you want to erase current stored value ? [y/n]”)
      2. if no existing value: add the entry using git credential approve
   2. if git helper is not configured
      1. warning message “hey you should use a git credential helper if you want to be fully integrated”
      2. alternatively: prompt “Set git-credential-store as default ? [y/n]” (or maybe propose a list: git-credential-cache, xkeychain, git credential manager,…)
      3. alternatively: make git-credential-store default without asking and store the value there
2. If notebook_login() in a google colab
   1. Use git-credential-store as default. No warning message. It is usually run on a temporary machine anyway. Same as current main branch (since this recent PR https://github.com/huggingface/huggingface_hub/pull/1053)
3. If notebook_login() not in a colab: we assume this is a machine owned by the user so same as huggingface-cli login
   1. if git helper configured
      1. if a “huggingface.co” value is already stored: print a warning
      2. if no existing value: add the entry using git credential approve
   2. if git helper is not configured
      1. same as with huggingface-cli but if it starts to be complicated (menu/prompt something), just put a warning “hey, please use the CLI”

Does that cover every possible use case?

[Wauplin]

huggingface-cli login to still have side-effects on non-python-runtime tasks. (…) However, I would expect the following workflow to work as well (and so do users, as we have had this issue in the past):

huggingface-cli login
git clone https://huggingface.co/<PRIVATE_REPO>

Thanks for reminding this here @LysandreJik ! TBH I completely forgot about this aspect. Dunno yet how to tackle the issue but good to know that the solution has to be through git credential.