Update v8 version

[rahulchaphalkar]

Title: Updating v8 requires uploading static snapshot at https://storage.googleapis.com/envoyproxy-wee8/v8-{version}.tar.gz ?

Description:
The only way to update v8 is to have the relevant version's snapshot at the above bucket, is that right?
I was hoping to update to v8's main branch until the next release is available, as discussed here, but looks like that is not possible.

[alyssawilk]

cc @mpwarres @lizan @phlax

[phlax]

The only way to update v8 is to have the relevant version's snapshot at the above bucket, is that right?

i think yes - its not an ideal situation - but i think that is how it is currently setup

[phlax]

cc @PiotrSikora

[mpwarres]

I can upload a new static snapshot, but would like to get clarification: is the proposal that we have Envoy use a version of v8 that is not an official release? How long would it be until the upstream v8 change is available in a standard release?

[PiotrSikora]

I can upload a new static snapshot, but would like to get clarification: is the proposal that we have Envoy use a version of v8 that is not an official release? How long would it be until the upstream v8 change is available in a standard release?

The reason for snapshots is that Gitiles used on *.googlesource.com properties doesn't create deterministic tarballs (see: google/gitiles#84), so we need to store downloaded artifacts somewhere to avoid checksum mismatch.

There are no changes between those tarballs and the upstream (see: https://storage.googleapis.com/envoyproxy-wee8/wee8-fetch-deps.sh).

[mpwarres]

@rahulchaphalkar what is the specific version tag of v8 that you need the dependency updated to?

[rahulchaphalkar]

Thanks for the details.
@mpwarres I was hoping to use v8 commit cc49dce9f5cb14daee8cc0946e996ba999f97d29 till a newer release of v8 is available, at which point we can switch to that release.
Looking at repository_locations.bzl and wee8-fetch-deps.sh, it seems perhaps other dependencies like base_trace_event, icu, zlib etc. might need to be updated in repository_locations.bzl if v8 is updated? I can do that if required.

[PiotrSikora]

Using a random commit from the mainline branch of V8 in a production software in order to add support for a niche and bleeding edge feature is definitely something that I'd object to in principle (but that's @mpwarres's role now).

Even more so, because V8 is not safe / stable on their main branch, which is used for active development with a lot reverts and no security updates... Even the commit you referenced was originally reverted and only relanded last week.

Having said that, it looks that it's a tiny change, so if there are no other code dependencies, then I'd recommend cherry-picking that change and carrying it in bazel/v8.patch until it ships in a stable release of V8.

Also, it looks that V8 wasn't updated since October 2022, and there was plenty of CVEs and 0-days in V8 since then, so it should be updated to the latest stable release... Note that those CVEs are published with cpe:2.3:a:google:chrome:* and not cpe:2.3:a:google:v8:*, so perhaps it's worth updating the CVE scanner to account for that, since it would need to map Chrome versions to V8 versions (see: https://omahaproxy.appspot.com/ or the existing instructions about extracting BoringSSL version from Chromium's DEPS file). cc @phlax

[phlax]

thanks @PiotrSikora - ill take a look at that presently

[phlax]

@mpwarres as a first step can we update v8 to the latest stable - given above info we possibly also want to backport the update to the other stable branches

[rahulchaphalkar]

Thanks @PiotrSikora for the feedback.
I did start with bazel/v8.patch, but it was recommended to upstream that to v8 and use the merged (main, LKGR) commit in the interim till a new release is available. (Reference)
It was my understanding that reverts/instability mostly affects tip of main, but rarely LKGR since all ci tests need to be completed and passed for LKGR unlike main.

Seems like there are 3 options -

• Add the main/LKGR branch commit for now, switch to release when available (cons - Security/stability concerns)
• Add bazel/v8.patch for now, switch to release when available (cons - maintainability/ security updates concerns)
• Wait until new v8 release is available for the PR to merge (cons - feature not available in the interim)

Happy to implement any of these based on the feedback here.
FYI @htuch