-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgraded jBCrypt to v0.4 #1942
Upgraded jBCrypt to v0.4 #1942
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2.6 only has tags right now, but we can spin up a branch straightforwardly. We'll also need to backport this to 3.0, 3.1, and 3.2... Thanks for busting it out so fast!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is removing a public API in the net.liftweb
namespace. I'm 200% for removing net.liftweb.util.BCrypt
, but we should reimplement it as a proxy for the actual BCrypt implementation until 4.0, mark all the public methods as deprecated, and then actually remove it in 4.0. :/
Whoops, let's not approve dropping a public API 🙊
We can't nuke that BCrypt class as it is public API in the net.liftweb.util package. We introduce a deprecated class that passes through both docs and public methods calls to org.mindrot.jbcrypt.BCrypt.
Added #1945 to put the public API back in as a deprecated pass-through. |
Bridges of BCrypt: Reintroduce pass-through deprecated net.liftweb.util.BCrypt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
💯 merging. We need to coordinate point releases of our various branches, as well. |
1 similar comment
💯 merging. We need to coordinate point releases of our various branches, as well. |
Fixes #1941
I did confirm that the copy we had was the same as the previously published 0.3 version.
I didn't test this against any apps as I'm not using either of the fields anywhere. However, this jar was published 3 years ago, so I think it's probably safe to use.
Lastly, we should probably publish a 2.6.4 version, but I don't see a branch on Github for 2.6 anywhere and wasn't sure how to go about backporting.