Open Romain-Geissler-1A opened 3 months ago
KalleOlaviNiemitalo
commented
3 months ago 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
commented
3 months ago 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
commented
3 months ago The author of the pull request may be different from
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:
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:
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)
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.