see #42, which I didn't notice until after I did this.

Also, this is breaking on a build on ruby-head - don't know if that's my fault

(Bumping for CI)

As I said in #43, I don't think this buys us anything, but I'll let @tjschuck decide since he is the current maintainer.

It buys nothing except "we're following best practices," which is in itself valuable.

another +1

👍 from me too

It is described in #43 why it is not necessary in this case. Has anything changed since then?

@codahale

bcrypt's preimage resistance makes timing attacks a non-issue here.

Bcrypt has preimage resistance according to known methods. Science is a process and remember md5 was state of the art and invulnerable at some time. This extra safety precaution causes no practical performance hit, but increases security by a significant amount. Dismissing this best practice is simply naive as it exists for a reason.

There is really no practical argument here, not to include this. The negligible performance decrease is not worth the security decrease.

I’m not sure why you saw fit to resurrect a decade-old issue and specifically tag me but here we go.

1. I don’t have commit access to this repo and couldn’t merge this even if I wanted to.
2. I’m not a maintainer for this project and haven’t committed to it since 2009.
3. I haven’t worked with Ruby for more than a decade.
4. Even if I were the person you needed to convince, your argument is not convincing.

Leave me alone.

Closing in favor of #282. @glittershark I cherry-picked your commit in to #282 then added some trivial performance related stuff (specifically just avoiding array allocations).