Ship our own credential helper on Linux

[gaborcsardi]

This is tricky for many reasons:

• should the credential helper call R? That is messy and not super reliable. Or should it be a standalone binary? That seems like a better option.
• how should be actually store credentials. We need to look at what gh does Linux. It apparently installs its own handler and stores credentials internally:

  root@99340efa4c28:~# cat .gitconfig
  [credential "https://github.com"]
      helper =
      helper = !/usr/bin/gh auth git-credential
  [credential "https://gist.github.com"]
      helper =
      helper = !/usr/bin/gh auth git-credential
  

[gaborcsardi]

Well, gh does implement a very simple credential helper that just stores the tokens in the gh config files, in plain text:

root@99340efa4c28:~# cat .config/gh/hosts.yml
github.com:
    oauth_token: <token>
    user: gaborcsardi
    git_protocol: https

So this is not any better than the built in "store" credential helper that stores the tokens in ~/.git-credentials.

We could certainly have something like this in gitcreds, but it seems questionable to introduce yet another plain text file with credentials.... we could store it the same place as gh, though.

[jthomasmock]

Just expressing interest in this feature!

We have seen a number of folks struggle when transitioning from RStudio Desktop to Posit Workbench or RStudio Server as they are relying on guidance from Happy Git with R or the underlying gitcreds workflows.

[gaborcsardi]

@jthomasmock As AFAIK there is no way to store credentials in Workbench currently (but FIXME), I think we cannot do better than the built-in 'store' credential helper, which just writes the credentials to plain text files.

But then maybe we could help the user set that up, with documentation and possibly a helper function?

[jthomasmock]

I honestly think that writing to the .Renviron file would be fine as that's generally what we would recommend anyway. On Linux, would it make sense to just stick with that?

https://happygitwithr.com/https-pat.html?q=renviron#pat-doesnt-persist-on-linux

IE have gitcreds::gitcreds_set() write out to .Renviron and then it could get pulled with gitcreds::gitcreds_get()? This could still be transparent through the messaging of gitcreds:

#> -> Your current credentials for 'https://github.com':
#> 
#>   protocol: https
#>   host    : github.com
#>   username: gaborcsardi
#>   password: <-- hidden -->
#> 
#> -> What would you like to do?
#> 
#> 1: Keep these credentials
#> 2: Replace these credentials
#> 3: See the password / token
#> 
#> Selection: 2
#> 
#> ? Enter new password or token: secret
#> -> Removing current credentials...
#> -> Adding new credentials to .Renviron...  <---- something like this.
#> -> Done.

[gaborcsardi]

A proper credential helper has many advantages over storing credentials in .Renviron. Although gitcreds supports setting host-specific credentials (e.g. GitHub, GitLab, Azure, etc.) from env vars, it does not support other customization, e.g. repository-specific (URL-specific) credentials and other possible customizations. These only work with a proper git credential store.

The other main advantage is that if we use a credential helper, then command line git, (and every other tool that uses the credentials store, like the github cli, etc.) will be able to use that.

[gaborcsardi]

I just tried calling

system("git config --global credential.helper store")

on colorado, and it seems to work well.

What's somewhat surprising to me is that different sessions share the same home directory, so you'll get one set of credentials across all sessions. I guess that is a feature.

So I think that we would need to update our advice in usethis and in gitcreds as well, probably, to say that people should set up the 'store' credential helper.

[jthomasmock]

Thanks for looking into this Gabor!

What's somewhat surprising to me is that different sessions share the same home directory, so you'll get one set of credentials across all sessions. I guess that is a feature

Yes, we persist information into the user's directory in NFS, so that users can safely resume or work on various projects over time.

---

If I recall correctly, @leesahanders and @Rikagx were facing an issue with persisting the config, and after referencing this blogpost they ended up trying:

git config --global credential.helper 'store --file ~/.my-credentials'
# OR
git config --global credential.helper 'cache --timeout=10000000'

Lisa or Rika, was that able to persist the behavior for both the shell and RStudio?

[leesahanders]

@jthomasmock Happy to confirm that using git config --global credential.helper 'store --file ~/.my-credentials' worked for me for persistence. This was especially useful for testing on a Sagemaker deployment where the home directories persist but any files saved onto the transient EC2 local drive would be lost once the session was spun down.

Unfortunately the downside to this method is that the file isn't saved with any encryption, which could be a problem for enterprise customers with security requirements. Would love thoughts for any other options that could be explored! The blog post mentioned by @jthomasmock suggested libsecret and gcm core, possibly worth considering recommending as part of the Workbench installation?

[gaborcsardi]

Yeah, that blog post is geared towards a desktop Linux I think. The cache helper is not great for workbench because it stores the credentials "in" a background process, so if the session is paused then I think that process dies. Setting a longer timeout does not help with this.

So we are left with the store credential helper.

[jthomasmock]

So we are left with the store credential helper.

Which isn't WORSE than .Renviron but is better for both terminal and R/RStudio use.

[gaborcsardi]

Why do you actually think it is worse than .Renviron? I would say that it is not more or less secure and it is much more flexible.

[gaborcsardi]

Re libsecret, we cannot use that in workbench, in practice it requires a GUI, and it is very hard, possibly impossible to make it work at the command line.

[jthomasmock]

Why do you actually think it is worse than .Renviron? I would say that it is not more or less secure and it is much more flexible.

Apologies for the double negative.

I think that store is better, ie NOT any worse than .Renviron, both have some issues in being plain-text, but store is directly tied to git.

[gaborcsardi]

Apologies for the double negative.

Apologies for not being able to read. 🙈