On 2024-06-04 at 19:29:28, Aaron Plattner wrote: > When a struct credential expires, credential_fill() clears c->password > so that clients don't try to use it later. However, a struct cred that > uses an alternate authtype won't have a password, but might have a > credential stored in c->credential. > > This is a problem, for example, when an OAuth2 bearer token is used. In > the system I'm using, the OAuth2 configuration generates and caches a > bearer token that is valid for an hour. After the token expires, git > needs to call back into the credential helper to use a stored refresh > token to get a new bearer token. But if c->credential is still non-NULL, > git will instead try to use the expired token and fail with an error: > > fatal: Authentication failed for 'https://<oauth2-enabled-server>/repository' > > And on the server: > > [auth_openidc:error] [client <ip>:34012] oidc_proto_validate_exp: "exp" validation failure (1717522989): JWT expired 224 seconds ago > > Fix this by clearing both c->password and c->credential for an expired > struct credential. While we're at it, use credential_clear_secrets() > wherever both c->password and c->credential are being cleared, and use > the full credential_clear() in credential_reject() after the credential > has been erased from all of the helpers. I think this is fine. I'm assuming that the credential (and other appurtenant information, such as the state[] values) are still passed to the erase call, and if so, I don't see a problem. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
