#20 Fix osquery version check Pull request opened by javuto Fix osquery version check Three bugs in the

verify

version-check path.

osqueryVersionCompare

was not a SemVer comparison It returned

1

on the first component where

existing > required

without first establishing that the higher-order components were equal, so

1.9.0

compared as newer than

2.0.0

— and

2.0.0

vs

1.9.0

returned

1

as well. The trailing

res := 2

fallthrough also meant

1.2

vs

1.2.0

reported "required is higher" instead of equal. Now compares component by component after zero-padding, returning at the first difference, and

0

when all components are equal.

getOsqueryVersion

could panic Guarded

len(splitted) < 2

but indexed

splitted[2]

— two-field output panicked with

index out of range [2] with length 2

. It only worked because

osqueryd -version

happens to print three fields. Guard is now

len(fields) < 3

. Parsing moved to

parseOsqueryVersion

so the case is testable without executing `osqueryd`; uses

strings.Fields

, which also drops the separate

TrimSpace

and tolerates repeated spaces. An unknown version reported as valid

verify

checked

> 1

, so the

-1

error sentinel fell through to logging "osquery version is valid". Now a `switch`:

2

→ too low,

-1

→ "unknown osquery version", otherwise valid. Tests Table-driven: 15 cases for the comparison (both directions of `1.9.0`/`2.0.0`, equal, mismatched component counts,

5.10.0

vs

5.9.0

to pin numeric-not-lexical ordering, both error sentinels) and 7 for the parse (three-, two-, one-field, empty). Confirmed failing against the pre-fix code.

go test ./cmd/osctrld/ -race

— 85 pass.

golangci-lint run ./...

— 0 issues. jmpsec/osctrld