Kubevious YAML parser sees hex numbers differently from Kubernetes, causing false positives.

We're using Kustomize's configMapgenerator with a .env file that contains a variable whose value is a 128-bit number in hex format, like so :

test.env : FOO=0xABCDABCDABCDABCDABCDABCDABCDABCD

The generated configMap has the exact same string (no quotes) : FOO: 0xABCDABCDABCDABCDABCDABCDABCDABCD
It gets applied without any issues.

However kubevious lint doesn't like it : 🔴 Invalid type under "/data/FOO". Must be string.

It clearly parses it as a number (and I can't say it's wrong), but here's the thing : Kustomize doesn't, it sees it as a string already and doesn't add quotes to the output.
It gets more interesting : Kustomize (and also kubectl create configmap --from-env-file) behaves differently for hex strings up to 64-bit, and it does add quotes for those ! FOO=0xABCDABCDABCDABCD becomes FOO: "0xABCDABCDABCDABCD", probably because whatever YAML library it uses parses it as an int64.

This is inconsistent (if explainable) behavior from Kustomize and I'm going to report it, but that doesn't solve my immediate problem : if I add double quotes to the source variable, Kustomize will add its own single quotes to that in the output (e.g. FOO: '"0xABCDABCDABCDABCD"'). Kubevious will be happy but our application may require changes to handle that.

At the end of the day, it seems there's a discrepancy between Kubevious CLI's YAML parser and Kubernetes regarding these large hex strings, so it would be great if you could align that.

In the meantime, can you think of a workaround or a way to selectively disable this check ?

Thanks

No files or tests are named. Start at the CLI's YAML parsing and lint-validation entry points, reproduce the 128-bit hex value in a ConfigMap, and compare it with Kubernetes and Kustomize behavior. Done means the value is not falsely reported as a non-string, or a documented selective workaround exists.