* git credential doesn't honor git config precedence rules
@ 2023-03-22 16:45 Coirier, Emmanuel
2023-03-22 17:19 ` Jeff King
0 siblings, 1 reply; 3+ messages in thread
From: Coirier, Emmanuel @ 2023-03-22 16:45 UTC (permalink / raw)
To: git@vger•kernel.org
Hello everyone,
I think I found a bug with git credential: this tool doesn't call
the configured credential helper following the configuration rules.
It calls the system configured credential helper (git config --system) even if another one
is configured (ie: at the global level : git config --global).
The problem I encountered is that the configured system one (manager-core
in my case) answers a wrong value instead of giving up. The globally
configured (wincred in my case) is then not called at all and my
authentication just fail without any way to manually enter login & pass.
Here is some details to reproduce what I think is a bug.
> What did you do before the bug happened? (Steps to reproduce your issue)
# Setup phase
# The purpose is to show that "git credential" & friends don't honor the
# config precedence rule when launching the credential helper
# I set the system credential helper to a nonexistent credential helper
# to provoke an error message later
$ git config --replace-all --system credential.helper "bla"
$ git config --get --system credential.helper
bla
# The global (per account) credential helper is an existing one
$ git config --get --global credential.helper
wincred
# this is the computed one based on the precedence rules
$ git config --get credential.helper
wincred
# Bug phase
$ git credential fill << EOF
> protocol=http
> host=<some internal host>
> path=<some internal path>
> EOF
> What did you expect to happen? (Expected behavior)
protocol=http
host=<some internal host>
username=<some local user>
password=<the password>
> What happened instead? (Actual behavior)
git: 'credential-bla' is not a git command. See 'git --help'.
protocol=http
host=<some internal host>
username=<some local user>
password=<the password>
> What's different between what you expected and what actually happened?
In this example, the "bla" credential helper is called
even if the wincred should have been the only one to be
called.
The result is OK since the "bla" credential returned a non
zero return code, then the global credential helper (wincred) was called.
Let's see what happened with a "zero returning" credential
helper :
> Anything else you want to add:
Let's replay the same scenario with the real "manager-core" credential helper
> What did you do before the bug happened? (Steps to reproduce your issue)
# Setup phase
$ git config --replace-all --system credential.helper manager-core
$ git config --get --system credential.helper
manager-core
# The global (per account) credential helper is still an existing one
$ git config --get --global credential.helper
wincred
$ git config --get credential.helper
wincred
# Bug phase
$ git credential fill << EOF
> protocol=http
> host=<some internal host>
> path=<some internal path>
> EOF
> What did you expect to happen? (Expected behavior)
protocol=http
host=<some internal host>
username=<some local user>
password=<the password>
# wincred would have been called and had returned what it learned before
> What happened instead? (Actual behavior)
protocol=http
host=<some internal host>
username=
password=
$ echo $?
0
# username and password are left empty, but the system credential helper
# didn't returned a non-zero return value, not triggering the global
# credential helper.
> What's different between what you expected and what actually happened?
Two problems :
- the manager-core credential manager didn't answer some login or
password nor prompted the user for anything. I'm not sure this
should be the good behavior, but it's not our concern here.
- the manager-core has been called despite the fact the global configuration
should have been used, letting only wincred filling the request.
[System Info]
git version:
git version 2.37.3.windows.1
cpu: x86_64
built from commit: c4992d4fecabd7d111726ecb37e33a3ccb51d6f1
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19045
compiler info: gnuc: 12.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Developpement\Git\usr\bin\bash.exe
[Enabled Hooks]
(none)
Best regards,
--
Emmanuel Coirier
Interne
Ce message et toutes les pièces jointes (ci-après le «message») sont confidentiels et établis à l’intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. Si vous recevez ce message par erreur, merci de le détruire sans en conserver de copie et d’en avertir immédiatement l’expéditeur. Internet ne permettant pas de garantir l’intégrité de ce message, la Caisse des Dépôts et Consignations décline toute responsabilité au titre de ce message s’il a été modifié, altéré, déformé ou falsifié. Par ailleurs et malgré toutes les précautions prises pour éviter la présence de virus dans nos envois, nous vous recommandons de prendre, de votre côté, les mesures permettant d'assurer la non-introduction de virus dans votre système informatique. This email message and any attachments (“the email”) are confidential and intended only for the recipient(s) indicated. If you are not an intended recipient, please be advised that any use, dissemination, forwarding or copying of this email whatsoever is prohibited without prior written consent of Caisse des Depots et Consignations. If you have received this email in error, please delete it without saving a copy and notify the sender immediately. Internet emails are not necessarily secure, and Caisse des Depots et Consignations declines responsibility for any changes that may have been made to this email after it was sent. While we take all reasonable precautions to ensure that viruses are not transmitted via emails, we recommend that you take your own measures to prevent viruses from entering your computer system.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: git credential doesn't honor git config precedence rules
2023-03-22 16:45 git credential doesn't honor git config precedence rules Coirier, Emmanuel
@ 2023-03-22 17:19 ` Jeff King
2023-03-23 10:34 ` Coirier, Emmanuel
0 siblings, 1 reply; 3+ messages in thread
From: Jeff King @ 2023-03-22 17:19 UTC (permalink / raw)
To: Coirier, Emmanuel; +Cc: git@vger•kernel.org
On Wed, Mar 22, 2023 at 04:45:51PM +0000, Coirier, Emmanuel wrote:
> I think I found a bug with git credential: this tool doesn't call
> the configured credential helper following the configuration rules.
>
> It calls the system configured credential helper (git config --system) even if another one
> is configured (ie: at the global level : git config --global).
That's because credential helpers are not a single variable where later
entries override earlier ones, but is actually a list of helpers to
execute. From "git help credentials":
If there are multiple instances of the credential.helper configuration
variable, each helper will be tried in turn, and may provide a
username, password, or nothing. Once Git has acquired both a username
and a password, no more helpers will be tried.
> The problem I encountered is that the configured system one (manager-core
> in my case) answers a wrong value instead of giving up. The globally
> configured (wincred in my case) is then not called at all and my
> authentication just fail without any way to manually enter login & pass.
If you want to clear any prior entries in the list, you can do that
explicitly. From the paragraph right below the one quoted above:
If credential.helper is configured to the empty string, this resets
the helper list to empty (so you may override a helper set by a
lower-priority config file by configuring the empty-string helper,
followed by whatever set of helpers you would like).
> > What's different between what you expected and what actually happened?
>
> In this example, the "bla" credential helper is called
> even if the wincred should have been the only one to be
> called.
>
> The result is OK since the "bla" credential returned a non
> zero return code, then the global credential helper (wincred) was called.
Right, this is the correct and documented behavior. You'd just want to
reset the list in your local config like:
git config --global credential.helper ""
git config --global --add credential.helper wincred
-Peff
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: git credential doesn't honor git config precedence rules
2023-03-22 17:19 ` Jeff King
@ 2023-03-23 10:34 ` Coirier, Emmanuel
0 siblings, 0 replies; 3+ messages in thread
From: Coirier, Emmanuel @ 2023-03-23 10:34 UTC (permalink / raw)
To: Jeff King; +Cc: git@vger•kernel.org
Dear Jeff,
Thank you for your very instructive answer. I realized that I was only at the half of my journey though the credential system (and the config system also).
I'm still struggling with the manager-core helper that doesn't want to prompt me anything and persist to return blank user and password despite the fact it has no idea of the real values, but this is another story.
Best regards,
--
Emmanuel Coirier
Interne
> -----Message d'origine-----
> De : Jeff King <peff@peff•net>
> Envoyé : mercredi 22 mars 2023 18:20
> À : Coirier, Emmanuel <Emmanuel.Coirier@caissedesdepots•fr>
> Cc : git@vger•kernel.org
> Objet : Re: git credential doesn't honor git config precedence rules
>
> [EMETTEUR EXTERNE] : Soyez vigilant avant d’ouvrir les pièces-jointes ou de
> cliquer sur les liens. En cas de doute, signalez le message via le bouton «
> Signaler un courriel suspect ».
>
> On Wed, Mar 22, 2023 at 04:45:51PM +0000, Coirier, Emmanuel wrote:
>
> > I think I found a bug with git credential: this tool doesn't call the
> > configured credential helper following the configuration rules.
> >
> > It calls the system configured credential helper (git config --system)
> > even if another one is configured (ie: at the global level : git config --global).
>
> That's because credential helpers are not a single variable where later entries
> override earlier ones, but is actually a list of helpers to execute. From "git
> help credentials":
>
> If there are multiple instances of the credential.helper configuration
> variable, each helper will be tried in turn, and may provide a
> username, password, or nothing. Once Git has acquired both a username
> and a password, no more helpers will be tried.
>
> > The problem I encountered is that the configured system one
> > (manager-core in my case) answers a wrong value instead of giving up.
> > The globally configured (wincred in my case) is then not called at all
> > and my authentication just fail without any way to manually enter login &
> pass.
>
> If you want to clear any prior entries in the list, you can do that explicitly.
> From the paragraph right below the one quoted above:
>
> If credential.helper is configured to the empty string, this resets
> the helper list to empty (so you may override a helper set by a
> lower-priority config file by configuring the empty-string helper,
> followed by whatever set of helpers you would like).
>
> > > What's different between what you expected and what actually
> happened?
> >
> > In this example, the "bla" credential helper is called even if the
> > wincred should have been the only one to be called.
> >
> > The result is OK since the "bla" credential returned a non zero return
> > code, then the global credential helper (wincred) was called.
>
> Right, this is the correct and documented behavior. You'd just want to reset
> the list in your local config like:
>
> git config --global credential.helper ""
> git config --global --add credential.helper wincred
>
> -Peff
Ce message et toutes les pièces jointes (ci-après le «message») sont confidentiels et établis à l’intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. Si vous recevez ce message par erreur, merci de le détruire sans en conserver de copie et d’en avertir immédiatement l’expéditeur. Internet ne permettant pas de garantir l’intégrité de ce message, la Caisse des Dépôts et Consignations décline toute responsabilité au titre de ce message s’il a été modifié, altéré, déformé ou falsifié. Par ailleurs et malgré toutes les précautions prises pour éviter la présence de virus dans nos envois, nous vous recommandons de prendre, de votre côté, les mesures permettant d'assurer la non-introduction de virus dans votre système informatique. This email message and any attachments (“the email”) are confidential and intended only for the recipient(s) indicated. If you are not an intended recipient, please be advised that any use, dissemination, forwarding or copying of this email whatsoever is prohibited without prior written consent of Caisse des Depots et Consignations. If you have received this email in error, please delete it without saving a copy and notify the sender immediately. Internet emails are not necessarily secure, and Caisse des Depots et Consignations declines responsibility for any changes that may have been made to this email after it was sent. While we take all reasonable precautions to ensure that viruses are not transmitted via emails, we recommend that you take your own measures to prevent viruses from entering your computer system.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-03-23 10:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-22 16:45 git credential doesn't honor git config precedence rules Coirier, Emmanuel
2023-03-22 17:19 ` Jeff King
2023-03-23 10:34 ` Coirier, Emmanuel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox