From: merch-redmine@... Date: 2018-07-17T02:23:01+00:00 Subject: [ruby-core:87964] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt Issue #14915 has been updated by jeremyevans0 (Jeremy Evans). shyouhei (Shyouhei Urabe) wrote: > I agree that crypt(3) is too difficult to use correctly. Properly avoiding traditional modes to generate adequate hash are up to users, which is not how we do security these days. OpenBSD splits the functionality into crypt_checkpass(3) and crypt_newhash(3), which are far better (meseems). > > Said that, Ruby's String#crypt has been there for a while and we should expect wild applications. You have to carefully watch your step for its removal. Definitely. I don't think we should remove String#crypt without deprecating it. It's mostly a question of how long the deprecation period should be. Maybe 1 year is too short. However, I think 10 years is definitely too long. > normalperson (Eric Wong) wrote: > > While I don't care for #crypt, I'd like to move some tiny exts > > like fiber, io/wait, io/nonblock directly into core; because > > DSOs increase memory usage and slow down startup: > > For String#crypt, because crypt(3) typically resides in libc, no extra DSO shall be necessary by theory. I think Eric means that if we move String#crypt to string/crypt, that's an extra string/crypt.so DSO you have to load if you use String#crypt. > How about call it from pure ruby (maybe using fiddle)? String#crypt can be easily emulated using fiddle if crypt is in libc: ~~~ ruby require 'fiddle' libc = Fiddle.dlopen('/path/to/libc.so') crypt = Fiddle::Function.new( libc['crypt'], [Fiddle::TYPE_VOIDP, Fiddle::TYPE_VOIDP], Fiddle::TYPE_VOIDP ) crypt.call('password', 'sl').to_s ~~~ It's more work if crypt_r is used, though. ---------------------------------------- Feature #14915: Deprecate String#crypt, move implementation to string/crypt https://bugs.ruby-lang.org/issues/14915#change-72971 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- This method is system and implementation dependent, and the portable usage mentioned in the documentation is not truly portable (doesn't work on OpenBSD) and insecure as it uses DES. For systems that lack a crypt(3) implementation, Ruby will happily substitute a version that only supports DES. It's 2018, using DES should be avoided if at all possible. The only internal usage of String#crypt in Ruby is in Webrick, where it uses DES for basic authentication with an htpasswd file. That could and should be changed to use a more secure hash by default (bcrypt since that's the most secure htpasswd format), or at least allow the user to customize Webrick's authentication. I expect there are few if any users actively using Webrick's htpasswd support. This moves the String#crypt implementation to the string/crypt extension, but leaves the String#crypt core method. The core method prints a deprecation warning, then loads the string/crypt extension. The string/crypt extension undefines the String#crypt core method, then defines the previous implementation. Because extensions use extconf.rb instead of configure for their configuration, this ports the related configure.ac code to extconf.rb. I'm not sure that is done correctly and works on all platforms, it will need testing. For systems that lack a crypt(3) implementation, this modifies the fallback code to only define crypt_r, since that is the only function that String#crypt will call in that case. While the patch just deprecates String#crypt, I think we should plan to remove support from ruby: 2.6: core method deprecated 2.7: core method removed, string/crypt extension ships with ruby 2.8: string/crypt extension moves to external gem, not shipped ---Files-------------------------------- 0001-Deprecate-String-crypt-move-implementation-to-string.patch (20.5 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: