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

Paranoid mode for git-changelist-maven-extension

    Details

    • Similar Issues:
    • Epic Link:

      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

            Hide
            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.

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

            Show
            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

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

                Dates

                • Created:
                  Updated:
                  Resolved: