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

On Fri, Jul 20, 2018 at 5:51 PM, Eric Wong <[e-mail]> wrote:
> "Urabe, Shyouhei" <[e-mail]> wrote:
>> normalperson (Eric Wong) wrote:
>> >  It's only the BasicAuth code and I have no idea how many people
>> >  use it; probably not many, but I don't want to break a single
>> >  user setup without adequate notice.
>>
>> Understand your concern.  The problem is, String#crypt is a thin
>> wrapper of crypt(3) whose behaviour is not under our control.  It
>> might change from time to time.
>
> OK, then we can refer users to their operating system
> documentation when it breaks.  In other words, we can shift
> responsibility for breakage over to whoever provides crypt(3)
> for their system.
>
> What we should do now is try to educate users to avoid crypt(3)
> before they start using it.
>
> However, if users already depend on it, lets not break their use
> case before their operating system breaks it for them.
>
> Again, if system (libc) breaks something, there's nothing we can
> do.  However, lets not prematurely break things; but try to warn
> and educate users to avoid future breakage.

Makes sense to me.

> Btw, glibc is considering such a shift to using 3rd-party libcrypt:
>
> https://public-inbox.org/libc-alpha/[e-mail]/t/#u
>
>> Looking at the current implementation of
>> webrick/httpauth/basicuath.rb, The usage of String#crypt silently
>> expects that crypt(3) acts in traditional (== DES) mode.  This
>> mode has been dropped in OpenBSD for years.  It now expects some
>> fixed-format string as its argument.  See also:
>> https://man.openbsd.org/crypt.3
>> https://man.openbsd.org/crypt.3
>>
>> So in short, the status quo is already broken.  I recommend you
>> to add "adequate notice" ASAP.
>
> See proposed patch below.

OK, the patch seems fine.

>> >  Even if BasicAuth is broken/removed/requires-extra-download,
>> >  most WEBrick can use the rest without difficulty.
>> >
>> >  WEBrick has several other authentication methods; which one do
>> >  we recommend users migrate to?  I am not an expert in this area
>> >  (I don't like authentication at all).
>>
>> There are two separate issues I think.
>>
>>   - Basic authentication itself does not require DES.  It is an
>>     implementation detail.  You can safely migrate to another
>>     hash function at will.  Ruby's openssl library has for
>>     instance OpenSSL::KDF.scrypt().
>>
>>   - On the other hand, WEBrick now supports .htpasswd file, which
>>     contain DES hash strings.  This does not interface with other
>>     hash functions.
>>
>> There are three possible solutions for this situation I think:
>>
>>  1. Keep supporting DES-formatted .htpasswd file.  In order to do
>>     so you arguably need your own DES implementation, given
>>     OpenBSD lacks one.
>
> Nope, too much work to support broken behavior.
>
>>  2. Give up DES, but contiue supporting BasicAuth in different
>>     hasing function (maybe using OpenSSL library).  This requires
>>     user-side migration of existing .htpasswd files into some new
>>     format, but nothing more.
>
> Maybe, as Jeremy proposed in [ruby-core:88002].  But does it
> make sense to add more options instead of telling people to use
> existing options (perhaps DigestAuth)?
>
> Both require work on the user-side to reconfigure, so I'd rather
> we tell them to use an existing functionality rather than new
> option (easier for people on older Ruby or webrick versions).
>
>>  3. Give up BasicAuth at all to migrate to DigestAuth.  Requires
>>     both developer-side and user-side to work on it.
>
> Why is there need for developer-side work on it? (aside from
> documentation change)

Maybe this was my misunderstanding.  Are BasicAuth and DigestAuth
made API-compatible? If that is the case what developers should
do might be just replacing BasicAuth to DigestAuth, and Htpasswd
to Htdigest.

> Anyways, 3. seems ideal, we can slowly let users deal with it.
> Anybody who complains when crypt(3) breaks, we can tell them
> "we told you so" once we make documentation updates:

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