This requires the concept of interesting branches and revisions to be introduced to the SCM API plugin.

Once that is present then you should be able to mark commits from non-whitelisted users as non-interesting and hence the branch-api plugin suppress automatic building of those commits

In the interim, the best workaround you can use is to leverage trust for non-origin forks. Builds from non-trusted users will build using the Jenkinsfile from the target branch. Then in your target branch Jenkinsfile you can have the very first thing be a check against the whitelist of users and abort the build if the user is not in the whitelist (you'd probably like to have JENKINS-27092 to allow you to do this with the error step so you could get the natural NOT_BUILT status... but it's not critical if you just need to ensure that the whitelist is enforced)

The proposed solution doesn't really implement what the OP is requesting.

He doesn't want to outright refuse to build PRs from non-whitelisted users but wants them to be sent to an approval queue where he can release them to be built or reject them.

This kind of security is really quite important as without it, it allows all-comers to execute any code they want on your builders.

100% agree.  The GHPRB plugin which appears to have now been deprecated in favor of github-branch-source-plugin has a major feature gap that appears to have been misunderstood here.  This is a blocker issue for us on migrating away from GHPRB, and from a security perspective we're currently in a less than desirable position since GHPRB seems to presently have security issues.

As a maintainer of an OSS project running a self-hosted Jenkins instance for the community, I want to build all PRs by those who are trusted contributors (which may be more than just those with merge rights) automatically.  For those who are not trusted, the PR build needs to be authorized via PR comment by a trusted user before it is built.  This should support Multibranch pipeline style jobs via Jenkinsfile so that the build process itself may be updated by untrusted OSS contributors.  This approval pipeline/step/check is critical because you must protect against malicious PR modifications of a Jenkinsfile.

Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA