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

maven release build exposes users' username and password

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • m2release-plugin
    • None

      When you specify a custom username and password to be used in a maven release build (using the option 'Specify SCM login/password'), the filled in username and password can be read by anyone who can Configure the build. If you run a release build and then, while it is still runnning, you configure the build plan, the see that the 'Goals and options' have changed to the one which are currently used for the release build.

      So in my case this then shows: -Dpassword=*** -Dusername=*** -Dproject.rel.<groupId>:<artifactId>=<release-version> -Dproject.dev.<groupId>:<artifactId>=<development-version> -Dresume=false release:prepare release:perform

      It seems the m2 release plugin is using the 'Goals and options' field to manage the parameters the release build.

      A workaround could be to mask these credentials in the 'Goals and options' fields.

          [JENKINS-8524] maven release build exposes users' username and password

          James Nord added a comment -

          regardless of how this is done, if you can configure the job and perform releases you can get this information.

          Just change the release goals to run a mojo that dumps the system variables - such as help:system and then perform a release.

          If this is important to you I would suggest you have a different job that only performs release builds and normal users have no access to it.

          James Nord added a comment - regardless of how this is done, if you can configure the job and perform releases you can get this information. Just change the release goals to run a mojo that dumps the system variables - such as help:system and then perform a release. If this is important to you I would suggest you have a different job that only performs release builds and normal users have no access to it.

          whermeling added a comment -

          I disagree. If i perform a release using the m2 release plugin and fill in a username and password (and the UI masks the password as it should), then i do not expect to have the password show up (and certainly not in plain text) when somebody looks at the job configuration by coïncident.

          Creating a different job is a bad solution because:
          A) this would require an additional job for every build plan in our Hudson instance and
          B) everybody is able to perform release in our organization, but they should do so by supplying their own username and password (which in our case are single sign credentials for a lot of systems).

          The fact the somebody could get this information via different ways is a bad argument IMO. We run release jobs without help:system and people running the job can check which goals are executed in advance (they are all able to view the job configuration).

          PS: It would be a nice addition if the configured release goals would be displayed in the screen where you can perform the maven release.

          whermeling added a comment - I disagree. If i perform a release using the m2 release plugin and fill in a username and password (and the UI masks the password as it should), then i do not expect to have the password show up (and certainly not in plain text) when somebody looks at the job configuration by coïncident. Creating a different job is a bad solution because: A) this would require an additional job for every build plan in our Hudson instance and B) everybody is able to perform release in our organization, but they should do so by supplying their own username and password (which in our case are single sign credentials for a lot of systems). The fact the somebody could get this information via different ways is a bad argument IMO. We run release jobs without help:system and people running the job can check which goals are executed in advance (they are all able to view the job configuration). PS: It would be a nice addition if the configured release goals would be displayed in the screen where you can perform the maven release.

          pmdubik added a comment -

          I agree with teilo, the password appears with ****** when you input it in the release Task then it is in clear in the build > Goals and options.
          So unless you configure Rights on specific builds anyone can use your SVN /CVS account.

          pmdubik added a comment - I agree with teilo, the password appears with ****** when you input it in the release Task then it is in clear in the build > Goals and options. So unless you configure Rights on specific builds anyone can use your SVN /CVS account.

          Dominik Bartholdi added a comment -

          does this arguementation mean this will not be fixed?
          IMO this makes the plugin absolutly unusable in a larger organisation where multiple people have to be able run the same release job. Just becase there was a failing job, does not mean tha showing the credentials is an acceptable behavior. e.g. if I triggered the release build and it fails, I don't want my colleagues to see my global SCM password- even if they are nice guys

          so I think this should be mnarked as a "Blocker" issue and not just a "Major".

          Dominik Bartholdi added a comment - does this arguementation mean this will not be fixed? IMO this makes the plugin absolutly unusable in a larger organisation where multiple people have to be able run the same release job. Just becase there was a failing job, does not mean tha showing the credentials is an acceptable behavior. e.g. if I triggered the release build and it fails, I don't want my colleagues to see my global SCM password- even if they are nice guys so I think this should be mnarked as a "Blocker" issue and not just a "Major".

          James Nord added a comment -

          The argument doesn't say it won't get fixed but thst it is not my to purport.

          it's also not a blocker for the plugin as you can use the plugin without this option with two major scm systems (svn + git).

          The fact that the goals are not rest i5 the build fails is a different issue that will be addressed first.

          James Nord added a comment - The argument doesn't say it won't get fixed but thst it is not my to purport. it's also not a blocker for the plugin as you can use the plugin without this option with two major scm systems (svn + git). The fact that the goals are not rest i5 the build fails is a different issue that will be addressed first.

          Cris added a comment -

          This is a blocker to us: practically a password exposure vulnerability...

          Cris added a comment - This is a blocker to us: practically a password exposure vulnerability...

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: imod
          Path:
          src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseArgumentInterceptorAction.java
          src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java
          http://jenkins-ci.org/commit/m2release-plugin/944906c5de59683d903d7de28a93b2182be21e8b
          Log:
          fix JENKINS-8524 - expose username and password

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: imod Path: src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseArgumentInterceptorAction.java src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java http://jenkins-ci.org/commit/m2release-plugin/944906c5de59683d903d7de28a93b2182be21e8b Log: fix JENKINS-8524 - expose username and password

          Dominik Bartholdi added a comment -

          fixed with version 0.9.0

          Dominik Bartholdi added a comment - fixed with version 0.9.0

            domi Dominik Bartholdi
            whermeling whermeling
            Votes:
            4 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: