Version 887 breaks usage of scm.userRemoteConfigs[].credentialsId

[TwoStone]

Jenkins and plugins versions report

Environment

Jenkins: 2.452.2
OS: Linux - 6.5.0-1020-aws
Java: 17.0.11 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)

What Operating System are you using (both controller, and any agents involved in the problem)?

Linux - 6.5.0-1020-aws on kubernetes

Reproduction steps

We have some steps in our jenkins pipelines that use the credentials provided for the checkout for other git actions.
Therefor we use some credentials binding
withCredentials([usernamePassword( credentialsId: scm.userRemoteConfigs[0].credentialsId, usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD' )])

This works with versions of these plugin previous to 887

Expected Results

scm.userRemoteConfigs[0].credentialsId returns the credentials id

Actual Results

Jenkins build breaks with:

09:34:41 java.lang.NullPointerException 09:34:41 at java.base/java.util.Objects.requireNonNull(Unknown Source) 09:34:41 at com.cloudbees.plugins.credentials.CredentialsProvider.findCredentialById(CredentialsProvider.java:897) 09:34:41 at com.cloudbees.plugins.credentials.CredentialsProvider.findCredentialById(CredentialsProvider.java:866) 09:34:41 at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:195) 09:34:41 at org.jenkinsci.plugins.credentialsbinding.impl.UsernamePasswordMultiBinding.bind(UsernamePasswordMultiBinding.java:73) 09:34:41 at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2.doStart(BindingStep.java:132) 09:34:41 at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77) 09:34:41 at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) 09:34:41 at java.base/java.util.concurrent.FutureTask.run(Unknown Source) 09:34:41 at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 09:34:41 at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 09:34:41 at java.base/java.lang.Thread.run(Unknown Source)

Anything else?

I think this was very likely introduced by the security fix ad359b3

Is this a bug or is it the intended behaviour?

Are you interested in contributing a fix?

No response

[a-mironenko-dataart]

We've got a regression as well, in a multi-project setup.

The Projects -> Repository Sources config uses OAuth tokens for authentication ("consumer"), so the token was used for the checkout over HTTPS.
The checkout is basic, as follows.

checkout([
                $class: 'GitSCM',
                branches: scm.branches,
                // ...
                userRemoteConfigs: scm.userRemoteConfigs,
            ])

After the upgrade from v848 to v888, the token is not used, failing checkout.

[Pipeline] checkout
The recommended git tool is: NONE
No credentials specified
Cloning the remote Git repository
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- https://orgname@bitbucket.org/orgname/repo.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: remote: Invalid credentials
fatal: Authentication failed for 'https://bitbucket.org/orgname/repo.git/'

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2846)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2185)
...
	Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to i-agent
...
		at jdk.proxy82/jdk.proxy82.$Proxy229.execute(Unknown Source)
		at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1222)
		at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1305)
		at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:136)

Reverting to older build helps:

[Pipeline] checkout
The recommended git tool is: NONE
using credential c243f692-0d5c-785a-9c05-bc326895b375
Cloning the remote Git repository
Cloning repository [https://x-token-auth:{tokeninplaintext}@bitbucket.org/orgname/repo.git](https://x-token-auth:tokeninplaintext@bitbucket.org/orgname/repo.git)

[amandel]

The issue cam in with: 886.v44cf5e4ecec5...887.va_d359b_3d2d8d - this looks like it was done by intention. But how can we now get the CredentialId?

[mmohrwinkel]

Can confirm, we are affected, too. Rolling back to version 886 fixes the problem, but obviously reintroduces the vulnerability.

[chilicheech]

This is happening to all my builds as well. scm.userRemoteConfigs[0].credentialsId is returning null

[Dohbedoh]

The fix could be as simple as continue passing credentialsId to the GitSCM but.. we need to make sure that we do not reintroduce the security problem.. Only maintainers and jensec team can tell us.