version comparison operators missing in OS posture checks

[qrkourier]

The console creates/updates OS posture checks with exact OS versions instead of a min/max range, so the posture check evaluates false unless the OS version exactly matches one of the min or max values specified in the console.

Here's what a functioning os posture check looks like in the API when it's created with the ziti CLI like this:

ziti edge update posture-check os "req-linux-6" --os 'Linux:>=6.0.0:<7.0.0'

        {
            "operatingSystems": [
                {
                    "type": "Linux",
                    "versions": [
                        "\u003c7.0.0",
                        "\u003e=6.0.0"
                    ]
                }
            ],
            "_links": {
                "self": {
                    "href": "./posture-checks/10gNgoHoM5CuMQPKoHgrsi"
                }
            },
            "createdAt": "2024-12-20T19:49:00.884Z",
            "id": "10gNgoHoM5CuMQPKoHgrsi",
            "name": "req-linux-6",
            "roleAttributes": [],
            "tags": {},
            "typeId": "OS",
            "updatedAt": "2024-12-21T18:01:16.744Z",
            "version": 1
        }

The CLI represented > and < as Unicode escape sequences \u003e and \u003c, respectively, when listing posture checks with --output-json, but this appears to be a quirk of the CLI, because I see the ASCII representation when I get the list directly with REST.

[qrkourier]

I found a relevant part of the API spec, but it doesn't detail how to represent OS versions.

This security concept article about posture check has some examples that told me how to write valid CLI commands.

The console's OS versions min/max values should be prefixed with comparison operators >=, <= when sending API requests, unless the user-supplied values already contain comparison operators.

[qrkourier]

On second thought, the concept of min/max doesn't align with how these values are represented in the API, leading to an unordered presentation in the console.

Specifically, the API expects a list of versions which must all evaluate true and are not evaluated in a predictable order, e.g. >=6.0.0 and <=7.0.0 must all be true in any order.

The console's min/max labels are nonsensical because the required versions' comparison operators are not parsed.