gp credential-helper blocks basic auth for unknown hosts

[arranstewart]

Bug description

One of the changes GitPod makes to custom Docker images seems to be that it adds a ".gitconfig" file for the gitpod user, containing the following:

[credential]
        helper = /usr/bin/gp credential-helper

This is a bit impolite, and interferes with the user's ability to provide credentials via (e.g.) basic authentication to non-GitHub servers. (Running with GIT_TRACE=1 shows that /usr/bin/gp credential-helper is being invoked for all repositories.) So, for example, if a user adds a non-GitHub remote that uses basic authentication and tries to pull from or push to it, they'll continually get an authentication error.

It would probably be better if GitPod added something more like the following fragment in .gitconfig:

[credential "https://github.com"]
        helper = /usr/bin/gp credential-helper

(the same as if git config --global credential.https://github.com.helper "/usr/bin/gp credential-helper" were invoked), as this limits the credential-helper to operating on GitHub repositories.

Steps to reproduce

• Add a non-GitHub remote that uses basic authentication
• Push to the remote

Expected behavior

• User should be prompted to supply credentials

Example repository

No response

Anything else?

No response

[akosyakov]

gp credential helper is not specific to GitHub. It takes a host for a given git operation and ask Gitpod for a token for such host. Gitpod account can associate additional Git integrations here: https://gitpod.io/integrations

cc @AlexTugarev could you check this request too?

[arranstewart]

It may not be specific to GitHub, but it does seems to be specific to the limited case where the server the remote is on can be added via your "integration" page -- i.e., it supports one of two "provider types" (GitLab and GitHub), and (I presume) acts as an OAuth2 provider. (I'm just taking this information from the "integrations" page you linked to.)

However, there are plenty of Git repository hosting providers that aren't OAuth2 providers (e.g. self-hosted instances of GitLab, or smaller hosting providers like SourceHut and RocketGit) - if a user happens to want to add one of them as a secondary remote, how can they authenticate in order to push to or pull from repositories with that provider?

And "Git servers" generally covers a very wide range of hosts a user might want to add as a secondary remote. The use case I'm referring to in my bug report is where the user adds a remote located on a server which uses the Git "smart http" protocol, and uses basic authentication over that. Obviously, such a server need not not be hosted by GitLab or GitHub, nor need it be an OAuth2 provider - I have one up at the moment, in fact, at https://assignment1.cits4407.arranstewart.info (though it only has private repositories on it). If a user adds such a server as a remote, then, as I say, the current settings mean the gp credential helper will prevent them from sending proper credentials to the server.

There is a straightforward fix for this, on my part - I can just add a command in the gitpod user's .bashrc that executes the commands

git config --global --unset credential.helper
git config --global credential.https://github.com.helper "/usr/bin/gp credential-helper"

so that the credentials helper stops interfering with the secondary remote.

However, I assumed that the credentials helper intervening for all authentications, when it clearly in some cases doesn't have the capacity to handle them properly, couldn't be intentional on your part and must be a bug. But if this is the intended behaviour, feel free to close and I'll work around it.

[AlexTugarev]

Hi @arranstewart,
Thanks for reporting! There is indeed no reason for the gp credential-helper to handle "unknown" providers. We'd need to see how to exit, or what exactly to return on such calls, so that it falls back to the CLI.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.