git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git credential-cache manager is not treating `path=` correctly

From
Ganriel Nützi <gnuetzi@gmail.com>
Date
Aug 23, 2023, 21:02 UTC
Message-ID
<14F3D856-6A3B-45F8-B5FD-9CD5D0CB7C47@gmail.com>
In-Reply-To
<20230823192207.GC2355007@coredump.intra.peff.net>
Thanks a lot for this informations.

What I did not get from the documentation ist that a “store” of a generic (without path) credential , e.g https://www.server.com will just overwrite the more specific ones already in there. (So that is the case in my test, right? And the prompt happens in the first fill because useHttpPath=true but there is nomore any credential entry in the cache which would match (only the generic but that does not match), right?)

I selectively applied useHttpPath for certain urls such that any other url not using httpPath matches the generic one (urls for submodules which I dont want to add credentials). So I just have to make sure the generic ones are added first and then the more specific ones (with path)

I am not sure but I thought that using cache is safer than store because i generally dont want to have credentials on a disk.
- Gabriel
Von meinem iPhone gesendet
Show 65 quoted lines
> Am 23.08.2023 um 21:22 schrieb Jeff King <peff@peff.net>:
> 
> 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
Previous: Jeff KingNext: Jeff King
Message 3 of 4 in “Git credential-cache manager is not treating `path=` correctly”
  1. Gabriel NütziAug 23, 2023
  2. Jeff KingAug 23, 2023
  3. Ganriel NütziAug 23, 2023
  4. Jeff KingAug 24, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.