Follow-up to #353, found by the gate acceptance suite (#359) rather than by an app.
The residual false-positive class
#353 widened _GUARD_HELPER_NAME_RE so the auth token no longer has to be the
final CamelCase segment. It did not remove the requirement that a non-empty
segment sit BETWEEN the prefix and the token, so the auth token can never come
first.
Consequently these are still reported as unguarded IDOR despite being guards:
hasPermission()canAccess()
Both are conventional Nextcloud-ish predicate names, so this is not an exotic shape.
Measured, not inferred
The gate acceptance suite in #359 exercises the regex directly against both the
pre-#353 and post-#353 forms.
⚠️ Also worth correcting for the record: the #353 commit message states that
canAccess matched. Measured against both regexes, it never did. #353 is
still a clean widening — nothing was lost and hermiq genuinely went 3 → 0 with all
of gate-7's own unit tests passing — but the message overstates its scope.
Why this is filed rather than fixed here
Two agents are mid-flight on gate-7-adjacent work and #359 (the acceptance suite)
is open for review. Landing a second regex widening now would change a gate's
verdict across the fleet while that suite is still being reviewed. The fix belongs
after #359, and #359 should carry the fixture that pins it.
Suggested fixture, to live alongside the #353 one: hasPermission and canAccess
in the clean arm (must NOT be findings), with canRender and hasChanges staying
in the planted arm (must remain findings, since neither carries an auth token).
/cc the hydra-gates acceptance suite work in #359
Follow-up to #353, found by the gate acceptance suite (#359) rather than by an app.
The residual false-positive class
#353widened_GUARD_HELPER_NAME_REso the auth token no longer has to be thefinal CamelCase segment. It did not remove the requirement that a non-empty
segment sit BETWEEN the prefix and the token, so the auth token can never come
first.
Consequently these are still reported as unguarded IDOR despite being guards:
hasPermission()canAccess()Both are conventional Nextcloud-ish predicate names, so this is not an exotic shape.
Measured, not inferred
The gate acceptance suite in #359 exercises the regex directly against both the
pre-#353 and post-#353 forms.
#353commit message states thatcanAccessmatched. Measured against both regexes, it never did.#353isstill a clean widening — nothing was lost and hermiq genuinely went 3 → 0 with all
of gate-7's own unit tests passing — but the message overstates its scope.
Why this is filed rather than fixed here
Two agents are mid-flight on gate-7-adjacent work and #359 (the acceptance suite)
is open for review. Landing a second regex widening now would change a gate's
verdict across the fleet while that suite is still being reviewed. The fix belongs
after #359, and #359 should carry the fixture that pins it.
Suggested fixture, to live alongside the #353 one:
hasPermissionandcanAccessin the clean arm (must NOT be findings), with
canRenderandhasChangesstayingin the planted arm (must remain findings, since neither carries an auth token).
/cc the hydra-gates acceptance suite work in #359