On 2024-12-18 at 20:42:31, M Hickford wrote: > Hi. Is this a bug in git version 2.47.1? Or am I using it incorrectly? > > # erase existing example.com credentials > printf "host=example.com\nprotocol=https\n" | git -c credential.helper= -c credential.helper=cache credential reject > # store bearer token with expiry in far future in credential-cache > printf "host=example.com\nprotocol=https\nauthtype=bearer\ncredential=letmein\npassword_expiry_utc=2147483640\n" > | git credential-cache store > # try to retrieve credential > printf "host=example.com\nprotocol=https\n" | git -c credential.helper= -c credential.helper=cache credential fill > > Expected output (complete credential): > > protocol=https > host=example.com > authtype=bearer > credential=letmein > password_expiry_utc=2147483640 > > Actual output (incomplete credential, no prompt for username or password): > > protocol=https > host=example.com > password_expiry_utc=2147483640 This is expected. Every request to a credential helper should include all of the capabilities that the caller supports on input, and the credential helper will always emit those on output. `git credential`, however, will only emit the capabilities that were actually supported, so that general callers (including Git LFS) can determine the actual set of supported capabilities. In this case, you asked the cache helper for a credential, but didn't tell it that you supported `authtype` and `credential`. Therefore, the only safe thing it can assume is that you are incapable of parsing and understanding those fields, so it doesn't emit them. This is a benefit for security, because some tooling logs all fields but the `password` field, and we don't want to include new secret fields that the caller is going to shovel into a file or syslog. In addition, the helper could actually store two different sets of credentials, one which is a username and password, and one which is an authtype and credential. If you provided the capability, the latter would be omitted, but otherwise the former would. That can be helpful if you have a stronger credential type but might occasionally need to use older software (say, older versions of Git or Git LFS). However, if you provide the proper capability, this works as you expect: ---- % printf "host=example.com\nprotocol=https\n" | git -c credential.helper= -c credential.helper=cache credential reject % printf "capability[]=authtype\nhost=example.com\nprotocol=https\nauthtype=bearer\ncredential=letmein\npassword_expiry_utc=2147483640\n" | git credential-cache store % printf "capability[]=authtype\nhost=example.com\nprotocol=https\n" | git -c credential.helper= -c credential.helper=cache credential fill capability[]=authtype authtype=bearer credential=letmein protocol=https host=example.com password_expiry_utc=2147483640 ---- Note that `capability[]` directives should always start the request to allow one-pass parsing. Hopefully this is helpful. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
