Fix compatibility with psych 4.0

[poloka]

Add psych 4.0 compatibility fix that fixes #322 .

[poloka]

@SamSaffron any support for this change? Would like patches pushed back all the way to the 3.x pipeline.

[SamSaffron]

This looks fine to me... @lloeki I am going to merge this... feel free to do backport prs as well.

[lloeki]

@poloka may I ask what is the dependency that you depend on that makes you depend on libv8? Is it therubyracer? If so what is depending on therubyracer?

IOW what, if anything, is precluding a move to mini_racer?

[mitorez]

@lloeki For me, and I believe similarly for @poloka, it's a deprecated internal dependency that depends on therubyracer that we cannot migrate off of yet because of time constraints.

[poloka]

@mitorez you are correct. We have an internal dependency that we do not have control of right now that depends on therubyracer that pulls in the 3.x series of libv8.

[SamSaffron]

therubyracer is incredibly high risk at this point in time... there are so many unpatched CVEs in ancient versions of v8...

[poloka]

Don't disagree. We need to get off it.

[poloka]

@SamSaffron @lloeki is it possible to get this released in a patch back to the 3.x? If wiki instructions were updated on how to build this locally, test, and then how to release I'd be open to tagging the releases. I attempted to pull the latest and build and I must be missing something because I cannot get it working locally on my M1 mac. Looks like travis CI is no longer building this project.

[lloeki]

I'll hack something.

[mitorez]

I'll hack something.

Thank you very much, @lloeki! If the version number could be something like 3.16.14.xx (e.g.; 3.16.14.20) that would be great, since that would allow the latest version of therubyracer to pick it up without it being rebuilt as well.

[lloeki]

If wiki instructions were updated on how to build this locally, test, and then how to release

TBH it's pointless, not the least because this libv8 version is extremely old and insecure.

I cannot get it working locally on my M1 Mac

You're not missing anything, this version of libv8 is outstandingly outdated and has issues with recent compiler and environments, even on Intel. It just does not support arm64-darwin, I'm not even sure it properly supports aarch64-linux, if at all; even if it produces an Intel build it is not amenable to reliably run under Rosetta 2. Attempting to reliably have it do a consistent Intel build on M1 through Rosetta is an exercise in frustration.

Looks like travis CI is no longer building this project.

Cue the above: running unreliable jobs on CI achieves very little in comparison to the effort of moving CIs, even more so for an outdated project.

it's a deprecated internal dependency that depends on therubyracer that we cannot migrate off of yet because of time constraints.

I can understand the realities of development - hence why I'll hack something, out of pure goodwill - and I certainly don't want to sound judgemental. That said, relying on such an old version of v8 and conversely on therubyracer, which cannot be upgraded to later v8 versions without extreme amounts of work, is a serious liability and a migration should have been considered with increasingly high priority as time has passed.

From CI to up-to-date v8, mini_racer's raison d'être is to tackle these issues, which is a hard-enough task in and of itself, so within the bounds of the time we can allocate to rubyjs that's where our focus is.

@SamSaffron WDYT about putting out a notice on the README of libv8 and therubyracer highlighting the status of both, with a recommendation to move to mini_racer+libv8-node?

[mitorez]

@lloeki Completely agree with everything you stated above^

Poor planning on our part does not necessitate an emergency on yours.

If you're able to hack something together, it would be very much appreciated. If you're not able to for whatever reason, that's totally understandable. I understand these projects are EOL, even if that's not explicitly stated - so any help we receive from you, we know it's above and beyond.

We are getting off our deprecated internal dependency as well as these, but unfortunately it's a large effort and that time frame doesn't lineup with the new internal push to update to Ruby 3.2, which is the only reason we were looking at this patch/hack. TMI...

Thank you again for your time looking into this issue.

[lloeki]

Hacked using good old unpack_gem and pack_gem:

curl -O https://rubygems.org/downloads/libv8-8.4.255.0.gem
curl -O https://rubygems.org/downloads/libv8-8.4.255.0-x86_64-linux.gem
curl -O https://rubygems.org/downloads/libv8-8.4.255.0-x86_64-darwin-20.gem
curl -O https://rubygems.org/downloads/libv8-8.4.255.0-universal-darwin-20.gem

unpack_gem libv8-8.4.255.0.gem
unpack_gem libv8-8.4.255.0-x86_64-linux.gem
unpack_gem libv8-8.4.255.0-x86_64-darwin-20.gem
unpack_gem libv8-8.4.255.0-universal-darwin-20.gem

cat > patch.sh <<'EOF' && chmod +x patch.sh
#!/usr/bin/env bash

set -e
set -u
set -o pipefail

test -f 3cb539da6b3d850dc1ec15e168a744d18ff3d35a.patch || curl -O https://github.com/rubyjs/libv8/commit/3cb539da6b3d850dc1ec15e168a744d18ff3d35a.patch

dir="$1"

cd "${dir}/data"
patch -p1 < ../../3cb539da6b3d850dc1ec15e168a744d18ff3d35a.patch
cd ..

perl -p -i -e 's/platform: (.+)-darwin-20/platform: \1-darwin/' metadata
perl -p -i -e 's/version: 8\.4\.255\.0/version: 8.4.255.0.1/' metadata
perl -p -i -e 's/VERSION = "8\.4\.255\.0"/VERSION = "8.4.255.0.1"/' data/lib/libv8/version.rb
EOF

./patch.sh libv8-8.4.255.0
./patch.sh libv8-8.4.255.0-x86_64-linux
./patch.sh libv8-8.4.255.0-x86_64-darwin-20
./patch.sh libv8-8.4.255.0-universal-darwin-20

mv -v libv8-8.4.255.0 libv8-8.4.255.0.1
mv -v libv8-8.4.255.0-x86_64-linux libv8-8.4.255.0.1-x86_64-linux
mv -v libv8-8.4.255.0-x86_64-darwin-20 libv8-8.4.255.0.1-x86_64-darwin
mv -v libv8-8.4.255.0-universal-darwin-20 libv8-8.4.255.0.1-universal-darwin

pack_gem libv8-8.4.255.0.1
pack_gem libv8-8.4.255.0.1-x86_64-linux
pack_gem libv8-8.4.255.0.1-x86_64-darwin
pack_gem libv8-8.4.255.0.1-universal-darwin

[lloeki]

For 3.16.14.19:

platforms=(
  '-arm-linux'
  '-x86-linux'
  '-amd64-freebsd-10'
  '-amd64-freebsd-11'
  '-x86_64-linux'
  '-armv7l-linux'
  '-x86_64-darwin-18'
  '-universal-darwin-17'
  ''
)

for platform in "${platforms[@]}"; do
    url="https://rubygems.org/downloads/libv8-3.16.14.19${platform}.gem"
    curl -O "${url}"
done

for platform in "${platforms[@]}"; do
    unpack_gem "libv8-3.16.14.19${platform}.gem"
done

cat > patch.sh <<'EOF' && chmod +x patch.sh
#!/usr/bin/env bash

set -e
set -u
set -o pipefail

test -f 3cb539da6b3d850dc1ec15e168a744d18ff3d35a.patch || curl -O https://github.com/rubyjs/libv8/commit/3cb539da6b3d850dc1ec15e168a744d18ff3d35a.patch

dir="$1"

cd "${dir}/data"
patch -p1 < ../../3cb539da6b3d850dc1ec15e168a744d18ff3d35a.patch
cd ..

perl -p -i -e 's/platform: (.+)-darwin-\d+/platform: \1-darwin/' metadata
perl -p -i -e 's/version: 3\.16\.14\.19/version: 3.16.14.19.1/' metadata
perl -p -i -e 's/VERSION = "3\.16\.14\.19"/VERSION = "3.16.14.19.1"/' data/lib/libv8/version.rb
EOF

for platform in "${platforms[@]}"; do
    ./patch.sh "libv8-3.16.14.19${platform}"
done

for platform in "${platforms[@]}"; do
    cat "libv8-3.16.14.19${platform}"/metadata | grep platform:
    cat "libv8-3.16.14.19${platform}"/metadata | grep '^  version:'
    cat "libv8-3.16.14.19${platform}"/data/lib/libv8/version.rb | grep VERSION
    cat "libv8-3.16.14.19${platform}"/data/ext/libv8/location.rb | grep safe_load
done

for platform in "${platforms[@]}"; do
    new_platform="$(cat "libv8-3.16.14.19${platform}"/metadata | perl -ne '/platform: (.*)$/ and print "$1\n"')"
    if [[ "${new_platform}" != "ruby" && "libv8-3.16.14.19${platform}" != "libv8-3.16.14.19-${new_platform}" ]]; then
        echo "${platform#-} -> ${new_platform}"
        mv "libv8-3.16.14.19${platform}" "libv8-3.16.14.19.1-${new_platform}"

        pack_gem "libv8-3.16.14.19.1-${new_platform}"
    else
        mv "libv8-3.16.14.19${platform}" "libv8-3.16.14.19.1${platform}"
        pack_gem "libv8-3.16.14.19.1${platform}"
    fi
done

Tested using:

docker run --platform linux/x86_64 --rm -it -v "${PWD}":"${PWD}" -w "${PWD}" ruby:2.4 /bin/bash
docker run --platform linux/x86_64 --rm -it -v "${PWD}":"${PWD}" -w "${PWD}" ruby:3.2 /bin/bash

gem install libv8-3.16.14.19.1-x86_64-linux.gem
gem install therubyracer
ruby -e 'require "v8; puts V8::Context.new.eval("6 * 7")'

[lloeki]

Pushed a bunch of things:

Successfully registered gem: libv8 (3.16.14.19.1)
Successfully registered gem: libv8 (3.16.14.19.1-amd64-freebsd-10)
Successfully registered gem: libv8 (3.16.14.19.1-amd64-freebsd-11)
Successfully registered gem: libv8 (3.16.14.19.1-arm-linux)
Successfully registered gem: libv8 (3.16.14.19.1-armv7l-linux)
Successfully registered gem: libv8 (3.16.14.19.1-universal-darwin)
Successfully registered gem: libv8 (3.16.14.19.1-x86-linux)
Successfully registered gem: libv8 (3.16.14.19.1-x86_64-darwin)
Successfully registered gem: libv8 (3.16.14.19.1-x86_64-linux)

Successfully registered gem: libv8 (8.4.255.0.1)
Successfully registered gem: libv8 (8.4.255.0.1-universal-darwin)
Successfully registered gem: libv8 (8.4.255.0.1-x86_64-darwin)
Successfully registered gem: libv8 (8.4.255.0.1-x86_64-linux)

I dropped the darwin version from the platform so that people stop complaining about it being unavailable every year.