You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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).
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.
Activity
mfazekas commentedon May 28, 2026
@headius thanks.
This is what llm said on the issue:
kares commentedon May 28, 2026
That would be great, currently kamal also directly depends on the gem but there's no direct usage of
BCryptPbkdffrom within the gem.headius commentedon May 29, 2026
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,
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 commentedon May 29, 2026
Agree.
kares commentedon May 29, 2026
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...
headius commentedon Jun 3, 2026
I reviewed @kares implementation and it looks good to me, modulo a couple minor review comments.
mfazekas commentedon Jun 27, 2026
1.2.0 beta released with java support: https://rubygems.org/gems/bcrypt_pbkdf/versions/1.2.0.beta1-java
headius commentedon Sep 29, 2026
The beta1 is working locally for me testing a simple sqlite scaffolded app on Rails 8.1.
I have included it in a
rails new -mtemplate here: https://github.com/jruby/rails_templates/blob/main/rails-8.1.rb