restore java8 compatability

[jtnord]

See JENKINS-69229.

revert the parent update that enforces java11 and does not give a nice way to go back to java 8.
(we would have to change 2 properties, as well as override parts of the enforcer - but then we would still require java11 to build/release which is not ideal when we want to be extra careful that we are correctly restoring lost functionality)

with this version of the parent spotbugs reports a lot of issues and as we are fine with the reports before this change (I guess false positives that have been fixed) I have just disabled spotbugs for the moment.

maven-enforcer-plugin is checking the bytecode of all the libraries, whilst it excludes jbcrypt this is version 1.0.0 that has been included for over 5 years so this should not be causing any new issues.

Submitter checklist

• JIRA issue is well described
• Appropriate autotests or explanation to why this change has no tests

[jglick]

trilead-ssh2/.github/dependabot.yml

Lines 3 to 6 in a4b1c4f

	- package-ecosystem: "maven"
	directory: "/"
	schedule:
	interval: "weekly"

nothing is preventing this from being undone.

[jtnord]

I would expect a human review to be obvious as the diff will show

<!-- do not upgrade the parent until we want to force everyone to java11 --> directly above the line being changed.

[kuisathaverat]

I do not see a strong reason to restore Java 8 compatibility, in less than 30 days Jenkins will not support it.

[ericndunn]

I do not see a strong reason to restore Java 8 compatibility, in less than 30 days Jenkins will not support it.

We have some Legacy support that requires Java8 connections for Jenkins ssh-slave plugins

[jglick]

We have some Legacy support that requires Java8 connections

And nothing is stopping you from running the current plugin version on your server, which is presumably older than 2.357 which dropped Java 8 support. This issue is about new plugin releases.

[kuisathaverat]

We have some Legacy support that requires Java8 connections for Jenkins ssh-slave plugins

Jenkins core >=2.357 will require Java 11. If you use trilead-api >= 1.71.v9e7860a_67a_df, the agents connected to this Jenkins must use Java 11 too. The recommendation is to use the same JDK on the Jenkins Controller and Jenkins Agents.
If your requirement to use Java 8 is to compile and test your software, you can still do it. You can use different JDKs to run the remoting process on JEnkins Agents and to build and test your software, it is a matter of configure it.

[kuisathaverat]

I think this PR can be closed

[Elisedlund-ericsson]

@kuisathaverat there have been tons of complaints within my company that the new version required JDK11 while many were still stuck on java 8 (atleast for a short while more)
I had to finally revert to an older version of trilead to restore java 8 compatibility in my library that uses trilead.
and then tell the users of my library to override version to the latest version of trilead if they needed #93
So far none that were stuck on java 8 and needing #93 at the same time

[jglick]

Someone outside Jenkins is still using Trilead? It should be considered deprecated.

[slandelle]

@jglick We're using com.trilead.ssh2.crypto.PEMDecoder to decode OPENSSH private keys. Couldn't figure out how to do it with BouncyCastle so far.

[Elisedlund-ericsson]

@jglick so what would you recommend instead?
I think you are selling Trilead short.
We have lookinto switching before to other libraries such as Jsch, sshj before, they possibly won on stuff such as easy to use API but did not support all the same authentication protocols or algorithms(like #38 which we need) and/or had lower performance.
(edit: https://github.com/connectbot/sshlib could be an option also but that is just a trilead fork without our fixes)

mina-sshd was probably not fully ready at that point but is probably good enough today.
What about Trilead caused you consider it be deprecated and not good enough to be used?

We wrap Trilead in our own API and use it to connect to huge amount of ssh servers of different kinds and it has always worked fantastic for our endusers, All error blamed on Trilead has almost always been user error, crappy ssh server or network setup.
We have been able contribute to Trilead for all the issues we have had, some examples #7 #38 #40 #44 #60 #93 (we probably added almost all the new MAC and KEX over the years)

Swapping ssh library would mostly be a headache for us, and would only cause toons of minor integration issues for our users, like the disconnect taking 50ms longer or stupid stuff like that.

[kuisathaverat]

I am porting the SSH build agent to mina-sshd, it is nice than Trilead at API level and is well documented. I also have test connectbot that was my first option to shade that library replacing only a few classes that are Jenkins implementations, was fine too. Finally, I chose Apache Mina SSHD because the Apache foundation is behind and is well documented.
The change will be progressive, but at some point, I will remove Trilead from my plugin, and I will stop maintaining the Trilead-ssh2 repository, I will say no more than a year from now. After that, the Trilead-ssh2 will be in adoption, and I cannot ensure someone will maintain it.

What about Trilead caused you consider it be deprecated and not good enough to be used?

We are the only ones who use and maintain this library. Security issues and updates come slow because we are limited people. Other libraries like Apache Mina SSHD are well maintained. Trilead SSH2 library is a really old code with a bunch of outdated ways to make stuff, and in some cases really odd and unjustified. It is really hard to maintain, when we add a new feature it is really easy to break something, in deed we did many times, it is really time consuming.