Issue #14915 has been updated by shevegen (Robert A. Heiler).


I have not read all comments (sorry) and it is way outside of my league to come to any meaningful
conclusion. However had, this functionality could become a gem, and put onto e. g. rubygems.org,
could it not? Then people who need it could install it; we had moved ncurses or curses into a gem
too.

> But I give up caring for backwards compatibility (as far as Ruby goes).
> Easier for me to stop using the language :P

Personally I am not affected by the change either way (I don't think I ever used either the
specific webrick functionality or String#crypt myself), but if it is a gem that can be
installed, it should not be a problem? I think the amount of people affected may be small,
and they could only be affected if they actively upgrade to a ruby version that may have
the deprecation/removed variant, which I guess will take a long time - and if that is the
case, they could use that gem? I am a bit confused about the comment even though there is
the tongue-in-cheek symbol. Unless I have missed it, other gems existed that allowed for
this. Take the syck gem; it is maintained in the sense that incompatible changes may
be added to it (possibly). I used it for a very long time but finally made the switch
into unicode. I think I used the syck gem ever since ruby 1.9.x.

I am not completely sure why this should not be possible for the functionality here.

By the way, if memory footprint, DSO size etc... is a concern, isn't that what ultimately
mruby could solve? E. g. if we would have a super-modular, super-small ruby that could
also be used as base for MRI eventually. (Well, just thinking here in principle ... I
guess there is a lot of work to be done either way.)

----------------------------------------
Feature #14915: Deprecate String#crypt
https://bugs.ruby-lang.org/issues/14915#change-78093

* 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)
0001-Deprecate-String-crypt.patch (7.48 KB)
0001-Deprecate-String-crypt.patch (7.35 KB)
0001-Deprecate-String-crypt.patch (7.43 KB)
deprecate-string-crypt.patch (6.7 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>