Register com.jcraft.jsch.jbcrypt.JBCrypt for reflection

[erik-wramner]

Fix issue #105 (hopefully, not tested) by registering JBCrypt for reflection.

[gastaldi]

Can you create a test using the snippet you provided in the issue description?

var keyPair = KeyPair.load(new JSch(), privateKeyBytes, null);
keyPair.decrypt(passphrase.getBytes(StandardCharsets.UTF_8)):

[erik-wramner]

I'll try. Problem is that code runs in Quarkus and only fails in native mode, not Java mode. Do you have any existing tests that run in native mode, that I can use as a starting point? (I'll look around).

[gastaldi]

Yes, https://github.com/quarkiverse/quarkus-jsch/blob/dced596cda52584e91f324b58fd33b1ba2a03eae/integration-tests/src/test/java/io/quarkus/it/jsch/NativeJSchIT.java runs in Native.

[gastaldi]

@erik-wramner I have a test that invokes that snippet of yours, let me push to your PR

[erik-wramner]

I also added a test, but your test is nicer. Shall I revert mine?

I haven't been able to actually test that it works. I had Visual Studio installed when this computer crashed and since then I can't reinstall it, so I can't compile native code without doing it in Docker. Can't find a way to run the integration tests in Docker, unfortunately.

I have verified with the real Quarkus release that adding com.jcraft.jsch.jbcrypt.JBCrypt to reflection-config.json helps.

[gastaldi]

I also added a test, but your test is nicer. Shall I revert mine?

Sure, I think it's better if we don't store any RSA keys in the repository :)

I haven't been able to actually test that it works. I had Visual Studio installed when this computer crashed and since then I can't reinstall it, so I can't compile native code without doing it in Docker. Can't find a way to run the integration tests in Docker, unfortunately.

I have verified with the real Quarkus release that adding com.jcraft.jsch.jbcrypt.JBCrypt to reflection-config.json helps.

That's great to hear. For some reason my test passes even without your fix, but I'll investigate what's going on

[erik-wramner]

Reverted. As for the RSA key, it is harmless, it was created for these tests, but it is still nicer to do without it.

[gastaldi]

PR Merged. Thanks! Can you build and try this extension locally and see if that resolves your problem?

[erik-wramner]

Yes, I'll give it a try.

[gastaldi]

I found out how to reproduce the issue in the test, it happens with OpenSSL keys only. I'll update it

[gastaldi]

@all-contributors add @erik-wramner for code

[allcontributors]

@gastaldi

I've put up a pull request to add @erik-wramner! 🎉

[erik-wramner]

@gastaldi I can confirm that the new version solves the issue when I build locally.

I have a question though. To make it work, I need to depend on quarkus-jsch-deployment. However, if I follow the installation docs and run mvnw quarkus:add-extension -Dextensions="io.quarkiverse.jsch:quarkus-jsch" the dependency becomes quarkus-jsch. That does not work (even with 999-SNAPSHOT).

Are the installation instructions wrong, so that the correct dependency is quarkus-jsch-deployment, or have I missed something?

[gastaldi]

The quarkus-jsch-deployment is resolved via the Quarkus extension Maven plugin and you don't need to explicitly add it (unless you're developing an extension)

[erik-wramner]

Hm, I thought so. Weird - but then perhaps the Maven plugin finds the released version, so I needed to depend on the deployment artifact explicitly to get 999-SNAPSHOT?

[gastaldi]

No, the resolver should pick from the local repository first. That sounds like a bug, we've been doing some changes in the Maven integration recently and I wonder if this is a new bug.

Can you open an issue in https://github.com/quarkusio/quarkus/issues with a small reproducer project?

[erik-wramner]

I'll see if it is reasonably easy to reproduce. My real project is complex with multiple Maven projects. Stripping it to a small reproducer is not trivial, but if the problem appears in a single Maven project I'll create an issue for it.

[erik-wramner]

@gastaldi I created a single-project reproducer, but it didn't have the problem. It (correctly) uses the local version without having to drag in the deployment project. It could be one of the many other dependencies that creates a conflict or it may be something with the multiple Maven projects. I could keep adding things, trying to make the example project even more like the real one, but given how long time a single build takes and how many variables there are to tweak I'm afraid I don't have the time.

[gastaldi]

@erik-wramner I've been trying to reproduce your use case and haven't seen it fail. Perhaps you could output the logs with mvn clean package -X? That would give you the -deployment artifacts being used by the Quarkus plugin

[erik-wramner]

I'd prefer not to upload the full trace to the world as it contains a bit too much that may be sensitive. However, I think this is where it goes wrong:

[DEBUG]    com.icecoresoft.connect:filetransfer-lib:jar:2.2-SNAPSHOT:compile
[DEBUG]       io.quarkiverse.jsch:quarkus-jsch:jar:3.0.1:compile (version managed from 999-SNAPSHOT)

For some reason it decides that the version from Quarkus BOM is better than the one in the pom file. I'll move things around a bit to see if I can find out why.

[gastaldi]

Funny, because this extension is not listed in the Quarkus BOM (none of the io.quarkiverse.* groupId are).

[erik-wramner]

Indeed, plus further down in the trace I get:

[DEBUG] [io.quarkus.bootstrap.resolver.maven.ApplicationDependencyTreeResolver] Injecting deployment dependency io.quarkiverse.jsch:quarkus-jsch-deployment:jar:999-SNAPSHOT
[DEBUG] [io.quarkus.bootstrap.classloading.QuarkusClassLoader] Adding elements io.quarkus.bootstrap.classloading.PathTreeClassPathElement[io.quarkiverse.jsch:quarkus-jsch-deployment / runtime=false resources=null] to QuarkusClassLoader Augmentation Class Loader: PROD

That looks correct. I'm building again with a few changes, perhaps Maven gets confused as the library is pulled in from two sub-projects.

[erik-wramner]

Actually, if you check the bom for 3.2.1 you'll find:

<dependency>
  <groupId>io.quarkiverse.jsch</groupId>
  <artifactId>quarkus-jsch-deployment</artifactId>
  <version>3.0.1</version>
</dependency>

[gastaldi]

Perhaps you already know, but it's important to mention that Maven resolves to the version that is nearest to the resolved dependency tree. Better use dependencyManagement in the parent pom and declare the version there just in case (although not required, declaring the -deployment there helps)

[gastaldi]

Actually, if you check the bom for 3.2.1 you'll find:

<dependency>
  <groupId>io.quarkiverse.jsch</groupId>
  <artifactId>quarkus-jsch-deployment</artifactId>
  <version>3.0.1</version>
</dependency>

Oh that's news to me, I was looking at https://github.com/quarkusio/quarkus/blob/main/bom/application/pom.xml but it looks like some preprocessing is run before the artifact is deployed

[erik-wramner]

Well, since the dependency is in the Quarkus BOM, it is already present in the parent's dependencyManagement section. If that is supposed to win, we have found the problem?

[gastaldi]

Right, so declaring the extension AND the deployment with the new version BEFORE the quarkus-bom should fix the problem.

You don't need to declare the -deployment as a dependency in your application though, only in dependencyManagement