Uploaded image for project: 'Bitbucket Server'
  1. Bitbucket Server
  2. BSERV-7983

Possibility for developer spoofing at a git level with BB Server



    • Bug
    • Status: Closed (View Workflow)
    • Low
    • Resolution: Duplicate
    • None
    • None
    • None
    • None


      Concerns have been raised around the validation of the authorship of Git commits from an audit point of view. Ie. in the future would we be able to identify with confidence the author of a particular change/commit.

      This is because Git requires that the user self enter their name and email address in their local Git configuration (which by default is not setup). There is no ‘single sign on’ or LDAP integration of the Git tools with any identity authority system.

      The authorship information specified on the machine is then added to every commit that user makes.

      By default Stash accepts every commit and does not verify or validate that the user submitting (pushing) the commits is the same person recorded in the commit itself.

      This raises the possibility that someone could impersonate another person and make a commit under a different name.

      It would be very hard to determine who the original committer/author was, as no IP address or machine name information is recorded which could be used to trace this.

      In addition, depending on how locked down a repository is, it is possible for someone (or at least the repository administrator) to go back through commit history to either remove a commit that was made, alter it or change the authorship of a commit.

      This clearly raises a few concerns from.

      It therefore seems prudent that some checks are performed on Stash to govern and control this.

      I believe there are some plugins that might help, like the “Yet Another Commit Checker” which can validate that the person pushing the changes is the person recorded in the commit. Although these could also be switched off at the repository level and so circumvented by the administrator and it does not help with the rewriting of history.

      Any plugin would have to work with the Git rebasing mechanism that is being used by teams to bring in changes to their branches.

      An additional plugin that would help would be one to enforce that all changes undergo a pull request/code review and that all changes are therefore reviewed and approved by the team/gatekeeper prior to committing.


        Issue Links



              Unassigned Unassigned
              a84825c9556e Barclays Vendor Management
              0 Vote for this issue
              2 Start watching this issue