<kares[m]>
there's more autoload + explicit require duplicity and we've hit the bug (with `Gem::Platform`) on the RGs CI
<headius[m]>
ok, seems like a good fix on their end in any case
<headius[m]>
I'll have a look at the patch tomorrow but I don't imagine there's any real issue incorporating it into 9.2.12
<headius[m]>
Benoit noticed some of the security specs are failing so I think we can quickly address those too. Almost all of them would be fixed by randomizing the seed for hashes, which I think we have code for but it's off by default
<headius[m]>
we had feature requests to make hashes predictable, funnily enough
<headius[m]>
so bit of patching tomorrow and then verification and release Tuesday or Wednesday
<headius[m]>
kares: if it isn't already, make a PR to get our RG in line with the patched 3.1 and we'll look it over
<headius[m]>
oh I want to cherry-pick that one fix for Java 14 too, I'll just do that now
<headius[m]>
the other one is probably a simple bug in how we coerce the path to require
ur5us has joined #jruby
<kares[m]>
think JRuby does `to_str` checked there, will take another look what changed in 3.1 RG's require method certainly has grown
<kares[m]>
* think JRuby does `to_str` checked there, will take another look what changed in 3.1 RG's require ... method certainly has grown
<kares[m]>
heh passing locally ...
<kares[m]>
well now with the full suite ... ruby:spec 🔨
<kares[m]>
* well not with the full suite ... ruby:spec 🔨
ur5us has quit [Ping timeout: 260 seconds]
nirvdrum has joined #jruby
<headius[m]>
of course the webrick security failures are because Ruby 2.6 reports the wrong webrick version it ships
<headius[m]>
I'm not even sure what version it ships, because they appear to have been patching it directly in the CRuby repository without releasing the gem at the same time
<headius[m]>
hopefully someone from CRuby can help us sort out what version they actually ship
<chrisseaton[m]>
In TruffleRuby we copy and paste from the version of MRI we're compatible with, rather than the downstream (upstream?) gem, for this reason.
<headius[m]>
yes, that's not acceptable to me
<headius[m]>
if they claim to be shipping 1.4.2, they should actually be shipping 1.4.2... and not just for us, users can't actually know what version of webrick is in CRuby right now
<headius[m]>
we also will not locally version sources that should be coming from a released gem, for exactly this reason: we should not lie about the version we ship either
<headius[m]>
if TruffleRuby is claiming to ship webrick 1.4.2, that's in error as well
<headius[m]>
took me a while to figure out why we fail this when we ship the same version of webrick that Ruby 2.6.6 claims to ship
<headius[m]>
for JRuby 9.2.12 I'll have to copy the source from CRuby 2.5.x, since it wasn't gemified then and there's probably no released version that matches
<headius[m]>
kares: deivid-rodriguez has a handle on the failures in pull
<kares[m]>
but than, for JRuby, I do not think we want to cherry-pick on top of the latest RGs release?
<headius[m]>
yeah I dunno... wasn't that your plan before?
<chrisseaton[m]>
Context for those specs in the first place was MRI were actually regressing on some of their own CVE fixes
<kares[m]>
yes it was to have one simple patch :)
<headius[m]>
ok I'm with ya
<headius[m]>
unfortunate that this is in flux right before a release
<headius[m]>
chrisseaton: 🙄
<kares[m]>
but yeah the patch is bigger + if they have any of those PR scheduled for next 3.1
<kares[m]>
* but yeah the patch is bigger + if they have any of those PRs scheduled for next 3.1
<headius[m]>
I never liked the randomization as a fix for hashDOS anyway
<chrisseaton[m]>
Like you're proposing, we have an option for deterministic hashing. We use it in some testing. Should probably turn it on for benchmarking...
<headius[m]>
we have that option already from a user's request in 2013... as well as an option to turn on the more robust siphash
<headius[m]>
but as far as we know perlhash is not susceptible to hash prediction, so we have not made siphash default
<headius[m]>
meh, I don't think I'm going to bother fixing this tainting security failure
<headius[m]>
nobody should trust tainting for anything ever
<headius[m]>
hmm I'm not sure why we even fail it... we do taint from the pack format string
<headius[m]>
oh I see
<headius[m]>
it needs to taint if any of the elements are tainted
<headius[m]>
meh
<headius[m]>
dead feature
<headius[m]>
the webrick fix does not appear to have been patched in Ruby 2.5.x
<headius[m]>
and it also reports that it ships 1.4.2