Regal lint fails when setting capabilities in config.yaml in windows

[geirs73]

We need to lint against a bit older opa.exe in production. Seems like this is a problem on windows. At least for me.

.regal/config.yaml:

capabilities:
  from:
    engine: opa
    version: 0.64.1

Our rego bundle resides in directory named rego in directory C:\git\work\policies. Trying to run linting.

regal.exe lint -c .regal/config.yaml rego

failed to decode user config from C:\git\work\policies\.regal: failed to load capabilities: failed to load capabilities due to error: no capabilities version found 0.64.1

Not sure why this happens. I do not have opa.exe (this is windows) in $PATH, so if regal.exe needs to call opa.exe to get it, it will probably not find it.

I also tried downloading the opa capabilities file and store it locally, to get around the above problem.

capabilities:
  from:
    file: "v0.64.1.json"

regal.exe lint -c .regal/config.yaml rego

failed to decode user config from C:\git\work\policies\.regal: failed to load capabilities: failed to parse URL 'file://C:\git\work\policies\v0.64.1.json': parse "file://C:\\git\\work\\policies\\v0.64.1.json": invalid port ":\\git\\work\\policies\\v0.64.1.json" after host

Seems like there is some issue concerning how paths are handled on Windows here?

OS: Windows 11

Regal:
Version:    0.28.0
Go Version: go1.22.5
Platform:   windows/amd64
Commit:     9503967b3cd1d3725d078b04dd55ee9ec807b3f3
Timestamp:  2024-10-07T15:17:16Z
Hostname:   github.actions.local

[anderseknert]

Thanks for reporting this!

As for the first issue — can you try using v0.64.1 (with a v prefix) for version rather than 0.64.1? The latter will IIRC be interpreted as either a number or some binary representation, which isn't going to work. Either way, we should improve the error handling in that case, and make sure that it's clear what's expected.

I'll have to look into why loading the capabilities from file doesn't work. The capabilities system was somewhat remodeled recently to allow EOPA to be set as an engine, and perhaps that introduced a change in behavior. Or it's isolated to Windows as you suggested. Some digging to do!

[geirs73]

The 'v' did it. Since that worked, the next issue may not be that important, however, I think testing all file-path-related functionality on windows images probably is a good idea, due to how the error message looked. Thanks!

[anderseknert]

Better error reporting for when the version is either numeric, or missing a v prefix: #1208

The Windows path issue will have to be addressed separately, but we'll get to that.