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.