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


mame (Yusuke Endoh) wrote:
> I agree with deprecation and removal of String#crypt.  If it were not included in the core, and if it were proposed today, the proposal would be definitely rejected as "it should be implemented as a gem".
> 
> > 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.
> 
> It looks complex a bit to me, and I don't see its advantage.  How about:
> 
> 2.6: core method deprecated, and a compatibility-layer gem released
> 3.0?: core method removed

The advantage of having the core method require the extension (either shipped with ruby or an external gem) is that you get the same behavior.  If the extension has different behavior than the core method, because configure feature detection is different than extconf.rb feature detection, it's going to be hard to debug, especially with so few users of this code.

That being said, I'm fine with just deprecating the core method, shipping an external gem, and removing the core method in 3.0.

> Unfortunately, the name "crypt" is [already taken](https://rubygems.org/gems/crypt), though...

"string-crypt" is not taken, which is the reason I named the extension "string/crypt".

> Incidentally, I found some usages of String#crypt in some gems.
> 
> https://github.com/eventmachine/eventmachine/blob/537127fa22a058e3d7b248a214df210e7c77dc95/lib/em/protocols/postgres3.rb#L187

The last PostgreSQL version that supported crypt passwords was 8.3, which stopped being supported over 5 years ago (PostgreSQL removed support for crypt passwords in 8.4, and no longer supports <9.3).  You would have to be connecting to a pre-8.4 server for it to be possible to connect with crypt passwords, and even in old PostgreSQL versions they recommended against crypt passwords, stating "crypt to be used only if you must support pre-7.2 clients".

I think it's safe to say nobody is executing that code and would notice if it broke.

> https://github.com/activeldap/activeldap/blob/a63e89c384cf7f5bb95451a3749e6dc4aa799969/lib/active_ldap/user_password.rb#L38

This gem depends on ~10 other gems if you count transitive dependencies, some heavy weight such as activemodel, and is actively maintained by a ruby committer.  I'm guessing kou wouldn't have a problem depending on another gem for the crypt support, but I don't want to speak for him.

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

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