Follow-up discovered during the staff review of the Registry Search server-side limits fix (PR #335). Deliberately left out of that PR's scope: the values are administrator-controlled, so this is robustness, not an attacker-reachable bypass.
Severity: Low (robustness / availability, admin-controlled trigger)
Problem
Both search_registrants and get_search_config in spp_registry_search/models/res_partner.py parse the search-governance config parameters with a bare int():
config_limit = max(10, min(200, int(get_param("spp_registry_search.result_limit", "50"))))
min_chars = max(1, min(10, int(get_param("spp_registry_search.min_chars", "3"))))If an administrator sets a non-numeric value ("abc", "", "10.5") via the System Parameters UI (which does not validate these), int() raises ValueError:
- every registry search RPC returns a generic 500 until the parameter is fixed, and
get_search_config fails during portal init (the JS catch silently falls back, masking the misconfiguration).
The res.config.settings fields write sane integers, but ir.config_parameter records can be edited directly.
Suggested fix
A small _get_int_param(name, default, lo, hi) helper used by both methods: int() in try/except (TypeError, ValueError) falling back to the default, then clamped. Optionally log a warning naming the bad parameter so the misconfiguration is visible. Tests: corrupt each parameter, assert search still works with defaults.
Origin
Follow-up discovered during the staff review of the Registry Search server-side limits fix (PR #335). Deliberately left out of that PR's scope: the values are administrator-controlled, so this is robustness, not an attacker-reachable bypass.
Severity: Low (robustness / availability, admin-controlled trigger)
Problem
Both
search_registrantsandget_search_configinspp_registry_search/models/res_partner.pyparse the search-governance config parameters with a bareint():If an administrator sets a non-numeric value (
"abc","","10.5") via the System Parameters UI (which does not validate these),int()raisesValueError:get_search_configfails during portal init (the JScatchsilently falls back, masking the misconfiguration).The
res.config.settingsfields write sane integers, butir.config_parameterrecords can be edited directly.Suggested fix
A small
_get_int_param(name, default, lo, hi)helper used by both methods:int()intry/except (TypeError, ValueError)falling back to the default, then clamped. Optionally log a warning naming the bad parameter so the misconfiguration is visible. Tests: corrupt each parameter, assert search still works with defaults.Origin
security(registry): enforce configured search limits server-side in search_registrants)internal/plans/sec-registry-search-limit-bypass.md(staff review, Low finding a)