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 -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
