Initial tests using OpenVex

[kikofernandez]

This PR adds

• openvex.table which is similar to the otp.table except that it contains all CVEs on a per branch basis
  the main idea is that instead of having to write an otp.table per branch to maintain, we have a centralised
  point in master branch that contains all CVEs classified per branch. Many openssl CVEs are repeated over
  and over from one branch to another so a central place makes it easy to maintain.

• .openvex/maint-26.openvex.json is a generated file that we use to express openvex statements.

• .openvex/templates/XXXX.openvex.json are empty templates. we are not using them as OpenVex templates since I do not
  think we gain much from them.

The main idea is to add all CVEs in openvex.table and run an otp-compliance script that generates and updates the .openvex/maint-26.openvex.json (and others) statements. Blindly running vexctl add multiple times generates the same entry multiple times, and the script (not yet implemented) should prevent us from generating the same entry multiple times.

we can express false positives running the command manually, and the master branch contains the OpenVex files up to date.
on each release, these files are push to the release page (github action to add next week).

This design is not final, but I think it makes sense to have the VEX files in the repo. If we place them in other repo, we make difficult to find them, e.g., erlang/vex where it is not clear if erlang/vex is for otp, rebar3, or any of the projects from the erlang organisation.

[github-actions]

CT Test Results

  1 files   11 suites   3m 3s ⏱️
 95 tests  91 ✅ 4 💤 0 ❌
111 runs  107 ✅ 4 💤 0 ❌

Results for commit e46ac51.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[okeuday]

@kikofernandez If the openvex json output for a release was provided as a file included in the installation, it should help to make the security situation easier to understand in the future. A file included in the installation is valuable because it should be secure, however, it will always be outdated for any new security problems.

If there was also updated openvex data provided from https://erlang.org, it could be considered the authoritative source of the data for comparisons. You may prefer focusing on the source code repository openvex data, but that doesn't have the same discoverability and ownership (i.e., attached to a DNS name). I suggest this because it would be helpful for an automated security tool that could check for CVE problems based on the current installed release.

In the past, https://github.com/okeuday/pest was able to check the current OpenSSL CVEs based on the installation information and webscraped data. However, the OpenSSL website has changed and broken the data update because no standard was being used for the information provided from their website. Allowing that discoverability with openvex is a better alternative to webscraped data because the standard can make the data more dependable and trustworthy.