Fix tests for String#crypt so they pass on OpenBSD
The String#crypt documentation states "the format and the result
are system and implementation dependent", so the tests should not
be checking for specific results. We should only be checking that
the method returns a string, that the results are different
if you use a different password or different salt, and the results
are the same if the using the encypted password as the salt
results in the same encrypted password.
Updated by mame (Yusuke Endoh) over 4 years ago
Do the tests cause any actual issue? Failed on OpenBSD?
Ruby's tests are not conformance test. They should include a test of implementation-defined behavior and it is actually useful to detect an unintentional change of behavior.
Yusuke Endoh firstname.lastname@example.org
Updated by jeremyevans0 (Jeremy Evans) over 4 years ago
Well, the tests fail on OpenBSD regardless of the patch, as OpenBSD crypt(3) does not support the historical, insecure DES-based crypt, only bcrypt, and you need to pass a bcrypt salt as the second argument. I will be adding a local patch to OpenBSD so that passing a non-bcrypt salt to
String#crypt will result in a bcrypt salt being autogenerated, so that portable ruby programs using
String#crypt will run on OpenBSD. I don't think that patch belongs in ruby.
I think this patch improves things as it allows implementations to choose how to implement crypt(3), as long as they their crypt has the property:
enc = "pass".crypt("salt") enc == "pass".crypt(enc)
This isn't a big deal, I'm fine keeping this as a local OpenBSD patch, but I think it makes sense to have this in ruby. If you disagree, feel free to close this issue.
Updated by jeremyevans0 (Jeremy Evans) 8 months ago
- Subject changed from Fix tests for String#crypt to Fix tests for String#crypt so they pass on OpenBSD
I've added a GitHub pull request to fix the
String#crypt tests on OpenBSD (https://github.com/ruby/ruby/pull/2200). It's less invasive than the previous patch, and should result in the same behavior on !OpenBSD. I plan on merging it after I can do some testing on Linux, assuming there are no objections.