[ruby-core:87962] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt

Issue #14915 has been updated by jeremyevans0 (Jeremy Evans).


normalperson (Eric Wong) wrote:
> [e-mail] wrote:
>  > 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.
>  
>  More exts increase build and maintenance time.  Right now, the
>  easiest and safest step would be to only deprecate it, but
>  keep it in core.

I agree that would be easiest and safest. However, at some point it should be moved out, and I think it's better to start that process early.

>  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:
>  
>  	https://udrepper.livejournal.com/8790.html

Note that DSOs only increase memory usage and slow down startup if they are actually used.  This would increase memory usage and slow down startup for users of String#crypt.  However, this would decrease memory usage and speed up startup for the 99.9%+ of ruby users that do not use String#crypt, since it would result in a smaller libruby.

FWIW, I'm fine including fiber, io/wait, and io/nonblock directly in core, because those extensions are small and the functionality they provide is useful in a large number of situations.

>  > 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
>  
>  Way too fast.  I agree with deprecation, but any removal should
>  take long-term distro release cycles (5-10 years) into account.

That's fine.  In the patch I don't specify it will be removed, just that it is deprecated.

Note that not removing String#crypt also has risks.  Mainly it risks unsuspecting users using it without understanding that doesn't really provide security.  I think we are doing a disservice to those users by basically promoting an insecure approach.  Most code that would be broken by the removal of String#crypt is insecure and should probably be updated.

----------------------------------------
Feature #14915: Deprecate String#crypt, move implementation to string/crypt
https://bugs.ruby-lang.org/issues/14915#change-72969

* 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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>