setClientVersion-implementation as discussed in #129 #130

kimmerin · 2022-03-09T12:21:01Z

Compared to the logger issue this is a more simple change. I've added a system-property that allows to set the client version that way as well and added tests to check the behavior. This required the setup of the config-hashtable to be in a dedicated method.

system property. Added tests.

norrisjeremy · 2022-03-09T12:26:45Z

src/main/java/com/jcraft/jsch/Session.java

  }
  public void setClientVersion(String cv){
+    V_C = null;


This will lead to an NPE if a user explicitly calls setClientVersion(null) because the V_C property is dereferenced in the connect() & receive_kexinit() methods.

All the tests that actually show that require a Docker-container I don't have. I've changed it so that everything is using the get-method now

particular client version has been set

norrisjeremy · 2022-03-09T12:54:39Z

src/main/java/com/jcraft/jsch/Session.java

@@ -624,7 +625,7 @@ private KeyExchange receive_kexinit(Buffer buf) throws Exception {
      throw new JSchException(e.toString(), e);
    }

-    kex.doInit(this, V_S, V_C, I_S, I_C);
+    kex.doInit(this, V_S, Util.str2byte(getClientVersion()), I_S, I_C);


If a user changed the client version string after a Session is connected and a rekeying operation occurred, their SSH connection would then break, because the client version is supposed to be idempotent.

Whilst this could already happen prior, with how you've adapted the Session class to fallback to calling an instance method in the JSch class, we would be making this scenario easier for a user to trigger, since they may naively believe they can change the client version of the JSch instance between multiple calls to getSession().

I'm thinking we should avoid this scenario, by simply initializing the V_C property to whatever the value of jsch.getClientVersion() is at the time the Session instance is created and avoid trying the callbacks to jsch.getClientVersion() within session.getClientVersion().

We simply would need to document to users that the client version of a Session instance is not affected by changes to the JSch instance after the Session is created, and that the only way to manipulate afterwards is by direct calls to session.setClientVersion().

Changing the client version while being in an active session was possible before so we've found a possible bug here as far as I can see it. I've solved it now by recreating a member V_C that is filled with the bytes of the client version that is returned by getClientVersion at the time of connect.

"immutable" and allow users to change the setting on the JSch- or Session-level

norrisjeremy · 2022-03-09T13:15:44Z

src/main/java/com/jcraft/jsch/JSch.java

+    fillConfig(config, JavaVersion.getVersion());
+  }
+
+  static void fillConfig(Map<String, String> config, int javaVersion) {


What's the purpose of the javaVersion argument? It appears to be unused?

It allows to test the different behavior in dependence of different java versions without the requirement to actually use that particular java version when executing the test

What's missing is a checkFillConfiig in JschTest but that's a big TODO I haven't had the time to attack

... and the actual use of the parameter was missing as well. Not sure what happened here, I've definitely used it when doing the implementation.

I'm still not sure I understand why we need a javaVersion argument instead of simply using JavaVersion.getVersion()?
The value returned by JavaVersion.getVersion() doesn't dynamically change at runtime.

I've committed JschTest showing the use of this parameter as part of a unit test. The fact that JavaVersion.getVersion doesn't change at runtime is the actual problem if you want to test behavior that depends on this value

norrisjeremy · 2022-03-09T13:21:13Z

src/main/java/com/jcraft/jsch/Session.java

@@ -81,7 +81,8 @@
  private static final int PACKET_MAX_SIZE = 256 * 1024;

  private byte[] V_S;                                 // server version
-  private byte[] V_C=Util.str2byte("SSH-2.0-JSCH_"+JSch.VERSION); // client version
+  private byte[] V_C; // will be set during connect so that the client version


Why not simply do VC=Util.str2byte(jsch.getClientVersion()) here?
Then we could omit all the other changes to this class.

There might be a setClientVersion on Jsch-level after creating a session and before doing a connect that would get lost that way

I think it's easier to document and understand that calls to jsch.setClientVersion() have no impact to any previously created Session instances than it is to document and understand that jsch.setClientVersion() affects any previously created Session instance that has not yet execute session.connect().

Basically: after you create a Session object, via jsch.getSession(), the only way to manipulate the client version string of said Session object should be via session.setClientVersion(), independent of any calls to jsch.setClientVersion() that occur after you have created the Session object.

Even if we implement it the way you suggested you need to either have a distinct member for the client version bytes used during a connection or check the state of the session and throw an exception if you try to set the version string after a connection has been established.

Otherwise you will run into the problem you've described before:

If a user changed the client version string after a Session is connected and a rekeying
operation occurred, their SSH connection would then break, because the client version
is supposed to be idempotent.

Personally I don't think that this is hard to document and I can add a javadoc comment trying to do it to the method (I would have done so anyway, if the method didn't exist already).

Added some javadoc that should explain the way this works.

I still disagree with this.
@mwiede what are your thoughts?

@mwiede Any thoughts on this?
Should we just go with a simpler approach I suggested or the more complex approach implemented here?

norrisjeremy · 2022-03-09T13:50:43Z

src/test/java/com/jcraft/jsch/JSchTest.java

+        assertEquals("com.jcraft.jsch.bc.XDH", map.get("xdh"), "check of xdh failed");
+        JSch.fillConfig(map, 11);
+        assertEquals("com.jcraft.jsch.jce.XDH", map.get("xdh"), "check of xdh failed");
+        JSch.fillConfig(map, 12);


Do we need to test this for 12 since it is the same as 11?

I'm always testing the edge cases to make sure that if somebody for some reason changes >= to ==, the test fails.

To -v that: a >= b can be seen as a shortcut for a == b || a > b. To have complete coverage over the conditions you need to implement three tests: one for a < b, one for a == b and one for a > b.

norrisjeremy · 2022-03-09T13:51:05Z

src/test/java/com/jcraft/jsch/JSchTest.java

+        assertEquals("com.jcraft.jsch.jce.KeyPairGenEdDSA", map.get("keypairgen.eddsa"), "check of keypairgen.eddsa failed");
+        assertEquals("com.jcraft.jsch.jce.SignatureEd25519", map.get("ssh-ed25519"), "check of ssh-ed25519 failed");
+        assertEquals("com.jcraft.jsch.jce.SignatureEd448", map.get("ssh-ed448"), "check of ssh-ed448 failed");
+        JSch.fillConfig(map, 16);


Do we need to test this for 16 since it is the same as 15?

Same reason as with the test for xdh

norrisjeremy · 2022-03-09T13:59:24Z

src/test/java/com/jcraft/jsch/JSchTest.java

    void resetJsch() {
-        JSch.setLogger(null);
+      orgConfig = (Hashtable<String, String>) JSch.config.clone();


How about simply doing new Hashtable<>(JSch.config), to avoid the ugly cast and call to clone()?

The "copy-constructor" creates shallow copies but with immutable values this isn't an issue here, so I've changed it as suggested.

connection.

norrisjeremy · 2022-03-11T07:13:51Z

src/main/java/com/jcraft/jsch/Session.java

+   * @return The used version string or <code>null</code> if no
+   * connection is active.
+   */
+  public String getUsedClientVersion() {


I personally find this extremely convoluted and would really rather we not add this method.

Since two members are necessary to prevent the effect you've described I though, offering a get-method to allow access to these two members should be available. But I have no special feelings about this method, so I've removed it.

sonarcloud · 2024-03-15T16:22:34Z

Quality Gate failed

Failed conditions
E Maintainability Rating on New Code (required ≥ A)
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

added configurability of used client version string by setter method and

ccc0eab

system property. Added tests.

kimmerin changed the title ~~setClientVersion-implementation as discussed in #128~~ setClientVersion-implementation as discussed in #129 Mar 9, 2022

norrisjeremy suggested changes Mar 9, 2022

View reviewed changes

use get method in connect and receive_kexinit to avoid NPE if no

4ce594b

particular client version has been set

norrisjeremy suggested changes Mar 9, 2022

View reviewed changes

put client version at connect time into a separate member to make it

8cf95e0

"immutable" and allow users to change the setting on the JSch- or Session-level

norrisjeremy suggested changes Mar 9, 2022

View reviewed changes

norrisjeremy reviewed Mar 9, 2022

View reviewed changes

kimmerin added 2 commits March 9, 2022 14:21

actually use javaVersion passed as parameter to the method

c542e24

show reason of parameter javaVersion by example

1f638d0

norrisjeremy reviewed Mar 9, 2022

View reviewed changes

kimmerin added 2 commits March 9, 2022 15:08

use copy constructor rather than cloning

c134954

added javadocs and a method returning the client version used during a

85bd82d

connection.

norrisjeremy reviewed Mar 11, 2022

View reviewed changes

removed method as requested

48e46de

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

setClientVersion-implementation as discussed in #129 #130

setClientVersion-implementation as discussed in #129 #130

kimmerin commented Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

kimmerin Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 11, 2022

norrisjeremy Apr 26, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 9, 2022

kimmerin Mar 9, 2022

norrisjeremy Mar 11, 2022

kimmerin Mar 11, 2022

sonarcloud bot commented Mar 15, 2024

setClientVersion-implementation as discussed in #129 #130

Are you sure you want to change the base?

setClientVersion-implementation as discussed in #129 #130

Conversation

kimmerin commented Mar 9, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sonarcloud bot commented Mar 15, 2024

Quality Gate failed