Fix IDTOKENS backwards-incompatibilities
Description
Depending on the results of BrianB’s testing, “double” either the pool password when used as an IDTOKENS signing key, or all signing keys.
Fix bug in “doubling” code where the returned length is incorrect / not enough bytes are returned.
Undo the change which introduced an “early out” in the pruning code (to allow nonroot clients to use tokens again).
Activity
Code Review
[Second review requested by ToddT because we’re releasing 8.9.12 with basically no burn-in period.]
The patch looks more complicated than it really is because it (also) renames some parameters, but it’s actually pretty simple. Looks good to me.
Code review comments addressed. No need for documentation as this ticket fixes bugs in unreleased (or pulled, sigh) versions.
CODE REVEW
Tested non-root client using a token to authenticate: It now no longer strips IDTOKENS out of the client list if /etc/condor/passwords.d is not world-readable. Woot! The patch is sufficient until is resolved.
Tested using using signing keys with and without NULLs…. signing keys without NULLs now work across versions as expected (meaning “doubling” code fixed properly).
SEC_TOKEN_POOL_SIGNING_KEY_IS_PASSWORD: Decision is give up on this knob, leave it undocumented until removed from the code, and instead go with the tool introduced in HTCONDOR-369. Given this, there is no need to merge the Pull Request #163 attached to this ticket.
Change default for SEC_TOKEN_POOL_SIGNING_KEY_FILE to equal $(SEC_PASSWORD_FILE)
ToddT will either do the second code review or ensure that BrianB does.
I think if we want to do a backward compatibility break with no apparent benefit to sites other than “cleaning up the defaults”, then we need to do a bit more planning here. I don’t want to make breaks in a pinch.
This change didn’t make it into the release notes for 8.9.12.
