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

Conjur Secrets Plugin causes "Save" button on System Configuration to be grayed out

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • Jenkins 2.452.4, 2.462.3, and 2.479.3
      Conjur Secrets Plugin Version2.2.3

      When plugin is installed, whenever a field in "System Configuration" is changed, the "SAVE" button and "APPLY" button become grayed out and never become active any more, even if the change was un-done.

      Need to either reload the page and ignore changes or go back in the browser.

          [JENKINS-75258] Conjur Secrets Plugin causes "Save" button on System Configuration to be grayed out

          Mark Waite added a comment - - edited

          Thanks for reporting the issue. I can duplicate the issue. The JavaScript debugging tools report an exception attempting to assign the value true to a field that is part of a null object applyBtn. That is line 192 of the file src/main/resources/org/conjur/jenkins/configuration/GlobalConjurConfiguration/config.jelly in the Conjur credentials plugin source code.

          Steps that I used to duplicate the bug:

          1. Create a plugins.txt file with the list of plugins and their versions
          2. Create a run-jenkins.sh shell script that downloads Jenkins 2.479.3 and the plugins from plugins.txt
          3. Run the run-jenkins.sh script and complete the setup wizard by creating a user and installing no additional plugins
          4. Open the "Manage Jenkins" -> "System" page and change any field (I changed number of executors from 2 to 3)
          5. Confirm that the "Save" and "Apply" buttons are now disabled (bug confirmed)
          6. Disable the Conjur Credentials plugin from the plugin manager and restart Jenkins
          7. Open the "Manage Jenkins" -> "System" page and change any field (I changed number of executors from 2 to 3)
          8. Confirm that the "Save" and "Apply" buttons are active (bug only visible when Conjur credentials plugin is active)

          Mark Waite added a comment - - edited Thanks for reporting the issue. I can duplicate the issue. The JavaScript debugging tools report an exception attempting to assign the value true to a field that is part of a null object applyBtn . That is line 192 of the file src/main/resources/org/conjur/jenkins/configuration/GlobalConjurConfiguration/config.jelly in the Conjur credentials plugin source code. Steps that I used to duplicate the bug: Create a plugins.txt file with the list of plugins and their versions Create a run-jenkins.sh shell script that downloads Jenkins 2.479.3 and the plugins from plugins.txt Run the run-jenkins.sh script and complete the setup wizard by creating a user and installing no additional plugins Open the "Manage Jenkins" -> "System" page and change any field (I changed number of executors from 2 to 3) Confirm that the "Save" and "Apply" buttons are now disabled (bug confirmed) Disable the Conjur Credentials plugin from the plugin manager and restart Jenkins Open the "Manage Jenkins" -> "System" page and change any field (I changed number of executors from 2 to 3) Confirm that the "Save" and "Apply" buttons are active (bug only visible when Conjur credentials plugin is active)

          Mark Waite added a comment - - edited

          Same problem happens with Jenkins 2.462.3 and 2.452.4

          Mark Waite added a comment - - edited Same problem happens with Jenkins 2.462.3 and 2.452.4

          Mark Waite added a comment -

          I've uploaded a build of the plugin from my pull request as conjur-credentials.zip . If you're willing to try it in a non-production environment, that might be more likely to persuade the plugin maintainers that they should accept the pull request and deliver a new release.

          Mark Waite added a comment - I've uploaded a build of the plugin from my pull request as conjur-credentials.zip . If you're willing to try it in a non-production environment, that might be more likely to persuade the plugin maintainers that they should accept the pull request and deliver a new release.

          Yuval Yosha added a comment - - edited

          Hi Mark,
           
          I installed the new plugin on my test env (Jenkins 2.479.3).
          Sorry, but no-joy.
           
          Also, in systemctl status Jenkins, I get this right after I install the plugin:
          WARNING o.k.s.BytecodeReadingParanamer#lookupParameterNames: Looking up parameter names for public hudson.util.FormValidation org.jenkinsci.plugins.pipelineConfigHistory.model.PipelineConfigHistoryGlobalConfiguration.doCheckMaxHistoryEntries(java.lang.String); update plugin to a version created with a newer harnessWARNING o.k.s.BytecodeReadingParanamer#lookupParameterNames: Looking up parameter names for public hudson.util.FormValidation org.jenkinsci.plugins.pipelineConfigHistory.model.PipelineConfigHistoryGlobalConfiguration.doCheckMaxDaysToKeepEntries(java.lang.String); update plugin to a version created with a newer harness

           

          I also noticed that when the plugin is installed, it has many complaints in "System Configuration' about JWT fields, even when JWT is not enabled.

           

          Thanks,
           
          Yuval

          Yuval Yosha added a comment - - edited Hi Mark,   I installed the new plugin on my test env (Jenkins 2.479.3). Sorry, but no-joy.   Also, in systemctl status Jenkins, I get this right after I install the plugin: WARNING o.k.s.BytecodeReadingParanamer#lookupParameterNames: Looking up parameter names for public hudson.util.FormValidation org.jenkinsci.plugins.pipelineConfigHistory.model.PipelineConfigHistoryGlobalConfiguration.doCheckMaxHistoryEntries(java.lang.String); update plugin to a version created with a newer harness WARNING o.k.s.BytecodeReadingParanamer#lookupParameterNames: Looking up parameter names for public hudson.util.FormValidation org.jenkinsci.plugins.pipelineConfigHistory.model.PipelineConfigHistoryGlobalConfiguration.doCheckMaxDaysToKeepEntries(java.lang.String); update plugin to a version created with a newer harness   I also noticed that when the plugin is installed, it has many complaints in "System Configuration' about JWT fields, even when JWT is not enabled.   Thanks,   Yuval

          Mark Waite added a comment -

          yyosha I need more details to understand what you mean when you say

          no-joy

          Are you saying that you installed the test build of the plugin, restarted Jenkins, and the "Manage Jenkins" -> "System" page was still disabled? If so, then I suspect that you may not be actually running the test build of the plugin. The zip file includes a ".hpi" file. If there is a ".jpi" file of the plugin already in the plugins directory, then that "jpi" file needs to be removed. Jenkins might be loading the released "jpi" file instead of the test build that is in the zip file as an "hpi" file.

          Also, in systemctl status Jenkins, I get this right after I install the plugin:
          WARNING o.k.s.BytecodeReadingParanamer#lookupParameterNames: Looking up parameter names for public hudson.util.FormValidation org.jenkinsci.plugins.pipelineConfigHistory.model.PipelineConfigHistoryGlobalConfiguration.doCheckMaxHistoryEntries(java.lang.String); update plugin to a version created with a newer harness

          That is an expected warning and should be harmless. It should also appear with the current release of the plugin.

          The plugin is built with older versions of the Jenkins build tools and allows itself to be run on Jenkins versions as old as 2.346.3. That warning says that the plugin needs to be updated to require a much newer minimum Jenkins version.

          I've submitted a pull request to update to a much newer minimum Jenkins version as recommended by "Choosing a Jenkins version to build against". However, I'm not a Cyberark user, so I've not tested either of those pre-release builds with an actual Cyberark instance. I'd love to have you test both of them. If it helps you, I can even combine the two pull requests into a single build so that you can test them together.

          Mark Waite added a comment - yyosha I need more details to understand what you mean when you say no-joy Are you saying that you installed the test build of the plugin, restarted Jenkins, and the "Manage Jenkins" -> "System" page was still disabled? If so, then I suspect that you may not be actually running the test build of the plugin. The zip file includes a ".hpi" file. If there is a ".jpi" file of the plugin already in the plugins directory, then that "jpi" file needs to be removed. Jenkins might be loading the released "jpi" file instead of the test build that is in the zip file as an "hpi" file. Also, in systemctl status Jenkins, I get this right after I install the plugin: WARNING o.k.s.BytecodeReadingParanamer#lookupParameterNames: Looking up parameter names for public hudson.util.FormValidation org.jenkinsci.plugins.pipelineConfigHistory.model.PipelineConfigHistoryGlobalConfiguration.doCheckMaxHistoryEntries(java.lang.String); update plugin to a version created with a newer harness That is an expected warning and should be harmless. It should also appear with the current release of the plugin. The plugin is built with older versions of the Jenkins build tools and allows itself to be run on Jenkins versions as old as 2.346.3. That warning says that the plugin needs to be updated to require a much newer minimum Jenkins version. I've submitted a pull request to update to a much newer minimum Jenkins version as recommended by "Choosing a Jenkins version to build against" . However, I'm not a Cyberark user, so I've not tested either of those pre-release builds with an actual Cyberark instance. I'd love to have you test both of them. If it helps you, I can even combine the two pull requests into a single build so that you can test them together.

          Yuval Yosha added a comment - - edited

          I actually did that:

          1. Went to "Installed Plugins" page and removed the "Conjur Secrets Plugin"
          2. Logged in to Jenkins server and stopped Jenkins service (sudo systemctl stop jenkins)
          3. Changed to /var/lib/jenkins/plugins and removed conjur-credentials.bak and conjur-credentials directory
          4. Started Jenkins service
          5. Installed the new plugin .hpi from my PC using the "Advanced Settings" under "Plugin" page
          6. Verified that the plugin was installed
          7. Went to ""Manage Jenkins" -> "System" and type one space in the "System Message"
          8. Verified that "Save" & "Apply" buttons are disabled

          I hope this clarify my no-joy

          Yuval Yosha added a comment - - edited I actually did that: Went to "Installed Plugins" page and removed the "Conjur Secrets Plugin" Logged in to Jenkins server and stopped Jenkins service (sudo systemctl stop jenkins) Changed to /var/lib/jenkins/plugins and removed conjur-credentials.bak and conjur-credentials directory Started Jenkins service Installed the new plugin .hpi from my PC using the "Advanced Settings" under "Plugin" page Verified that the plugin was installed Went to ""Manage Jenkins" -> "System" and type one space in the "System Message" Verified that "Save" & "Apply" buttons are disabled I hope this clarify my no-joy

          Yuval Yosha added a comment - - edited

          markewaite,

          I took a peek in src/main/resources/org/conjur/jenkins/configuration/GlobalConjurConfiguration/config.jelly.

          It looks to me like line 160 ( document.addEventListener("input", disableSubmitButton); ) is still invoking disableSubmitButton() upon input to the document.

          This is exactly what I experience.

           

          Any way, AFAIU, disableSubmitButton() disables the buttons only if the JWT is not configured (fields are empty). This means that I MUST configure JWT even if I don't use it (If I use only tenant user credentials).

          So I managed to overcome this behavior by entering garbage data in JWT configuration.

           

          Yuval Yosha added a comment - - edited markewaite , I took a peek in src/main/resources/org/conjur/jenkins/configuration/GlobalConjurConfiguration/config.jelly. It looks to me like line 160 ( document.addEventListener("input", disableSubmitButton); ) is still invoking disableSubmitButton() upon input to the document. This is exactly what I experience.   Any way, AFAIU, disableSubmitButton() disables the buttons only if the JWT is not configured (fields are empty). This means that I MUST configure JWT even if I don't use it (If I use only tenant user credentials). So I managed to overcome this behavior by entering garbage data in JWT configuration.  

          Mark Waite added a comment -

          Thanks for catching the mistake in my pull request!  I've updated the pull request with the additional change and have included the change in my second pull request to modernize the plugin. I've uploaded builds of those changes as:

          I'd love to have you test the "modernize" version and confirm that the "Manage Jenkins" page submits as expected and that the warning about outdated Jenkins version is no longer visible. If those tests pass, please leave a comment on the pull requests so that the maintainers know that the plugin has been tested interactively.

          Mark Waite added a comment - Thanks for catching the mistake in my pull request!  I've updated the pull request with the additional change and have included the change in my second pull request to modernize the plugin. I've uploaded builds of those changes as: conjur-credentials-modernized-plugin-with-no-disableSubmit.zip - modernized plugin with disableSubmit removed conjur-credentials-with-no-disableSubmit.zip - disableSubmit removed I'd love to have you test the "modernize" version and confirm that the "Manage Jenkins" page submits as expected and that the warning about outdated Jenkins version is no longer visible. If those tests pass, please leave a comment on the pull requests so that the maintainers know that the plugin has been tested interactively.

          Yuval Yosha added a comment -

          markewaite,

          I installed the modernized plugin and the buttons are not being disabled any more, even with empty fields for JWT. So your fix is working!

          I wonder if it is possible to add a toggle that enable/disable JWT all together and then add a condition to the disableSubmitButton() function to test on that toggle.

          Yuval Yosha added a comment - markewaite , I installed the modernized plugin and the buttons are not being disabled any more, even with empty fields for JWT. So your fix is working! I wonder if it is possible to add a toggle that enable/disable JWT all together and then add a condition to the disableSubmitButton() function to test on that toggle.

          Mark Waite added a comment - - edited

          Thanks very much for testing the change and confirming that it is working as expected. That is a great result. Could you share that result as a comment in the bug fix pull request and in the modernization pull request?

          I wonder if it is possible to add a toggle that enable/disable JWT all together and then add a condition to the disableSubmitButton() function to test on that toggle.

          That might be possible, but I'm not willing to spend more effort on the plugin until the plugin maintainers merge and release the current fixes. I'm not a user of the plugin, I think that it is a serious bug to block saving the Jenkins system configuration. If that bug were on a system that I used, I would immediately remove the plugin. I think that should prompt the maintainers to review, merge, and release the fix.

          Maintainers of the plugin include:

          Could you work with those individuals to have them review, merge, and release the pull requests?

          The plugin has additional issues that need to be addressed, but addressing those issues needs a plugin maintainer.

          The plugin uses the Acegi security API's in Jenkins. Those API's were deprecated in November 2020. The plugin should use the Spring Security API instead of Acegi. A blog post describes more details of that transition.

          The plugin uses Java EE 8 API's. Those API's were deprecated in October 2024 as part of Jenkins 2.479.1. The plugin should be updated to require Jenkins 2.479.1 or newer, Spring Security 6, and Jakarta EE 9. Examples of that transition are available in:

          Mark Waite added a comment - - edited Thanks very much for testing the change and confirming that it is working as expected. That is a great result. Could you share that result as a comment in the bug fix pull request and in the modernization pull request ? I wonder if it is possible to add a toggle that enable/disable JWT all together and then add a condition to the disableSubmitButton() function to test on that toggle. That might be possible, but I'm not willing to spend more effort on the plugin until the plugin maintainers merge and release the current fixes. I'm not a user of the plugin, I think that it is a serious bug to block saving the Jenkins system configuration. If that bug were on a system that I used, I would immediately remove the plugin. I think that should prompt the maintainers to review, merge, and release the fix. Maintainers of the plugin include: andytinkham itsbrugu jaleelaf nitincyberark hughsaunders conjur_jenkins Could you work with those individuals to have them review, merge, and release the pull requests? The plugin has additional issues that need to be addressed, but addressing those issues needs a plugin maintainer. The plugin uses the Acegi security API's in Jenkins. Those API's were deprecated in November 2020 . The plugin should use the Spring Security API instead of Acegi. A blog post describes more details of that transition. The plugin uses Java EE 8 API's. Those API's were deprecated in October 2024 as part of Jenkins 2.479.1 . The plugin should be updated to require Jenkins 2.479.1 or newer, Spring Security 6, and Jakarta EE 9. Examples of that transition are available in: GitLab OAuth plugin PR 169 Authorize Project plugin PR 290 GitHub OAuth plugin PR 285

            markewaite Mark Waite
            yyosha Yuval Yosha
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: