fix: harden stored plugin trust and startup execution path#6719
fix: harden stored plugin trust and startup execution path#6719Chaitu7032 wants to merge 1 commit intosugarlabs:masterfrom
Conversation
|
✅ All Jest tests passed! This PR is ready to merge. Coverage: Statements: 42.4% | Branches: 35.1% | Functions: 46.74% | Lines: 42.81% |
There was a problem hiding this comment.
this is clean pr for the plugin persistence
@walterbender l
|
have you tried loading a plugin? It may be a preexisting regression, but while the Maths plugin loads, none of its block run. |
|
hy i can reproduce what walter said , the regression is in the seassion scoped trust storage when u load maths with the built-in flow, prepepare plugin exorts save the hash to sessionstorage so on reload the sesssion storage is cleared so the hash is gone then then confirm dialog appears and if dismissed , executiontrusted stays false so the palette render but blocks do nothing the fix would be to store the approval hash in localstorage( not session sorage ) for plugins that came thorugh explicit build in load flow and only use session-scropte for unknow/untrusted source |
|
Thanks for verifying it walter sir . I will test it once again on my side and update you with the conclusions shortly. |
Summary
This PR fixes a critical client-side security issue in plugin loading.
Before this change, plugins stored in browser storage could be treated as trusted and auto-executed on startup, which created a persistent execution path if storage was poisoned once.
Now, stored plugins are no longer blindly trusted, approval is explicit, and trust is scoped safely so malicious persistence cannot silently re-authorize itself across sessions.
Relevant areas:
utils.jsactivity.jsWhat this change does
Behavior after this PR
Tests added and updated
Added targeted tests for new trust logic in:
utils.test.jsNew test coverage includes:
ScreenShots
jest tests
focused test
PR Category