From: "Urabe, Shyouhei" Date: 2018-07-23T10:24:24+09:00 Subject: [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 wrote: > "Urabe, Shyouhei" 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/20180625134403.2B6DC43994575@oldenburg.str.redhat.com/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: