On Monday, February 5, 2024 5:18 PM, brian m. carlson wrote: >On 2024-02-05 at 03:01:17, Quentin Bouget wrote: >> Good point, I had not considered the security implications. >> >> I can see libcurl only reuses credentials after a redirect if the >> hostname has not changed: [1] >> >> By default, libcurl only sends credentials and Authentication >> headers to the initial hostname as given in the original URL, to >> avoid leaking username + password to other sites. >> >> Does it sound OK if I use the credentials provided by the redirect >> when there are any (out of consistency with the current >> implementation), and only allow reusing the current credentials when >> the redirect and the original URLs share the same hostname? > >I don't think we can actually rely on that functionality because >`credential.usehttppath` could actually have been set, in which case we'd need a >different credential. For example, I know some forges issue certain types of tokens >that are tied to a specific URL and wouldn't validate for a redirect, even if it were >actually the same repo. > >If there are credentials in the URL provided by the redirect, I think it should be safe >to use them; otherwise, we'd need to rely on filling them with the credential >protocol. > >> Apologies, I feel like I may have given the impression I wanted to >> configure credentials in git's configuration files, which is not the >> case. >> >> My use case is to `git push` a tag from a CI/CD pipeline to trigger a >> release, similar to how I do it here. [3] >> >> Or is this the kind of use case you are trying to discourage? > >We're trying to discourage all use of credentials in the URL at the command line and >in remote names/configuration files. If you want to pass in credentials from the >environment, the Git FAQ explains how to do that[0], and that technique can be >used in such a situation. > >[0] https://git-scm.com/docs/gitfaq#http-credentials-environment A common side-use case (not directly in git) for this situation is to attempt to use curl (or libcurl) to create a Pull Request via the GitHub (or other enterprise git server) CLI or POST. This is most often done via REST rather than supplying via the URL. It does remove the need to pass some credentials (a.k.a. the API token) via the URL as the API token gets injected into the JSON content - this may have been the original motivation as many of the servers do redirects. However, they do not reprocess or inject different credentials. I am wonder about the specific use case is for this situation and why a redirect injects a credential change, which I cannot see is a good thing. --Randall
