Nowadays, when the Credentials Binding Plugin is used on a certificate credential, CertificateMultiBinding calls credentials.getPassword() and credentials.getKeyStore() and saves the KeyStore to a temporary file encrypted with this password. Typically, any private keys within the KeyStore have already been encrypted with the same password; otherwise, the Credentials Plugin would have warned about the unaccessible key when the PKCS#12 file was uploaded to Jenkins.
CertificateMultiBinding could be changed to generate a random password and use that when it passes the credential to the job. This would mean:
- Generate a cryptographically random temporary password.
- Create a temporary KeyStore.
- Enumerate the KeyStore of the credential. Decrypt each key with the password of the credential, encrypt with the temporary password, and add to the temporary KeyStore.
- Save the temporary KeyStore to the temporary file, encrypting it with the temporary password.
- Pass the temporary password to the passwordVariable.
If passwordVariable is empty, i.e. there is no way to pass the generated password to the job, then CertificateMultiBinding should behave the same as now.
The benefit would be that, if the temporary password is revealed via some build log file not written by Jenkins itself (JENKINS-58664), then it would be useless for accessing any persistent KeyStore anywhere, e.g. in the workstation of a developer. The temporary password would only be valid for the temporary KeyStore, which is deleted after the withCredentials step.
This change however has some compatibility risks:
- Jobs might be getting the credential password from the Credentials Binding Plugin and using it on some other keystore file.
- Jobs might run programs that have restrictions on the length or format of the password, and the temporary password might violate those even if the password of the credential does not.
- Some keys in the KeyStore of the credential might be encrypted with a different password not known by Jenkins. I suppose CertificateMultiBinding could catch the exception and copy those unchanged.