Version Check API - Add latest_stable_version_of_minor

What / Why

API/Backend for gitlab-org/gitlab#438447 (closed)

This change adds a new key to the /check.json endpoint latest_stable_version_of_minor. This key will provide the latest non-vulnerable version available on the provided minor version. If one is not available the value will be nil.

This will be used in GitLab to provide some additional information it the critical security alert pop up:

• Preferably, latest supported versions: 16.7.2, 16.6.4, 16.5.6
• Latest patch of your current GitLab minor version: 16.3.7

Video Demo

UI Setup	API Test
UI_Setup	API_Demo

How to Test

Important: To test this fully there is a bit of setup you will need to do. I will visualize this in the video demo above.

1. Have version.gitlab.com fully running locally and ability to add some test version records.
2. Have a way to send GET requests with modified HEADERS. I used Postman w/ Postman Desktop Agent to fire localhost requests.
3. A way to Base64 encode your version information to send in the query params.
   • I use rails c and the following method Base64.urlsafe_encode64({ version: '11.0.0' }.to_json)

UI Setup

1. Follow important steps (and remember I will demo this in the video above as well)
2. Create a few non-vulnerable versions across 4 different minor patches. For simplicity I am doing 11.0.0, 11.1.0, 11.2.0, 11.3.0
3. Create a Critical Security Release for a patch on each of those versions. In my case 11.0.1, 11.1.1, 11.2.1, 11.3.1
4. This will mark the initial non-vulnerable versions you created in step 2 as Critical Vulnerabilities

API Testing

1. We are going to simulate a customer currently on 11.0.0 (a critically vulnerable version 4 minor versions behind)
2. Using Base64 encoding in rails c generate your encoded string Base64.urlsafe_encode64({ version: '11.0.0' }.to_json)
   • eyJ2ZXJzaW9uIjoiMTEuMC4wIn0=
3. Create a GET Request with the following details
   • url: localhost:3000/check.json?gitlab_info=eyJ2ZXJzaW9uIjoiMTEuMC4wIn0=
   • header: REFERER=http://gitlab.example.com
4. You should get a JSON response that includes the following information
   • latest_stable_versions: ['11.3.1', '11.2.1', 11.1.1']
   • latest_stable_version_of_minor: "11.0.1"
   • latest_version: "11.3.1"

Usage Notes

Initially we intended to also add logic to only provide data in this key if the patch wasn't also listed in latest_stable_versions. I felt this was a bit implementation specific as well as made the key a bit harder to understand without digging into the code.

I made the decision to make this key very straight forward on what it provides (the latest stable patch for the minor version) and allow the implementing UI (in this case GitLab) decide when to display it. I.E a string match to see if the patch is already in the latest_stable_versions.