Re: [PATCH v2] credential: clear expired c->credential, unify secret clearing
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Jun 4, 2024, 21:21 UTC
- Message-ID
- <Zl-FQ3SwNKM_4x6Q@tapette.crustytoothpaste.net>
- In-Reply-To
- <20240604192929.3252626-1-aplattner@nvidia.com>
On 2024-06-04 at 19:29:28, Aaron Plattner wrote:
Show 23 quoted lines
> 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