You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.
By exposing the wallet API as a global variable, we expose it (and the plugin's restricted methods, which may be sensitive) to not just the plugin's entry point, but all of its dependencies, making plugins more prone to dependency supply-chain attacks.
Instead, we could require plugins export an object or function, which would allow us to pass in authority in a more controlled way. For example, a plugin may look more like:
module.exports = function (wallet) {
wallet.onUnlock(() => console.log('tada!'))
}
We could also have plugins export an object, which would allow it to register methods, but this opens it to potential name collisions, I'm not sure which API is better, but am open to reasoned opinions.
The text was updated successfully, but these errors were encountered:
It is unclear whether the proposed approach had the benefit of mitigating the suggested attack. I have removed the blocker tag until we can further investigate whether there is a safe way to expose an object to a SES-confined script in a way that its dependencies don't necessarily also have global access to that object.
(The answer may simply be that the plugins would want to run SES around their dependencies, in which case it is beyond our control, but #98 might make it easier to do that).
I'd love to get input from @erights on whether this goal should be pursued by our plugin system itself, or just be a best practice for plugin developers to be encouraged towards.
By exposing the
wallet
API as a global variable, we expose it (and the plugin's restricted methods, which may be sensitive) to not just the plugin's entry point, but all of its dependencies, making plugins more prone to dependency supply-chain attacks.Instead, we could require plugins export an object or function, which would allow us to pass in authority in a more controlled way. For example, a plugin may look more like:
We could also have plugins export an object, which would allow it to register methods, but this opens it to potential name collisions, I'm not sure which API is better, but am open to reasoned opinions.
The text was updated successfully, but these errors were encountered: