Closed joshbuker closed 3 years ago
It's been said on many occasions at this point that I won't be taking large, breaking-changes PRs. Whilst I agree that the potential for API misuse is worth fixing, I don't agree with framing that as a vulnerability or using that to push such a PR.
I've made a two line change (+tests) that makes this go away.
It's been said on many occasions at this point that I won't be taking large, breaking-changes PRs. Whilst I agree that the potential for API misuse is worth fixing, I don't agree with framing that as a vulnerability or using that to push such a PR.
I've made a two line change (+tests) that makes this go away.
Unchanging code is neither secure nor maintainable in the long term. The whole point of major versions in semver is to support breaking changes when necessary, and I have yet to see any reasons that the existing api flow is beneficial or preferable in any way. That, and the changes suggested are incredibly easy to account for downstream.
This is about as small as a breaking change as possible, and it directly benefits developers both by reducing complexity, and better following object-oriented design.
@technion can you explain your position behind why Argon2::Password.new
should represent configuration details? The class name suggests that it's for generating/reading Argon2 Passwords, not configuration information. Likewise, the helpers also tell the same story.
I disagree with an assertion that constant API changes benefit developers benefits security, and I've spent more time debating that than I'm comfortable.
Closes #50
This introduces breaking changes that will require a major version bump.