JRuby support needed for Rails (via Kamal)

[headius]

This gem is a dependency of kamal, which is used by default in new Rails applications 8.0 and higher (possibly others). Because bcrypt_pbkdf has its own native extension, this prevents bundling a fresh Rails app.

The workaround is to specify --skip-kamal for now, but we would like to see JRuby support for bcrypt_pbkdf and are here to help make that happen!

If I'm understanding things correctly, it looks like PBKDF2 is included in standard Java crypto features, as described here:

https://mojoauth.com/hashing/pbkdf2-in-java#advantages-and-disadvantages-of-pbkdf2

This means we can either have a very small JRuby extension or just call these classes from a piece of Ruby code. We would still need a -java platform gem for bcrypt_pbkdf that avoids building the C extension.

[mfazekas]

@headius thanks.

This is what llm said on the issue:

Note that bcrypt_pbkdf is not standard PBKDF2 — it's OpenBSD's custom variant using bcrypt as the PRF, so Java's built-in PBKDF2WithHmacSHA256 won't produce compatible output. A dedicated implementation would be needed, though compatible ISC-licensed Java implementations exist (e.g., Apache MINA SSHD's BCrypt.java).

That said, the more impactful fix is on the net-ssh side (see net-ssh/net-ssh#914): our OpenSSH key loader is currently gated behind ed25519+bcrypt_pbkdf even for RSA/ECDSA keys. We shouldmake bcrypt_pbkdf a lazy dependency — only required when the key is actually encrypted. That would unblock JRuby for the common case (passphrase-less keys).

[kares]

That would be great, currently kamal also directly depends on the gem but there's no direct usage of BCryptPbkdf from within the gem.

[headius]

Your LLM's clarification of the differences is interesting. Indeed we can use a different implementation or port the code as alternatives to the pbkdf2 provided by OpenJDK.

However,

That said, the more impactful fix is on the net-ssh side

This is clearly false, since it does not address the use of this gem as a direct dependency in other libraries like Kamal.

Making this a lazy dependency everywhere that it is a direct dependency might help in the short term but it is not a practical general-purpose or "the most impactful" fix. We still need to have an alternate form that runs on JRuby so that this library works when it is actually needed.

[mfazekas]

That said, the more impactful fix is on the net-ssh side

This is clearly false, since it does not address the use of this gem as a direct dependency in other libraries like Kamal.

Agree.

[kares]

Szia Miklos, again. 👋

Made a try with generating the Java parts based on current C sources: #30

Understand that there's now extra stuff to maintain, hopefully the sources aren't changing much, let us know what you think...