Split out of the RMP boundary-cleanup epic #303 as tracked tech-debt. Not a live security hole — low priority.
What
NIP-46 client authorization is tracked in two places that can drift:
- Android: the
Nip46ClientStore denylist (EncryptedSharedPreferences) + authorizedClients (keep-mobile BunkerConfig).
- Engine: the keep-nip46
PermissionManager apps map + per-kind grants.
The engine does not consult the Android denylist/authorizedClients; the two are kept in sync by hand in the revoke/authorize flows.
Why it's low priority (the exploit is already closed)
Investigated during #303. The concrete revocation-divergence risk is mitigated by earlier work:
- Revoke clears the engine grant and persists that (keep #575/#593), so a revoked client has no in-engine grant across restarts.
- Revoke removes the client from the engine apps map, so it cannot even sign globally auto-approved reactions.
- The denylist backstops the callback path; reconnect that clears the denylist is user-gated (the connect prompt).
What remains is architectural duplication (two authz lists that could drift), not an exploitable hole.
Proposed fix (if revisited)
Make the engine the single source of truth for NIP-46 authorization: move authorizedClients + a persistent denylist concept into keep-nip46 / keep-mobile and route the Android authorization + revoke through it, then drop the Android denylist. This is a sizable authz-unification refactor for modest marginal gain, which is why it was deferred.
Out of scope to keep
The in-flight concurrency cap (max 3 pending approvals) is a UI concern and correctly stays Android-side.
Split out of the RMP boundary-cleanup epic #303 as tracked tech-debt. Not a live security hole — low priority.
What
NIP-46 client authorization is tracked in two places that can drift:
Nip46ClientStoredenylist (EncryptedSharedPreferences) +authorizedClients(keep-mobileBunkerConfig).PermissionManagerapps map + per-kind grants.The engine does not consult the Android denylist/authorizedClients; the two are kept in sync by hand in the revoke/authorize flows.
Why it's low priority (the exploit is already closed)
Investigated during #303. The concrete revocation-divergence risk is mitigated by earlier work:
What remains is architectural duplication (two authz lists that could drift), not an exploitable hole.
Proposed fix (if revisited)
Make the engine the single source of truth for NIP-46 authorization: move
authorizedClients+ a persistent denylist concept into keep-nip46 / keep-mobile and route the Android authorization + revoke through it, then drop the Android denylist. This is a sizable authz-unification refactor for modest marginal gain, which is why it was deferred.Out of scope to keep
The in-flight concurrency cap (max 3 pending approvals) is a UI concern and correctly stays Android-side.