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

maven release build exposes users' username and password

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: m2release-plugin
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            domi Dominik Bartholdi added a comment -

            fixed with version 0.9.0

            Show
            domi Dominik Bartholdi added a comment - fixed with version 0.9.0
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            cris Cris added a comment -

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

            Show
            cris Cris added a comment - This is a blocker to us: practically a password exposure vulnerability...
            Hide
            teilo 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.

            Show
            teilo 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.
            Hide
            domi 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".

            Show
            domi 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".
            Hide
            pmdubik 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.

            Show
            pmdubik 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.
            Hide
            whermeling 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.

            Show
            whermeling 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.
            Hide
            teilo 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.

            Show
            teilo 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.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: