-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 887 breaks usage of scm.userRemoteConfigs[].credentialsId #862
Comments
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. checkout([
$class: 'GitSCM',
branches: scm.branches,
// ...
userRemoteConfigs: scm.userRemoteConfigs,
]) After the upgrade from v848 to v888, the token is not used, failing checkout.
Reverting to older build helps:
|
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? |
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. |
The fix could be as simple as continue passing |
Jenkins and plugins versions report
Environment
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
The text was updated successfully, but these errors were encountered: