security(oauth): restrict OAuth signing-key settings to system admins

[gonzalesedwin1123]

Problem

spp_oauth granted base.group_user (every internal user) read + write on
res.config.settings, which exposes oauth_priv_key — the RS256 JWT signing key used
by calculate_signature() — and oauth_pub_key. A low-privileged internal user could:

• Read the private key and forge OAuth/JWT tokens that verify_and_decode_signature()
  accepts (full API auth bypass / impersonation), and
• Overwrite the keypair to break or subvert authentication (tamper / DoS).

Severity: High/Critical — this is a signing credential, not a config toggle.

Why the ACL fix alone is not enough

res.config.settings.default_get() (Odoo core base/models/res_config.py) reads
config_parameter fields via ir.config_parameter.sudo() and performs no model-ACL or
field-group check. It is an @api.model method reachable over RPC, so
env['res.config.settings'].default_get(['oauth_priv_key']) leaks the key regardless of the
ACL. This was reproduced by a failing test before the fix (the plain-user default_get
result contained the private key). Both changes below are required.

Changes

1. Remove the over-broad ir.model.access row. Odoo core already grants
   res.config.settings to base.group_system (read/write/create), so system admins keep
   full access and can still Save settings. This was the only module in the repo widening this
   model to base.group_user.
2. Override default_get to strip oauth_priv_key/oauth_pub_key for users who are not
   base.group_system, closing the sudo RPC path. (A groups= field attribute would not fix
   this — field groups are not enforced in default_get's config loop.)
3. Bump manifest 19.0.2.0.0 → 19.0.2.0.1.

Tests

New spp_oauth/tests/test_config_settings_acl.py:

• plain internal user is denied model access to res.config.settings (AccessError);
• plain internal user cannot read the keys via default_get;
• system admin retains model access and can read both keys via default_get.

Written test-first (failing → passing). ./spp test spp_oauth → 14 passed, 0 failed;
./spp lint clean.

⚠️ Operational remediation required

Every internal user has had read access to the signing key historically, so the deployed
RSA keypair must be treated as compromised. After upgrading, operators should rotate
(regenerate) the keypair and invalidate any outstanding tokens. A code fix cannot un-leak an
already-exposed key.

Out of scope (noted for awareness)

• Placeholder values in data/ir_config_parameter_data.xml (YourPrivateKeyHere /
  YourPublicKeyHere) are non-secret placeholders.
• Empty 0-byte spp_oauth/tools/private_key.pem / public_key.pub are unused (keys are read
  only from ir.config_parameter).
• password="true" on the settings view fields is display masking only, not an access control.

Merge order (vs #114 spp_oauth stable prep)

Per the cross-PR interaction analysis (2026-07-24, internal/plans/security-prs-interaction-analysis.md): this PR merges before #114. #114 renames the exact fields this PR's guard protects (oauth_priv_key/oauth_pub_key → oauth_private_key/oauth_public_key, same lines in res_config_settings.py) — a guaranteed conflict whose naive resolution (keep this guard verbatim + #114's renames) leaves OAUTH_KEY_FIELDS pointing at dead field names: res.pop() removes nothing and the signing-key leak this PR closes silently reopens, with green-looking code. #114's post-merge rebase must rename the OAUTH_KEY_FIELDS entries AND port this PR's test_config_settings_acl.py to the new names — the ported test is the safety net. The ACL-csv conflict is semantically compatible either way (both end admin-only). Versions sequence cleanly in this order (2.0.1 → 2.1.0).

[gemini-code-assist]

Code Review

This pull request enhances security by restricting access to OAuth signing keys to system administrators. It removes broad read/write access to res.config.settings for standard users and overrides default_get to filter out sensitive keys for non-admins, backed by new integration tests. The feedback suggests ensuring that custom group checks bypass restrictions when running in superuser mode (self.env.su) to prevent unexpected behavior during elevated executions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.25%. Comparing base (a92701b) to head (e9dc451).

Additional details and impacted files

@@                     Coverage Diff                     @@
##           19.0-staging-sec-batch1     #265      +/-   ##
===========================================================
+ Coverage                    71.16%   71.25%   +0.08%     
===========================================================
  Files                          221      227       +6     
  Lines                        15396    15441      +45     
===========================================================
+ Hits                         10957    11002      +45     
  Misses                        4439     4439              

Flag	Coverage Δ
spp_base_common	91.07% <ø> (ø)
spp_oauth	100.00% <100.00%> (?)
spp_programs	65.27% <ø> (ø)
spp_registry	86.94% <ø> (ø)
spp_security	69.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
spp_oauth/models/res_config_settings.py	100.00% <100.00%> (ø)

... and 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gonzalesedwin1123]

Staff review (post-rebase, head cc6a56d6): SHIP-WITH-NITS. The one must-fix is addressed in abe64750: added the readme/HISTORY.md fragment for 19.0.2.0.1, including the operator-facing key-rotation instruction. That mattered more than usual here — the remediation is manual, and the changelog is how a deployment learns the deployed keypair must be treated as compromised. (CI does not catch a missing fragment: no fragment change means no README drift for the oca-gen hook to diff.)

Review traced every enumerable read path against Odoo 19 core source and found none open: default_get over RPC (the original sink), read/search_read/web_read, the web client onchange path, direct ir.config_parameter reads, the write/tamper path via execute(), get_values(), API controllers, exports, and MRO re-add by another inheritor. The default_<field> context-forge vector from #364 was checked specifically and is not applicable here: res_config.default_get unconditionally overwrites config-parameter fields, and the pop runs last.

Also confirmed: the post-rebase field names still match (no upstream rename — git log 02de7ba7..cb7f4c6b -- spp_oauth is empty), and the superuser-mode commit is necessary rather than a widening — without it a sudo'd settings write would have wiped the live signing key.

Two optional hardening items deliberately not taken here, to keep the reviewed diff minimal:

1. Add groups="base.group_system" to both field definitions as defence-in-depth. The current barrier is core's ACL plus the default_get pop; field groups would also close the write path if any future module widens the res.config.settings ACL.
2. Three cheap test asserts pinning invariants that currently rest on Odoo core behaviour (context injection, get_param as an unprivileged user, create({}) → read()).

Standing constraint unchanged: #265 must merge before #114, whose rebase must rename the OAUTH_KEY_FIELDS entries and port test_config_settings_acl.py — a naive resolution silently reopens the leak. Post-rebase wrinkle: #265 now targets 19.0-staging-sec-batch1 while #114 targets 19.0, so the ordering must be enforced when the batch lands on 19.0, not just between the two PRs.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.