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

Security leak - passwords are visible in workspace (git / http)

    Details

    • Similar Issues:

      Description

      Maven-Jobs with git-SCMs using http-URLs: The credentials are automatically attached to the URL for the remote repository. Thus the password is visible for all users reading the workspace-directory (see attachments).

      I know that the password >has< to be set somewhere. I suggest to force the usage of ~/.netrc. This file is visible for the build admin only!

      Note: This is not identical with JENKINS-4428!

        Attachments

          Activity

          Hide
          ndeloof Nicolas De Loof added a comment -

          git-plugin 2.0 is a significant progress in this direction as it relies on credentials plugin.
          I'm not sure how to avoid a remote to be set. Maybe switch from "git clone" to "git init" + "git fetch URL"

          Show
          ndeloof Nicolas De Loof added a comment - git-plugin 2.0 is a significant progress in this direction as it relies on credentials plugin. I'm not sure how to avoid a remote to be set. Maybe switch from "git clone" to "git init" + "git fetch URL"
          Hide
          ndeloof Nicolas De Loof added a comment -

          lowering to "Major" as this only applies to http repository. Using ssh is a simple workaround

          Show
          ndeloof Nicolas De Loof added a comment - lowering to "Major" as this only applies to http repository. Using ssh is a simple workaround
          Hide
          chrisabit chrisabit added a comment - - edited

          I do understand your point. But make passwords visible to virtually anybody cannot be a proper solution. Please reflect upon this. Furthermore ssh is not always a workaround. We're using a Git repo manager without ssh support. Therefore Critical is the right value (maybe even Blocker since we're in a productive enterprise context and Password visibility is an absolute no go). By the way: your implementation doesn't work for maven releases (maven-release-plugin perform phase - the scm checkout to target/checkout fails). Ok. Now to the solutions: one way could be to write the password into standard in of the the native git process. That's what you do when calling Git on the commandline. Another (much better) way could be to enforce a .netrc file with credentials. Those are visible for root / build admin only. And (much better!): this works also for the maven-release-plugin! Alternatively you could implement an 'use .netrc' option. If set you don't make the password part of the remote repos URL.

          Show
          chrisabit chrisabit added a comment - - edited I do understand your point. But make passwords visible to virtually anybody cannot be a proper solution. Please reflect upon this. Furthermore ssh is not always a workaround. We're using a Git repo manager without ssh support. Therefore Critical is the right value (maybe even Blocker since we're in a productive enterprise context and Password visibility is an absolute no go). By the way: your implementation doesn't work for maven releases (maven-release-plugin perform phase - the scm checkout to target/checkout fails). Ok. Now to the solutions: one way could be to write the password into standard in of the the native git process. That's what you do when calling Git on the commandline. Another (much better) way could be to enforce a .netrc file with credentials. Those are visible for root / build admin only. And (much better!): this works also for the maven-release-plugin! Alternatively you could implement an 'use .netrc' option. If set you don't make the password part of the remote repos URL.
          Hide
          chrisabit chrisabit added a comment -

          You may consider to implement an additional option "Password management by ~/.netrc file" in the optional "Advanced clone behaviours" block.

          Show
          chrisabit chrisabit added a comment - You may consider to implement an additional option "Password management by ~/.netrc file" in the optional "Advanced clone behaviours" block.
          Hide
          ndeloof Nicolas De Loof added a comment -

          git don't provide any way to pass credentials, that's a pity.

          maven release is another topic. maven to use local environment for credentials vs settings <server> is just a nonsense.

          About solutions, .netrc don't support concurrent builds on same slave, so that can't be an option. I'd prefer to setup a git-credentials store as a buidlwrapper. Need to investigate.

          About criticity and security, in enterprise context a job will be restricted to development team, so I don't think this is such an issue.

          Show
          ndeloof Nicolas De Loof added a comment - git don't provide any way to pass credentials, that's a pity. maven release is another topic. maven to use local environment for credentials vs settings <server> is just a nonsense. About solutions, .netrc don't support concurrent builds on same slave, so that can't be an option. I'd prefer to setup a git-credentials store as a buidlwrapper. Need to investigate. About criticity and security, in enterprise context a job will be restricted to development team, so I don't think this is such an issue.
          Hide
          ndeloof Nicolas De Loof added a comment -

          note for implementation :

          run git with --file to set config file path
          generate (temporary) config file to include credential.helper store --store=/tmpfile
          generate /tmpfile to include https://user:pass@repoURL

          Show
          ndeloof Nicolas De Loof added a comment - note for implementation : run git with --file to set config file path generate (temporary) config file to include credential.helper store --store=/tmpfile generate /tmpfile to include https://user:pass@repoURL
          Hide
          ndeloof Nicolas De Loof added a comment -

          draft implementation on https://github.com/jenkinsci/git-client-plugin/tree/gitcredentials
          Doesn't work. Not sure the git command gets the generated config.

          I expected to use GIT_CONFIG env variable, but it's considered 'detrimental'

          commit dc87183189b54441e315d35d48983d80ab085299
          Author: Daniel Barkalow <[hidden email]>
          Date: Mon Jun 30 03:37:47 2008 -0400

          Only use GIT_CONFIG in "git config", not other programs

          For everything other than using "git config" to read or write a
          git-style config file that isn't the current repo's config file,
          GIT_CONFIG was actively detrimental. Rather than argue over which
          programs are important enough to have work anyway, just fix all of
          them at the root.

          Show
          ndeloof Nicolas De Loof added a comment - draft implementation on https://github.com/jenkinsci/git-client-plugin/tree/gitcredentials Doesn't work. Not sure the git command gets the generated config. I expected to use GIT_CONFIG env variable, but it's considered 'detrimental' commit dc87183189b54441e315d35d48983d80ab085299 Author: Daniel Barkalow < [hidden email] > Date: Mon Jun 30 03:37:47 2008 -0400 Only use GIT_CONFIG in "git config", not other programs For everything other than using "git config" to read or write a git-style config file that isn't the current repo's config file, GIT_CONFIG was actively detrimental. Rather than argue over which programs are important enough to have work anyway, just fix all of them at the root.
          Hide
          chrisabit chrisabit added a comment -

          "About criticity and security, in enterprise context a job will be restricted to development team, so I don't think this is such an issue."
          I fear that's not always the truth. In our enterprise context for instance we have ~200 developers organised in various development teams. Using their individual (LDAP) password for builds isn't an option (for obvious reasons). Therefore we're using an technical user which MUST only be visible to the buildserver administrator. Unfortunately your implementation make it visible to every developer. That's a HUGE issue regarding criticity and security. Please don't underestimate that.

          Show
          chrisabit chrisabit added a comment - "About criticity and security, in enterprise context a job will be restricted to development team, so I don't think this is such an issue." I fear that's not always the truth. In our enterprise context for instance we have ~200 developers organised in various development teams. Using their individual (LDAP) password for builds isn't an option (for obvious reasons). Therefore we're using an technical user which MUST only be visible to the buildserver administrator. Unfortunately your implementation make it visible to every developer. That's a HUGE issue regarding criticity and security. Please don't underestimate that.
          Hide
          chrisabit chrisabit added a comment -

          "I'd prefer to setup a git-credentials store as a buidlwrapper"
          If that's possible and if that uses jenkins credentials, it would be a wonderful solution! I just know of the git credential cache mechanism, which doesn't maintain credentials permanently (see https://confluence.atlassian.com/display/STASH/Permanently+authenticating+with+Git+repositories).

          Show
          chrisabit chrisabit added a comment - "I'd prefer to setup a git-credentials store as a buidlwrapper" If that's possible and if that uses jenkins credentials, it would be a wonderful solution! I just know of the git credential cache mechanism, which doesn't maintain credentials permanently (see https://confluence.atlassian.com/display/STASH/Permanently+authenticating+with+Git+repositories ).
          Hide
          chrisabit chrisabit added a comment -

          "About solutions, .netrc don't support concurrent builds on same slave, so that can't be an option."
          Can you explain more about that problem please? As far as I know ~/.netrc is just another way to provide credentials (only read / no write operations). In which situations do race conditions happen?

          Show
          chrisabit chrisabit added a comment - "About solutions, .netrc don't support concurrent builds on same slave, so that can't be an option." Can you explain more about that problem please? As far as I know ~/.netrc is just another way to provide credentials (only read / no write operations). In which situations do race conditions happen?
          Hide
          ndeloof Nicolas De Loof added a comment -

          .netrc only can be set in $HOME, so you can't get N executors on the same slave to run distinct jobs with various credentials.
          That's a pitty git-cli don't let us pass (lib)curl -u option.

          in-memory git-credentials require dedicated software running on slave, and is tricky for windows users.
          I was considering using file-based git-credentials store https://www.kernel.org/pub/software/scm/git/docs/git-credential-store.html

          git init+fetch to replace git clone is a simpler option at this time - just have discovered a fetch is required after clone anyway, see JENKINS-20502

          Show
          ndeloof Nicolas De Loof added a comment - .netrc only can be set in $HOME, so you can't get N executors on the same slave to run distinct jobs with various credentials. That's a pitty git-cli don't let us pass (lib)curl -u option. in-memory git-credentials require dedicated software running on slave, and is tricky for windows users. I was considering using file-based git-credentials store https://www.kernel.org/pub/software/scm/git/docs/git-credential-store.html git init+fetch to replace git clone is a simpler option at this time - just have discovered a fetch is required after clone anyway, see JENKINS-20502
          Hide
          ndeloof Nicolas De Loof added a comment -

          git-credentials anyway can't be used to clone, as we need a git repository to store (local) git configuration and enable git-credentials support :-\
          so git init + fetch seems to be the best option.

          Show
          ndeloof Nicolas De Loof added a comment - git-credentials anyway can't be used to clone, as we need a git repository to store (local) git configuration and enable git-credentials support :-\ so git init + fetch seems to be the best option.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/8799a3a374d0e79ff37e91b7bf54fbf494cc9495
          Log:
          JENKINS-20318 prefer git init+fetch
          only use clone when required by advanced behaviors

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/8799a3a374d0e79ff37e91b7bf54fbf494cc9495 Log: JENKINS-20318 prefer git init+fetch only use clone when required by advanced behaviors
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          pom.xml
          http://jenkins-ci.org/commit/git-plugin/79e4261e5653825914299a92faf09c8ec5653a83
          Log:
          JENKINS-20318 use git-credentials-store

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: pom.xml http://jenkins-ci.org/commit/git-plugin/79e4261e5653825914299a92faf09c8ec5653a83 Log: JENKINS-20318 use git-credentials-store
          Hide
          markewaite Mark Waite added a comment -

          Is this now resolved? I'm definitely using the credentials plugin successfully with git-client-plugin 1.6.2 and git-plugin 2.0.1.

          Show
          markewaite Mark Waite added a comment - Is this now resolved? I'm definitely using the credentials plugin successfully with git-client-plugin 1.6.2 and git-plugin 2.0.1.

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              chrisabit chrisabit
            • Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: