[FIXED JENKINS-39232] - DefaultJnlpSlaveReceiver should not reject connections from non-JNLP launchers

[oleg-nenashev]

In 2.27 we released Remoting 3. It required some patches in the core.

There was also compatibility check hardening:

jenkins/core/src/main/java/jenkins/slaves/DefaultJnlpSlaveReceiver.java

Lines 50 to 53 in 71cbe0c

	if (computer == null || !(computer.getLauncher() instanceof JNLPLauncher)) {
	event.reject(new ConnectionRefusalException(String.format("%s is not a JNLP agent", clientName)));
	return;
	}

From what I see the code does not process ComputerLauncherFilter or DelegatingComputerLauncher correctly, and it causes failures of plugins like Slave Setup Plugin (https://github.com/jenkinsci/slave-setup-plugin/blob/ba1a93e0d1a4a150c1cd1cda87a29930a2d60773/src/main/java/org/jenkinsci/plugins/slave_setup/SetupSlaveLauncher.java#L23).

It also breaks plugins like VSphere plugin, which use JNLP, but declare there own Launcher, which nests the JNLP one: https://github.com/jenkinsci/vsphere-cloud-plugin/blob/dd3f70f41b06ac2ab3e02996f924a73f15850911/src/main/java/org/jenkinsci/plugins/vSphereCloudLauncher.java#L31

https://issues.jenkins-ci.org/browse/JENKINS-39232

@reviewbybees @jenkinsci/code-reviewers @stephenc

[oleg-nenashev]

Maybe it leaks the fact of the agent existense

[ghost]

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

[stephenc]

🐛 👎 should not allow non-jnlp agents to connect on a jnlp launcher... correct solution would be to walk the delegating computer launcher instances to see if one of them is a JNLP launcher

[oleg-nenashev]

@stephenc Well, this approach won't work with plugins, which extend ComputerLauncher on their own. And there are many of them, not only vSphere cloud plugin. See https://github.com/search?q=org%3Ajenkinsci+%22extends+computerlauncher%22&type=Code

The proposed fix contains TODO for a better replacement. I do not believe we can fix and test all plugins by the next weekly, hence I propose this PR as a temporary fix

[oleg-nenashev]

It does not help with vSphere Launcher I've referenced

On Oct 26, 2016 11:40 AM, "Stephen Connolly" notifications@github.com
wrote:

🐛 👎 should not allow non-jnlp agents to connect on a jnlp launcher...
correct solution would be to walk the delegating computer launcher
instances to see if one of them is a JNLP launcher

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2601 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC3IoP2nNuC9A9PzM9R_lH0FUf-OvGauks5q3yAEgaJpZM4Kg274
.

[oleg-nenashev]

Closing in favor of #2602

[KostyaSha]

@stephenc so you are enforcing plugins to extend classes while java doesn't allow multiple inheritance?

[KostyaSha]

Please reopen

[oleg-nenashev]

I will reopen it just to continue the discussion

[KostyaSha]

@stephenc

[stephenc]

🐛 for reasons I have previously raised out of band

[stephenc]

If you are going to do this rather than walk the delegation chain, you need to reject a connection over JNLP where a connection is already established and connected.

[KostyaSha]

@stephenc what is the reason? I will repeat my question, there are plugins that already do class inheritance. Now in non 3.0 you introduced breaking API behaviour and plugins doesn't work. People just adding ignore property. This is not acceptable in 2.x terms. Such behaviour could be planned for 3.X or any other breaking release.

[stephenc]

@KostyaSha the reason starts with S and ends in Y.

[stephenc]

@oleg-nenashev why is this still open?

[oleg-nenashev]

@stephenc Just because I do not feel that screwing up so many plugins was a good decisions. But since nobody else from @jenkinsci/code-reviewers or CloudBees bothers to provide feedback, I suppose we can close it with the "Nobody else GAF" resolution