From: Jeff King <peff@peff.net>
To: "Gabriel Nützi" <gnuetzi@gmail.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Git credential-cache manager is not treating `path=` correctly
Date: Wed, 23 Aug 2023 15:22:07 -0400 [thread overview]
Message-ID: <20230823192207.GC2355007@coredump.intra.peff.net> (raw)
In-Reply-To: <CAA9rTuccfyXO66YApDfss6JM9+JuUzZxDiYyfG_qShfehyAEsQ@mail.gmail.com>
On Wed, Aug 23, 2023 at 06:23:36PM +0200, Gabriel Nützi wrote:
> # Add 3 credentials, 2 specifics with `path=`
> # 1 with general host.
> {
> echo "protocol=https"
> echo "host=www.server.com"
> echo "path=repos/1.git"
> echo "username=banana"
> echo "password=banana1"
> } | git credential approve
>
> {
> echo "protocol=https"
> echo "host=www.server.com"
> echo "path=repos/2.git"
> echo "username=banana"
> echo "password=banana2"
> } | git credential approve
>
> {
> echo "protocol=https"
> echo "host=www.server.com"
> echo "username=banana"
> echo "password=general"
> } | git credential approve
I don't think we ever planned around this kind of "sometimes paths are
important, and sometimes not", and I'm not surprised it doesn't work.
The "useHTTPPath" flag is only read by the by the main Git side, and
just tells it whether to pass a "path" entry. On the helper side, any
omitted entry ("path" in the final case) means "match anything".
So that final command translates (from the helper's view) to "store
this, and delete any other credentials we have stored for
https://banana@www.server.com".
It might be possible to change the handling on the helper side to
distinguish between entries with no path and entries with a path, and
consider them separately. I don't know what gotchas we might see in that
case, though. I suspect at least in credential-store's on-disk format,
there is not really room to distinguish the empty-string path from "no
path given".
If you set credential.useHTTPPaths (so that it is applied consistently),
I think path-matching should work. But then you'd have to independently
store credentials for each path that could match the "generic" case.
As a workaround, you could use two different stores/caches. Something
like:
[credential]
# store most stuff here
helper = store
[credential "https://www.server.com/repos/1.git"]
# turn off the main helper, and use a path-specific file instead
helper =
helper = store --file=$HOME/.git-credentials-path
useHttpPath = true
-Peff
next prev parent reply other threads:[~2023-08-23 19:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-23 16:23 Git credential-cache manager is not treating `path=` correctly Gabriel Nützi
2023-08-23 19:22 ` Jeff King [this message]
2023-08-23 21:02 ` Ganriel Nützi
2023-08-24 14:44 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230823192207.GC2355007@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gnuetzi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).