Avoid using the same digest across calls #697
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes jwt#696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez
Contributor
Author
|
Some variation of the script provided in #696 could probably be adapted as a test for the ECDSA part of the fix. I am not familiar enough with the libraries involved to know how to modify that script to test the RSA part of the fix. |
Contributor
Author
|
I've adapted the #696 example for an ECDSA test. |
Member
|
Looks solid @headius and thanks for the fix. If you would address the issues raised by the robot we are good to go. |
Member
|
Re-enabled the Truffleruby CI step in #698. I can confirm that the provided spec is indeed failing for that. |
Contributor
Author
|
I will fix the Rubocop issues and ping you when that's ready. I am curious... why no JRuby in the test matrix before? I'll add it, but it is troubling that it wasn't there to begin with. |
Contributor
Author
|
Well, I guess I answered my own question... there are just a few failures running on JRuby, and something that appears to hang. I will look into those separately from this PR (at some point). I've made the Rubocop changes and this should now be ready to go. |
anakinj
approved these changes
Jun 28, 2025
Member
|
Thanks for the fix @headius. The fix is included in the latest patch release. Cannot remember if there has been any specific reason there is no jruby in the CI matrix. If it's possible to get it there i'm all for it. |
anakinj
pushed a commit
to anakinj/ruby-jwt
that referenced
this pull request
Jun 29, 2025
* Avoid using the same digest across calls JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes jwt#696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez * Add jwt#697 to changelog * Modify Rsa digest name test for new structure The @digest instance variable now contains the name to the digest to be used. See jwt#697 * Add test for concurrent encode/decode using ECDSA This is adapted from the script in jwt#696 and provides a test for the ECDSA part of the fix in jwt#697. * Fixes for Rubocop
anakinj
pushed a commit
to anakinj/ruby-jwt
that referenced
this pull request
Jun 29, 2025
* Avoid using the same digest across calls JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes jwt#696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez * Add jwt#697 to changelog * Modify Rsa digest name test for new structure The @digest instance variable now contains the name to the digest to be used. See jwt#697 * Add test for concurrent encode/decode using ECDSA This is adapted from the script in jwt#696 and provides a test for the ECDSA part of the fix in jwt#697. * Fixes for Rubocop
anakinj
pushed a commit
to anakinj/ruby-jwt
that referenced
this pull request
Jun 29, 2025
* Avoid using the same digest across calls JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes jwt#696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez * Add jwt#697 to changelog * Modify Rsa digest name test for new structure The @digest instance variable now contains the name to the digest to be used. See jwt#697 * Add test for concurrent encode/decode using ECDSA This is adapted from the script in jwt#696 and provides a test for the ECDSA part of the fix in jwt#697. * Fixes for Rubocop
2 tasks
anakinj
pushed a commit
to anakinj/ruby-jwt
that referenced
this pull request
Jun 29, 2025
* Avoid using the same digest across calls JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes jwt#696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez * Add jwt#697 to changelog * Modify Rsa digest name test for new structure The @digest instance variable now contains the name to the digest to be used. See jwt#697 * Add test for concurrent encode/decode using ECDSA This is adapted from the script in jwt#696 and provides a test for the ECDSA part of the fix in jwt#697. * Fixes for Rubocop
anakinj
pushed a commit
to anakinj/ruby-jwt
that referenced
this pull request
Jun 29, 2025
* Avoid using the same digest across calls JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes jwt#696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez * Add jwt#697 to changelog * Modify Rsa digest name test for new structure The @digest instance variable now contains the name to the digest to be used. See jwt#697 * Add test for concurrent encode/decode using ECDSA This is adapted from the script in jwt#696 and provides a test for the ECDSA part of the fix in jwt#697. * Fixes for Rubocop
anakinj
pushed a commit
to anakinj/ruby-jwt
that referenced
this pull request
Jun 29, 2025
* Avoid using the same digest across calls JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes jwt#696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez * Add jwt#697 to changelog * Modify Rsa digest name test for new structure The @digest instance variable now contains the name to the digest to be used. See jwt#697 * Add test for concurrent encode/decode using ECDSA This is adapted from the script in jwt#696 and provides a test for the ECDSA part of the fix in jwt#697. * Fixes for Rubocop
anakinj
added a commit
that referenced
this pull request
Jun 29, 2025
Avoid using the same digest across calls (#697) * Avoid using the same digest across calls JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads. This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue. Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest. The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock. Fixes #696 Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez * Add #697 to changelog * Modify Rsa digest name test for new structure The @digest instance variable now contains the name to the digest to be used. See #697 * Add test for concurrent encode/decode using ECDSA This is adapted from the script in #696 and provides a test for the ECDSA part of the fix in #697. * Fixes for Rubocop Co-authored-by: Charles Oliver Nutter <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
JWT appears to reuse these JWA instances across threads, which can lead to them stepping on each other via the shared OpenSSL::Digest instance. This causes decoding to fail verification, likely because the digest contains an amalgam of data from the different threads.
This patch creates a new OpenSSL::Digest for each use, avoiding the threading issue.
Note that the HMAC JWA already calls OpenSSL::HMAC.digest, avoiding the shared state, and the others do not use digest.
The original code does not fail on CRuby most likely because only one thread at a time can be calculating a digest against a given OpenSSL::Digest instance, due to the VM lock.
Fixes #696
Addresses the issue reported in jruby/jruby#8504 by @mohamedhafez
Checklist
Before the PR can be merged be sure the following are checked: