[#87773] timer thread [was Re: [ruby-alerts:7905] failure alert on trunk-asserts@silicon-docker (NG (r63844))] — Eric Wong <normalperson@...>
> test_all <main>: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken
[#87836] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been reported by ko1 (Koichi Sasada).
ko1@atdot.net wrote:
On 2018/07/06 18:47, Eric Wong wrote:
[#87847] undefined symbol: mjit_init_p — Leam Hall <leamhall@...>
I pulled Ruby trunk on 3 Jul and am now getting errors similar to the
QXMgSSB0b2xkIHlvdSwgYG1ha2UgaW5zdGFsbGAgaXMgbmVlZGVkIHRvIG1ha2UgUnVieSB3b3Jr
T25lIG1vcmUgcmVhc29uIGZvciBodHRwczovL2J1Z3MucnVieS1sYW5nLm9yZy9pc3N1ZXMvMTM2
[#87986] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt — mame@...
Issue #14915 has been updated by mame (Yusuke Endoh).
mame@ruby-lang.org wrote:
normalperson (Eric Wong) wrote:
[#88088] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — normalperson@...
Issue #14937 has been reported by normalperson (Eric Wong).
[#88104] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been updated by ko1 (Koichi Sasada).
[#88173] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — Greg.mpls@...
Issue #14950 has been reported by MSP-Greg (Greg L).
[#88189] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — nobu@...
Issue #14950 has been updated by nobu (Nobuyoshi Nakada).
[#88199] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — takashikkbn@...
Issue #14937 has been updated by k0kubun (Takashi Kokubun).
takashikkbn@gmail.com wrote:
> yet, sky3 had a failure at
> http://ci.rvm.jp/results/trunk@P895/1173951
> > http://ci.rvm.jp/results/trunk@P895/1173951
[ruby-core:88000] Re: [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt
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.
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
So in short, the status quo is already broken. I recommend you
to add "adequate notice" ASAP.
> 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.
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.
3. Give up BasicAuth at all to migrate to DigestAuth. Requires
both developer-side and user-side to work on it.
On Wed, Jul 18, 2018 at 5:42 PM, Eric Wong <normalperson@yhbt.net> wrote:
> mame@ruby-lang.org wrote:
>> We first need to remove the usage of String#crypt from WEBrick. @normalperson, the maintainer of WEBrick, what do you think? Is it possible and acceptable? If it is not, we can't deprecate String#crpyt as long as WEBrick is bundled.
>> If normalperson agrees with the removal, we then ask @jeremyevans0 to release compatibility-layer gem by 2.6 release. If the release is succeeded, we can deprecate the core method, with a deprecation message like "String#crypt is deprecated; use `string-crypt' gem".
>> And finally, after @normalperson removed the dependency from WEBrick in any way, we will remove the core method, maybe in 3.x.
>
> 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.
>
> 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).
>
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>