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

Paranoid mode for git-changelist-maven-extension

    XMLWordPrintable

Details

    Description

      By default, or (if performance is poor) upon request from CI, do a RevWalk of the whole repository looking for clashes in commit hash prefix and rev count. If any is found, fail the build.

      This would block attempts to spoof a legitimate commit.

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            There seem to be no clashes in jenkinsci/jenkins of hash prefix length 8 or greater; there is one of length 7, and a few dozen of length 6. There are no clashes of prefix and rev count of prefix length 4 or greater; at length 3, 84d9244520b917629e82b762eb7b7548cf5f6b9f and 84dcde5902755239f915dedafbdc0566bcde087a clash. Since we are using a 12-digit prefix, an accidental collision seems extremely unlikely.

            jglick Jesse Glick added a comment - There seem to be no clashes in jenkinsci/jenkins of hash prefix length 8 or greater; there is one of length 7, and a few dozen of length 6. There are no clashes of prefix and rev count of prefix length 4 or greater; at length 3, 84d9244520b917629e82b762eb7b7548cf5f6b9f and 84dcde5902755239f915dedafbdc0566bcde087a clash. Since we are using a 12-digit prefix, an accidental collision seems extremely unlikely.
            jglick Jesse Glick added a comment -

            Done, but it is not enough to block attacks, since the search for clashes only runs from commits reachable from HEAD. If a legitimate developer pushes a (perhaps forked) PR, and then an attacker immediately creates another (forked) PR with a clashing prefix + revcount, neither CI build will see the other—and although the malicious PR would fail if the legitimate PR had already been merged, the attack would consist of trying to get the malicious PR deployed before the legitimate PR deployed, much less was merged. So the deployment tool also needs to check for prefix clashes across forks.

            jglick Jesse Glick added a comment - Done, but it is not enough to block attacks, since the search for clashes only runs from commits reachable from HEAD . If a legitimate developer pushes a (perhaps forked) PR, and then an attacker immediately creates another (forked) PR with a clashing prefix + revcount, neither CI build will see the other—and although the malicious PR would fail if the legitimate PR had already been merged, the attack would consist of trying to get the malicious PR deployed before the legitimate PR deployed, much less was merged. So the deployment tool also needs to check for prefix clashes across forks.

            People

              jglick Jesse Glick
              jglick Jesse Glick
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: