Introduce a new trust policy: "trust pull request submitter with write right in the destination repository/branch"

[Romain-Geissler-1A]

What feature do you want to see added?

In my corporate environment with thousands of developers using Jenkins daily, the deployment of the latest version of the BitBucket source plugin had quite some effect, because of the fix for SECURITY-3300 / CVE-2024-28152.

My own experience is that most of the time, the people who submit changes to Jenkinsfile are also the "maintainers" of a given repository (at least in corporate environment, it may be less true in an open source project having many external contributors). So in most cases, I would expect the person submitting a change to a Jenkinsfile via pull request also has the "write" right on BitBucket side, so is a rather "trusted" person. The current implementation of who is trusted and who isn't in the BitBucket source plugin assumes that if you can create a fork inside the project, then somehow you have the "write" right into the whole project, so you are "trusted". I think this encourages wrong practices (I honestly don't see why people would create some "my-project2" BitBucket project to be able to test a change targetting "my-project"), and IMO it hardly makes sense to start teaching my colleagues that:

• if you want to submit a change affecting only the "normal" code, you should create a branch in your own personal fork and submit a pull request the "normal" way (ie without polluting any "public" repository or BitBucket folder with your own experimental branches/projects besides the pull request)
• if you want to submit a change affecting jenkinsfile, you should create a new fork, which isn't your personal fork, "pollute" everyone with it, and submit your pull request from there

In the end, what people would like is to keep submitting pull request like they always did, from their own personal fork, and IMO these people shall be trusted if they have the right to write in the destination branch/pull request. The fact of deducing this right from the ability to fork from inside the BitBucket project is weird and looks like a "side channelled" way to get the real information that really matters "can this person write in my repo in the end" ?

So would it be acceptable to add a 4th trust policy in this plugin, and potentially even making it the default ?

Upstream changes

No response

Are you interested in contributing this feature?

I hardly know anything in Java, and hardly know your code. If maintainers of these repo do accept the idea, but have no time to implement it, I (or someone in my company) may try to have a look to help implementing this.

[KalleOlaviNiemitalo]

Do Bitbucket Cloud and/or Bitbucket Data Center provide an API that Jenkins could use to check whether the author of the pull request has write access? IIRC, Bitbucket Cloud in particular has tightened access to user information because of GDPR.

[Romain-Geissler-1A]

Indeed looking at the API of BitBucket Data Center it really doesn't seem to exist. In BitBucket Cloud it seems there is a notion of "role", the one with write access being "contributor" but I am not sure how restricted is this API.

Since in my case I care more particularly about BitBucket Data Center, and with the privacy in mind as I guess exposing who has right to do what is a bit a sensitive information, I have opened a different feature request on BitBucket Data Center side here: https://jira.atlassian.com/browse/BSERV-19339

[KalleOlaviNiemitalo]

The author of the pull request may be different from

• the owner of a personal repository that contains the source branch of the pull request
• a user who has write access to the source branch of the pull request
• the user who pushed commits to the source branch of the pull request
• the author of commits in the pull request
• the committer of commits in the pull request

There is a rejected feature request [BSERV-8635] Ability to change the author of a pull request. If that were ever implemented and Jenkins used the author of a pull request for the trust decision, then the following could happen:

1. A user makes a pull request from a personal fork. This PR does not change Jenkinsfile yet.
2. A project maintainer takes authorship of the PR, in order to make commits and request approval from the original author. Jenkins now starts trusting the PR.
3. The original author pushes commits that change Jenkinsfile. Jenkins trusts these.

BSERV-8635 seems unlikely to be implemented so this scenario cannot happen as is. Regardless, I feel it is an indication that the PR authorship might not be the best input for the trust decision. What could be used instead:

• Jenkins-side group of trusted users per project. If the PR commits are from a member of the group, then trust them. Con: committer information can be forged.
• Bitbucket-side "trusted" flag on pull requests, and a per-repository role authorised to set the flag. Set the flag by default, on pull requests created by users in those roles. Con: needs a change or a plugin in Bitbucket Data Center. Pro: simple, predictable behaviour; Bitbucket would not need to detect Jenkinsfile changes specifically.