Summary
Next in the #1123/#1234/#1246/#1247/#1253/#1254 chain. repo-config/configure.sh's ruleset_id() guards against its own single-fetch assumption with a plain jq, whose output on a native Windows jq carries a trailing \r that breaks the guard's own integer comparison.
The defect
if [ "$(jq 'length' <<<"$out")" -eq 100 ]; then
(repo-config/configure.sh, ruleset_id(), around line 145.) On a native Windows jq, the substitution yields 100\r. [ "100\r" -eq 100 ] is not a CRLF-vs-LF string mismatch like the sibling sites in this chain; it is a non-numeric string reaching bash's arithmetic comparison, which prints integer expression expected to stderr and evaluates false. ['s non-zero status here is the condition of an if, which bash never treats as a triggering failure under set -e, so the guard silently reads as false at exactly the boundary it exists to catch, and its own "100 rulesets returned" stderr line never fires.
A repo that has hit the 100-ruleset per_page cap would then fall through to the single-fetch id lookup instead of aborting, exactly the "the single-fetch lookup is unreliable" case the guard's own comment says it exists to prevent. A missed name match at that point can make apply_ruleset() create a duplicate ruleset by name rather than update the existing one.
This is the same CRLF-exposure class #1123/#1234/#1246/#1253 already fixed at other sites in the same file, on a numeric-comparison guard in ruleset_id()'s own dependency chain rather than a string comparison.
Suggested fix
Route the extraction through jqr(), matching the treatment the rest of ruleset_id() gets after #1253.
Context
Found via an adversarial local-review pass dispatched while fixing #1253. Filed separately to keep that PR scoped to its assigned line.
Unverified on a real Windows host, same as #1123/#1234/#1246/#1247/#1253/#1254.
Summary
Next in the #1123/#1234/#1246/#1247/#1253/#1254 chain.
repo-config/configure.sh'sruleset_id()guards against its own single-fetch assumption with a plainjq, whose output on a native Windows jq carries a trailing\rthat breaks the guard's own integer comparison.The defect
(
repo-config/configure.sh,ruleset_id(), around line 145.) On a native Windows jq, the substitution yields100\r.[ "100\r" -eq 100 ]is not a CRLF-vs-LF string mismatch like the sibling sites in this chain; it is a non-numeric string reaching bash's arithmetic comparison, which printsinteger expression expectedto stderr and evaluates false.['s non-zero status here is the condition of anif, which bash never treats as a triggering failure underset -e, so the guard silently reads as false at exactly the boundary it exists to catch, and its own "100 rulesets returned" stderr line never fires.A repo that has hit the 100-ruleset per_page cap would then fall through to the single-fetch id lookup instead of aborting, exactly the "the single-fetch lookup is unreliable" case the guard's own comment says it exists to prevent. A missed name match at that point can make
apply_ruleset()create a duplicate ruleset by name rather than update the existing one.This is the same CRLF-exposure class #1123/#1234/#1246/#1253 already fixed at other sites in the same file, on a numeric-comparison guard in
ruleset_id()'s own dependency chain rather than a string comparison.Suggested fix
Route the extraction through
jqr(), matching the treatment the rest ofruleset_id()gets after #1253.Context
Found via an adversarial local-review pass dispatched while fixing #1253. Filed separately to keep that PR scoped to its assigned line.
Unverified on a real Windows host, same as #1123/#1234/#1246/#1247/#1253/#1254.