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

jobconfighistory-plugin does not track credential.xml changes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins 1.625.3
      jobConfigHistory 2.12
    • Similar Issues:

      Description

      When making change (add/remove/update credentials) on Jenkins Credentials (http://localhost:8080/jenkins/credential-store/domain/_/) page, the System Configuration History (http://localhost:8080/jenkins/jobConfigHistory/?filter=system) page does not show or track the change.

        Attachments

          Activity

          Hide
          jochenafuerbacher Jochen A. Fürbacher added a comment -

          Hi Stephen Connolly,

          is there a possibility that you provide a listener in your credentials plugin? We need a listener to get notified, if there are changes on the credentials page.
          Furthermore we are also not really sure, if this could lead to any security issues.

          Thank you.

          Show
          jochenafuerbacher Jochen A. Fürbacher added a comment - Hi Stephen Connolly , is there a possibility that you provide a listener in your credentials plugin? We need a listener to get notified, if there are changes on the credentials page. Furthermore we are also not really sure, if this could lead to any security issues. Thank you.
          Hide
          stephenconnolly Stephen Connolly added a comment -

          IIUC the credentials files are all Saveable, so should respect the standard SaveableListener. If there are specific ones that you can point me to then we can see about having them notify the SaveableListener appropriately.

          There is obviously an issue in recording the changes of the credentials as if your secret key becomes compromised then the changes will have been captured.

          More generally I am considering adding a second layer of encryption for the credentials.xml file such that it may become binary only or at least the individual credentials would be saved with a random salt added so that the same password would not have the same encrypted form twice (e.g. just like how Maven does encryption of secrets for the settings.xml... it's reversible but the same password will never encrypt to the same form twice) As such any change to one credential would trigger a re-save of the whole file which would then show up as all credentials having been "changed" as the salt will be different for each one.

          I wonder, in that case, if there is much point in the jobconfig plugin trying to track credentials changes

          Show
          stephenconnolly Stephen Connolly added a comment - IIUC the credentials files are all Saveable, so should respect the standard SaveableListener. If there are specific ones that you can point me to then we can see about having them notify the SaveableListener appropriately. There is obviously an issue in recording the changes of the credentials as if your secret key becomes compromised then the changes will have been captured. More generally I am considering adding a second layer of encryption for the credentials.xml file such that it may become binary only or at least the individual credentials would be saved with a random salt added so that the same password would not have the same encrypted form twice (e.g. just like how Maven does encryption of secrets for the settings.xml... it's reversible but the same password will never encrypt to the same form twice) As such any change to one credential would trigger a re-save of the whole file which would then show up as all credentials having been "changed" as the salt will be different for each one. I wonder, in that case, if there is much point in the jobconfig plugin trying to track credentials changes
          Hide
          jochenafuerbacher Jochen A. Fürbacher added a comment -

          Thanks for your answer.

          It seems like SystemCredentialsProvider needs to notify the SaveableListener about changes in the credentials.xml file.
          At the moment JobConfigHistory gets notified by the SaveableListener (see here). I think the changes for JobConfigHistory shouldn't be too big.

          The idea of a second encryption layer is good. We are also having the idea of not saving the old credentials.xml files, but showing the information, that credentials have changed.

          Show
          jochenafuerbacher Jochen A. Fürbacher added a comment - Thanks for your answer. It seems like SystemCredentialsProvider needs to notify the SaveableListener about changes in the credentials.xml file. At the moment JobConfigHistory gets notified by the SaveableListener (see here ). I think the changes for JobConfigHistory shouldn't be too big. The idea of a second encryption layer is good. We are also having the idea of not saving the old credentials.xml files, but showing the information, that credentials have changed.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          src/main/java/com/cloudbees/plugins/credentials/SystemCredentialsProvider.java
          http://jenkins-ci.org/commit/credentials-plugin/18c1627de208adca2f431107aa4b3e7f370568ef
          Log:
          [FIXED JENKINS-33111] Notify SaveableListener when System credentials file is saved

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/com/cloudbees/plugins/credentials/SystemCredentialsProvider.java http://jenkins-ci.org/commit/credentials-plugin/18c1627de208adca2f431107aa4b3e7f370568ef Log: [FIXED JENKINS-33111] Notify SaveableListener when System credentials file is saved
          Hide
          jochenafuerbacher Jochen A. Fürbacher added a comment - - edited

          Thanks, Stephen.

          Reopened: We still need to do some changes on JobConfigHistory.

          EDIT: At the moment JobConfigHistory tracks credentials.xml with the new version of the credentials plugin installed (thanks to Stephen Connolly). No new version of JobConfigHistory required. But we're looking forward to also implement a second encryption layer.

          Show
          jochenafuerbacher Jochen A. Fürbacher added a comment - - edited Thanks, Stephen. Reopened: We still need to do some changes on JobConfigHistory. EDIT: At the moment JobConfigHistory tracks credentials.xml with the new version of the credentials plugin installed (thanks to Stephen Connolly). No new version of JobConfigHistory required. But we're looking forward to also implement a second encryption layer.
          Hide
          jochenafuerbacher Jochen A. Fürbacher added a comment -

          Bing Shiao: As reporter of this issue, what would you prefer?

          • Tracking der whole credentials.xml file with the possibility to restore old files (probably a security issue).
          • Encrypt the content of credentials.xml randomly without the possibility of restoring the files. The user / admin can only see, that the file has changed, but not what exactly has changed.

          Daniel Beck: Do you also agree, that there are some security problems with recording credentials changes?

          Show
          jochenafuerbacher Jochen A. Fürbacher added a comment - Bing Shiao : As reporter of this issue, what would you prefer? Tracking der whole credentials.xml file with the possibility to restore old files (probably a security issue). Encrypt the content of credentials.xml randomly without the possibility of restoring the files. The user / admin can only see, that the file has changed, but not what exactly has changed. Daniel Beck : Do you also agree, that there are some security problems with recording credentials changes?
          Hide
          danielbeck Daniel Beck added a comment -

          Jochen A. Fürbacher Probably less of a security vulnerability (no way to really exploit this AFAICT) but more of a case of needing to be careful how to design this, otherwise confidentiality will be messed up.

          Example: You (perhaps accidentally) add a credential to Jenkins, remove it again. Reasonable assumption is probably that other admins cannot restore it…

          FWIW this has always been a concern with JCH though.

          Show
          danielbeck Daniel Beck added a comment - Jochen A. Fürbacher Probably less of a security vulnerability (no way to really exploit this AFAICT) but more of a case of needing to be careful how to design this, otherwise confidentiality will be messed up. Example: You (perhaps accidentally) add a credential to Jenkins, remove it again. Reasonable assumption is probably that other admins cannot restore it… FWIW this has always been a concern with JCH though.
          Hide
          bingshiao Bing Shiao added a comment -

          Jochen A. Fürbacher, the content of credentials.xml is cryptic to some extend; being able to see which credential item was changed (add/delete/update) in the JobConfigHistory page is good enough for me. Thanks a lot.

          Show
          bingshiao Bing Shiao added a comment - Jochen A. Fürbacher , the content of credentials.xml is cryptic to some extend; being able to see which credential item was changed (add/delete/update) in the JobConfigHistory page is good enough for me. Thanks a lot.

            People

            Assignee:
            jochenafuerbacher Jochen A. Fürbacher
            Reporter:
            bingshiao Bing Shiao
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated: