Parentheses in job names break git checkout with manually provided host key

[cubistico]

Jenkins and plugins versions report

Environment

Using docker image jenkins/jenkins:lts-jdk21 on Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-177-generic x86_64)

Note: The problem occurred after rebuilding the container one day ago, so it was probably introduced in a recent publication of the tag.

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

Using docker image jenkins/jenkins:lts-jdk21 on Ubuntu host

Reproduction steps

1. Create a job name that contains parentheses on a controller that uses manually provided host keys to validate the SSH connection for git
2. Have it use a Jenkinsfile from git
3. Run it

Expected Results

Job should run without problems (and it used to work since years)

Actual Results

Git checkout fails with Syntax error: "(" unexpected

Full output:

10:26:14   > git fetch --tags --force --progress -- ssh://git@hidden.domain.name:7722/util/jenkins-shared-library.git +refs/heads/*:refs/remotes/origin/* # timeout=10
10:26:14  ERROR: Error fetching remote repo 'origin'
10:26:14  hudson.plugins.git.GitException: Failed to fetch from ssh://git@hidden.domain.name:7722/util/jenkins-shared-library.git
10:26:14  	at PluginClassLoader for git//hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:998)
10:26:14  	at PluginClassLoader for git//hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1239)
10:26:14  	at PluginClassLoader for git//hudson.plugins.git.GitSCM._checkout(GitSCM.java:1310)
10:26:14  	at PluginClassLoader for git//hudson.plugins.git.GitSCM.checkout(GitSCM.java:1277)
10:26:14  	at PluginClassLoader for workflow-scm-step//org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:136)
10:26:14  	at PluginClassLoader for pipeline-groovy-lib//org.jenkinsci.plugins.workflow.libs.SCMBasedRetriever.lambda$doRetrieve$4(SCMBasedRetriever.java:200)
10:26:14  	at PluginClassLoader for pipeline-groovy-lib//org.jenkinsci.plugins.workflow.libs.SCMBasedRetriever.retrySCMOperation(SCMBasedRetriever.java:222)
10:26:14  	at PluginClassLoader for pipeline-groovy-lib//org.jenkinsci.plugins.workflow.libs.SCMBasedRetriever.doRetrieve(SCMBasedRetriever.java:199)
10:26:14  	at PluginClassLoader for pipeline-groovy-lib//org.jenkinsci.plugins.workflow.libs.SCMRetriever.retrieve(SCMRetriever.java:65)
10:26:14  	at PluginClassLoader for pipeline-groovy-lib//org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:297)
10:26:14  	at PluginClassLoader for pipeline-groovy-lib//org.jenkinsci.plugins.workflow.libs.LibraryAdder.add(LibraryAdder.java:156)
10:26:14  	at PluginClassLoader for pipeline-groovy-lib//org.jenkinsci.plugins.workflow.libs.LibraryDecorator$1.call(LibraryDecorator.java:125)
10:26:14  	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087)
10:26:14  	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:624)
10:26:14  	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:602)
10:26:14  	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:579)
10:26:14  	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:323)
10:26:14  	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:293)
10:26:14  	at PluginClassLoader for script-security//org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox$Scope.parse(GroovySandbox.java:162)
10:26:14  	at PluginClassLoader for workflow-cps//org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:202)
10:26:14  	at PluginClassLoader for workflow-cps//org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:186)
10:26:14  	at PluginClassLoader for workflow-cps//org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:670)
10:26:14  	at PluginClassLoader for workflow-cps//org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:616)
10:26:14  	at PluginClassLoader for workflow-job//org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:344)
10:26:14  	at hudson.model.ResourceController.execute(ResourceController.java:97)
10:26:14  	at hudson.model.Executor.run(Executor.java:456)
10:26:14  Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- ssh://git@hidden.domain.name:7722/util/jenkins-shared-library.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
10:26:14  stdout: 
10:26:14  stderr: /var/jenkins_home/jobs/Security Checks (OWASP) for My project/workspace@libs/ce6aa583a2c907f1310d861761a4b6d8b91b873ed4d7d0035e1d9a62a809fdcb@tmp/jenkins-gitclient-ssh2608752526904972336.sh-copy: 6: Syntax error: "(" unexpected
10:26:14  fatal: Could not read from remote repository.

Anything else?

The error went away after removing the parentheses from the job names. However parentheses in job names did not use to cause any issues before, so this seems to be a bug/regression.

Are you interested in contributing a fix?

No response

[timja]

Whilst its a bug and should be fixed somewhere, I'd suggest keeping your job names to simple text and then using the display name field for the prettier name.

[daniel-beck]

did not use to cause any issues before

What versions of Jenkins and plugins were you using "before"?

[cubistico]

I used the absolute same version of Jenkins and plugins, just recreated the image. Jenkins displays version 2.555.1 – however that is not the latest jenkins/jenkins:lts-jdk21, which seems to contain 2.555.2, so my assumption that the latest tag caused the issue seems wrong.

I admit, I'm confused now, and I currently have no idea how to reproduce what happened.

[cubistico]

Update:

I have rebuilt the image from the current jenkins/jenkins:lts-jdk21, it now reports Jenkins 2.555.2 as expected, and I was able to reproduce the bug with this image.

The manifest digest of that image is sha256:bfa50edb8f9c10b20a3c08e56ea29f7c10ae168d5ba220a78d2c8e5a45823c03

[timja]

What version did you upgrade from?

[cubistico]

2.555.1

[Dipanshusinghh]

I took a closer look at the failing path, and the Syntax error: "(" unexpected seems to be coming from the generated jenkins-gitclient-ssh*.sh wrapper script rather than from Git itself.
Since the workspace path includes the job name (Security Checks (OWASP) for My project/...), this feels like a quoting/escaping regression somewhere in the git-client shell script generation layer after upgrading from 2.555.1 → 2.555.2.

It might be worth checking whether the generated temp script paths are still being safely shell-escaped before execution when workspace names contain special shell characters like ( and ).

I can try reproducing this locally and dig through the git-client/plugin side if that would be helpful.

[cubistico]

@Dipanshusinghh, I think a reproduction of the bug by you would definitely be helpful to rule out local peculiarities on my side.

[MarkEWaite]

I am unable to duplicate the issue. You didn't provide your detailed configuration or your list of plugins, so I made assumptions. I've included those assumptions in gh-26804.zip.

Steps that I took (included in the zip file and can be executed on my Linux computer with bash ./README):

• Download and install Jenkins 2.555.2 with the configuration as code plugin, the Pipeline plugins, the Pipeline library plugin, and the git plugin (exact list of plugins and versions is in the plugins.txt file included in the zip file)
• Configure two ssh build agents, one using my user account and the other using an account named 'jagent' that does not have access to my ssh private keys (jenkins.yaml in the zip file reads the private keys from my .ssh directory)
• Create an ED 25519 private key credential in Jenkins for my GitHub account
• Define a Pipeline global library that uses git as the modern SCM to clone the repository using SSH with the Jenkins credential. The Pipeline library is loaded implicitly
• Define a Pipeline job that performs a checkout with ssh using the GitHub credential using the git Pipeline step. Restrict the job to the jagent label to assure that it runs on the jagent node
• Define a Pipeline job that performs a checkout with ssh using the GitHub credential using the checkout Pipeline step. Restrict the job to the jagent label to assure that it runs on the jagent node

There were no changes between Jenkins 2.555.1 and Jenkins 2.555.2 that should have altered the behavior of ssh based checkouts.

Are you sure that your ssh private key that is used for the Pipeline shared library is still valid?

[apuig]

thanks @MarkEWaite for this easy-to-use reproducer, very neat! 🍯

I ran it (after generating some dummy key files first :)) and noticed the CasC config doesn't set the Git Host Key Verification Strategy in Manage Jenkins > Security, so it defaults to "Known hosts file".

When manuallyProvidedKeyVerificationStrategy is added:

security:
  gitHostKeyVerificationConfiguration:
    sshHostKeyVerificationStrategy:
      manuallyProvidedKeyVerificationStrategy:
        approvedHostKeys: "github.com ssh-ed25519 AAAA..."

the SSH wrapper script fails with Syntax error: "(" unexpected. Looks like its only ManuallyProvidedKeyVerifier embeds the temp known_hosts path (which contains the parenthesized job name) into the shell script without proper quoting.

@cubistico, could you please confirm if your environment uses "Manually provided keys" ?

[MarkEWaite]

Thanks @apuig . That means this issue should be transferred to the git client plugin repository.

[MarkEWaite]

The workarounds for the issue include:

• Use 'accept first connection' instead of manually provided host key
• Remove the '(' character from the job name

[cubistico]

@apuig I can indeed confirm that my environment uses "Manually provided keys". Even more, that was changed only recently and so is most probably why the jobs suddenly started to throw that error. However, since I've also rebuilt the docker container, unfortunately, I didn't think of that change as a possible cause.
Great job tracking this down!