Open TwoStone opened 2 months ago
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)
The issue cam in with: https://github.com/jenkinsci/bitbucket-branch-source-plugin/compare/886.v44cf5e4ecec5...887.va_d359b_3d2d8d - this looks like it was done by intention. But how can we now get the CredentialId?
Can confirm, we are affected, too. Rolling back to version 886 fixes the problem, but obviously reintroduces the vulnerability.
This is happening to all my builds as well. scm.userRemoteConfigs[0].credentialsId
is returning null
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.
Jenkins and plugins versions report
Environment
```text 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 https://github.com/jenkinsci/bitbucket-branch-source-plugin/commit/ad359b3d2d8d6c114025d81abc59b3c9acb636df
Is this a bug or is it the intended behaviour?
Are you interested in contributing a fix?
No response