Skip to content
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

Updating sshd-core to 1.4.0 #10

Merged
merged 3 commits into from
Apr 21, 2017
Merged

Conversation

jglick
Copy link
Member

@jglick jglick commented Mar 15, 2017

Helpful, if not strictly required, for jenkinsci/jenkins#2795. Cf. #8.

Note that sshd-core is not compatible across the 1.0 boundary (hence the src/main/java/ changes), but

  • It should not matter for typical plugins since the only extension point from Jenkins is SshCommandFactory, which is only referring to Command, which does not seem to have changed in interface (including its transitive dependencies) since 0.x.
  • cloudbees-ssh-slaves uses 0.13.0 and would not compile against 1.x, but it declares an explicit dependency and uses pluginFirstClassLoader.
  • ssh-agent uses 1.0 and pluginFirstClassLoader.
  • remote-terminal-access uses Jenkins’ version and will not work with 1.x, but only in the commands that would be broken by [JENKINS-41745] Non-Remoting-based CLI jenkins#2795 anyway (at least without using deprecated Remoting mode); it could probably be fixed up to work in Remoting mode by using the pluginFirstClassLoader trick.
  • Some test code in various places may be broken, particularly in plugin-compat-tester, but this is not a user issue and is easily solved by declaring an explicit test-scoped dependency on 1.x.

@reviewbybees

@stephenc
Copy link
Member

cloudbees-ssh-slaves uses 0.13.0 and would not compile against 1.x, but it declares an explicit dependency and uses pluginFirstClassLoader.

I have a PR in flight that upgrades this to 1.2.0

@ghost
Copy link

ghost commented Mar 15, 2017

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.

jglick added a commit to jglick/jenkins that referenced this pull request Mar 15, 2017
@oleg-nenashev oleg-nenashev self-assigned this Mar 24, 2017
@oleg-nenashev oleg-nenashev self-requested a review March 24, 2017 20:50
@jglick
Copy link
Member Author

jglick commented Apr 6, 2017

Manually tested cloudbees-ssh-slaves and it was fine, as was some sample usages of git-server. Hard to test ssh-agent since as of jenkinsci/ssh-agent-plugin#18 it is not using SSHD by default anyway.

@oleg-nenashev
Copy link
Member

oleg-nenashev commented Apr 7, 2017

Some other research according to the compatibility change in 1.0 https://git-w%69p-us.apache.org/repos/asf?p=mina-sshd.git;a=commitdiff;h=6824d759a9f89940c7deccc710a2f6071ce93dba:

  • org.apache.sshd.ClientSession is not used within the jenkinsci org
  • org.apache.sshd.SshClient is not being used within the jenkinsci org, cloudbees-ssh-slaves has been tested by @jglick
  • org.apache.sshd.client.channel.ChannelDirectTcpip is not used within jenkinsci GitHub org
  • org/apache/sshd/client/session/ClientSessionImpl is not used within jenkinsci GitHub org
  • org/apache/sshd/client/session/ClientUserAuthService and ClientUserAuthServiceNew are not used within jenkinsci
  • java/org/apache/sshd/common/forward/DefaultTcpipForwarder.java is not used within jenkinsci GitHub org
  • java/org/apache/sshd/common/TcpipForwarder.java is not used within jenkinsci GitHub org
  • java/org/apache/sshd/common/io/IoService.java is not used within jenkinsci GitHub org
  • org/apache/sshd/client/auth/deprecated/AbstractUserAuth.java is not used within jenkinsci GitHub org
  • org/apache/sshd/client/session/ClientUserAuthServiceOld.java is not used within jenkinsci GitHub org
  • org/apache/sshd/client/auth/deprecated/UserAuth.java is used in tests for Gerrit Trigger and SSH Credentials. It is being also used in https://github.com/jenkinsci/ssh-cli-plugin, which has been never officially released. But one may have built it...
  • org/apache/sshd/client/auth/deprecated/UserAuthAgent.java is not used within jenkinsci GitHub org
  • org/apache/sshd/client/auth/deprecated/UserAuthKeyboardInteractive is not used within jenkinsci GitHub org
  • org/apache/sshd/client/auth/deprecated/UserAuthPassword - only tests in SSH Slaves and SSH Credentials
  • org/apache/sshd/client/auth/deprecated/UserAuthPublicKey - Tests in SSH Credentials, in-code dependency in the SSH CLI Plugin

So no explicit risk in the jenkinci GitHub organization if we do not care about the unreleased SSH CLI plugin.
It does not prove anything, because the following cases are not surveyed:

  • Transient dependencies on sshd-core in external libraries being used by Jenkins plugins
  • OSS plugins located outside the jenkinsci organization in GitHub
  • Closed-source plugins

I am working on further review

@oleg-nenashev
Copy link
Member

Other dependencies:

No explicit issues in transient dependencies from what I see, but my Maven kung-fu does not seem to be strong enough to reliably check all libs being used in Jenkins plugins

jglick added a commit to jglick/jenkins that referenced this pull request Apr 7, 2017
@jglick
Copy link
Member Author

jglick commented Apr 11, 2017

Might be worth going to 1.4.0; would pick up apache/mina-sshd#29, for starters.

@oleg-nenashev
Copy link
Member

oleg-nenashev commented Apr 12, 2017 via email

@oleg-nenashev
Copy link
Member

@jenkinsci/code-reviewers and maybe @daniel-beck How do we proceed here? Is the analysis above enough to justify the compat change?

pom.xml Outdated
@@ -4,6 +4,7 @@
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>2.24</version>
<relativePath />
</parent>

<groupId>org.jenkins-ci.modules</groupId>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The release version should be 2.0 just in case

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.

@jglick
Copy link
Member Author

jglick commented Apr 20, 2017

I need to at least prepare an update to 1.4.0, and a matching core integration PR (which can also update sshd-core as used by cli, and reënable a currently ignored test). But I have seen no evidence that there is a significant compatibility risk, compared to the obvious benefit of being on a new, and supported, version of this component.

@oleg-nenashev
Copy link
Member

But I have seen no evidence that there is a significant compatibility risk, compared to the obvious benefit of being on a new, and supported, version of this component.

I did the line-by-line review of changes (see above) and also discovered nothing really risky. Just one unreleased plugin + likely some issues with PCT after the merge.

So 🐝 from me and @reviewbybees done

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the discussion above, approved. Maybe we want to also enable new more secure Ciphers as a part of the 2.0 release of the module

Copy link
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel especially qualified to review this, but I have reviewed it and don't see anything wrong.

@oleg-nenashev
Copy link
Member

@mc1arke @paladox I consider making this change along with the Trilead SSH upgrade in the core. There is no risk of inter-influence, right?

@paladox
Copy link

paladox commented Apr 20, 2017

Nope I doint think there will be any conflicts :)

I believe there is a problem with sshd 1.4.0 though, see https://bugs.chromium.org/p/gerrit/issues/detail?id=5905 and https://issues.apache.org/jira/plugins/servlet/mobile#issue/SSHD-736

1.2.0 works fine.

@jglick
Copy link
Member Author

jglick commented Apr 20, 2017

believe there is a problem with sshd 1.4.0 though

What makes you think SSHD-736 will have any effect on Jenkins? Looks offhand like a fairly technical issue limited to another environment.

@paladox
Copy link

paladox commented Apr 20, 2017

Just was warning just in case. Anyways it may not affect jenkins.

@mc1arke
Copy link
Member

mc1arke commented Apr 20, 2017

@oleg-nenashev there should be no interference that I'm aware of: Trilead isn't used in core for making any connection, and the version of Trilead in CLI has been left as-is so there shouldn't be a change in how it tries to connect to SSHD.

@oleg-nenashev
Copy link
Member

Will merge it tomorrow once I figure out an issue number for it

@jglick
Copy link
Member Author

jglick commented Apr 20, 2017

I would like to bump up to 1.4.0 first, and set up an integration PR.

@jglick jglick changed the title Updating sshd-core to 1.2.0 Updating sshd-core to 1.4.0 Apr 20, 2017
@jglick jglick closed this Apr 20, 2017
@jglick jglick reopened this Apr 20, 2017
@oleg-nenashev
Copy link
Member

I will try to check it today

@oleg-nenashev
Copy link
Member

Additionally integrated changes:

All changes there look fine, hence I am going to merge this version and maybe give a try with new Jenkins core and SSH stuff early on the next week

@oleg-nenashev oleg-nenashev merged commit 04216b8 into jenkinsci:master Apr 21, 2017
@jglick jglick deleted the sshd-update branch April 24, 2017 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants