We fixed a bug in how the IDTOKENS authentication method reads its signing key(s), which are stored in directory =/etc/condor/passwords.d=. If you are not currently using tokens, or you have created these signing key(s) by using the _condor_store_cred_ command-line tool, you should not have any problems and can skip to Step 3. If, however, you created the signing key file(s) in directory =/etc/condor/passwords.d= via some other method (such as a copying from =/dev/random=), there is a possibility that previously issued tokens will no longer authenticate.
-You can use the new =condor_check_password= tool to determine if your signing key(s) were affected by this bug:
+You can use the new =condor_check_password= tool to determine if your signing key(s) were affected by this bug (run as root):
-{code}condor_check_password{endcode}
+ # condor_check_password
-If this tool indicates that your signing keys were truncated, we recommend that you re-issue these tokens to clients via either _condor_token_create_ or _condor_token_fetch_. The `condor_check_password` tool may also be used to truncate the affected key(s) before the first byte causing the problem, which will allow existing tokens to continue to work, but is, perhaps substantially, less cryptographically secure. If you'd like to do so anyway, use the following command:
+If this tool indicates that your signing keys were truncated, we recommend that you re-issue these tokens to clients via either _condor_token_create_ or _condor_token_fetch_. The `condor_check_password` tool may also be used to truncate the affected key(s) before the first byte causing the problem, which will allow existing tokens to continue to work, but is, perhaps substantially, less cryptographically secure. If you'd like to do so anyway, use the following command (run as root):
-{code}condor_check_password --truncate{endcode}
+ # condor_check_password --truncate
{subsection: Step 3: Directory permission changed in /etc/condor/tokens.d}
