Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-60317

Encrypt the temporary keystore and keys with a random password in certificate binding

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins 2.190.3
      Credentials Binding Plugin 1.20
      Credentials Plugin 2.3.0
    • Similar Issues:

      Description

      Current behaviour

      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.

      Desired change

      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.

      Benefits

      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.

      Risks

      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.

        Attachments

          Issue Links

            Activity

            There are no comments yet on this issue.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              kon Kalle Niemitalo
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated: