Integrity checks for R2 migration

TL:DR;

We will change the way we serve the binaries, so we want to ensure that the binaries are properly migrated. Additionally, we can take this opportunity to have some scripts (potentially GH actions) that we can use to check if the binaries are fine and the releases are correct.

Historical Context

We had being suffering from cache problems for a while:

• https://github.com/nodejs/build/issues/3424
• https://github.com/nodejs/TSC/issues/1416
• https://github.com/nodejs/build/issues/3410

Seems like the long term solution will be to relocate the binaries to R2:

• https://github.com/nodejs/build/issues/3461

Implementation

I started building a simple GitHub Action that collects all the releases and generates the URLs for all the available binaries. It then performs a basic HTTP request using curl to check the response headers. After that, it generates some metrics based on this and presents a simple report in markdown format.

While presenting this proof of concept in Slack, the collaborators provided super useful feedback and suggested features that we can implement.

Current approach

The idea of using a CRON Job to collect availability metrics may not be very effective for the cache issues scenario, but there are many features that can be valuable to us.

Features requested/ideas

• Add support for iojs.org/dist as NVM depends on it (@ljharb)
• Verify the R2 cutover (@flakey5 @MattIPv4 @ovflowd)
• Store and validate the SHA for files does not change (@MattIPv4)
• Check that the SHASUMS256 files are correctly signed (@UlisesGascon)
• Check the binaries (@MattIPv4 @UlisesGascon)
  • Checksum matches the release SHASUMS256
  • Binaries described in the SHASUMS256 are available
  • Binaries are excluded from malware databases using VirusTotal
  • Binaries checksum matches the SHASUMS256

I will request to transfer the repo to the Node.js org when the code is stable and documented, currently is quite hacky code

Next steps

I have started to consolidate the feedback into issues:

• https://github.com/UlisesGascon/nodejs-distribution-system-monitoring/issues/4
• https://github.com/UlisesGascon/nodejs-distribution-system-monitoring/issues/9
• https://github.com/UlisesGascon/nodejs-distribution-system-monitoring/issues/7
• https://github.com/UlisesGascon/nodejs-distribution-system-monitoring/issues/6
• https://github.com/UlisesGascon/nodejs-distribution-system-monitoring/issues/8
• https://github.com/UlisesGascon/nodejs-distribution-system-monitoring/issues/3
• https://github.com/nodejs/admin/issues/821
• https://github.com/UlisesGascon/nodejs-distribution-system-monitoring/issues/5

Discovery

There are some things that bubble to the surface while implementing the systematic checks:

• https://github.com/nodejs/build/issues/3468
• https://github.com/nodejs/build/issues/3463