Add a Security and Update model for snaps dependencies.

[Bunjin]

Thinking about a mechanism for snaps requiring other snaps (similar to dependencies)

[Pasting here a discussion we had on slack with Dan regarding this]

Imagine I need a state channel snap for my gaming snap.
If so, then we need a way to specify which version of the dependency snap is being used. And then potentially to handle several versions of the same snap in case a snap that requires it hasn’t updated to the latest version

Dan Finlay 4:05 PM
It is worth considering this! For now we just had the implicit dependency enabled by requesting a connection between plugins. We could require snaps of breaking change to simply have different origins, is one way. But worth laying out the options.

Vincent ELI 4:35 PM
Snaps of breaking change to simply have different origins, is one way
This would span a different key space right?
It would then mean that any breaking change snap update would require to migrate the crypto to this new key space.
(may not even be doable in some cases, if the snap didn’t anticipate this in its previous crypto schemes)

Dan Finlay 5:47 PM
I’m curious what you see as the alternatives. If a snap has a breaking interface, dependent modules should need to deliberately opt into the update. If it does not, it can update without a new name. We could even have semver namespacing, like [PATCH].[MINOR].[MAJOR].snapname.eth

Vincent ELI 6:02 PM
An extreme alternative would be to require all snaps to hardcode the version of the snaps dependencies and use only those. But then they would need to bump versions to update the dependencies.
We indeed need to find something in between that allows a given snap’s snaps dependencies to be updated automatically unless there is a breaking interface change while allowing snaps to make breaking interfaces changes without changing the keys they use
What about specifying in the snap manifest the snaps dependencies major version used. If there is a major update, the snaps requiring have to opt in deliberately indeed.
If there is a minor update, it will automatically update
Any breaking interface change requires indeed a major version change.
And we don’t take the semver part of the path into account to generate the snap’s keys
So a snap would only use keys generated by “snapname.eth” no matter the version of the snap
if the snap would like to start using new keys, dependent on the version, then they can do by deriving the keys they use from the on we provide them and they would have to do so in a way that is version dependent

Although there is a related topic: How much do we want to secure the use of snaps dependencies? What if I’m including a state channel snap dependency in my dex snap because I audited the code of a given version? Can I provide a checksum of that file and say that I want to use only this version? Maybe I don’t want to take the risk that when a new user installs my dex snap he could download a malicious code for the dependency that would do malicious stuff at the state channel level.
or do we go more for a trust model between snaps publishers and we rely on ens to keep the url secure
Dan Finlay 6:34 PM
I like the idea of letting snaps/dapps specify exactly the security model they want: Hard code to a hash? Auto update non-breaking changes? Anything by the same key?

Vincent ELI 6:35 PM
Yes so depending on how much you specify in your snap manifest you can choose your security and update model

Dan Finlay 6:35 PM
Yeah, I think that makes sense.

Vincent ELI 6:43 PM
the options are:

• lock to a given version file with checksum hash verification / no updates - extra secure
• lock to a given version without checksum verification / no updates - less secure
• lock a given major version without checksum verification / auto updates of minor changes - less secure
  Anything by the same key?
  do you mean adding specifying a given key and comparing it to the publisher’s key that signed the new version? If so then yes we can add this as another parameter than can be specified for any of the 3 options above

Dan Finlay 6:44 PM
Yeah I think that we should definitely require cryptographically secure origin keys:

• https
• ens
• ipfs/swarm?
  I prefer the first two, because they imply a publisher key being validated somehow.
  It’s not just a hash being verified, it’s an update channel.

Vincent ELI 6:45 PM
Yes so that’s in the case you trust the publisher
So yes we have the 3 options above with or without the origin key
Now regarding updates of a given snap, from the user perspective. I think we can use the resquestPermission model for that.
Made a few comments there about that #45
3 options there too from the user perspective:

• refuse trackUpdates and thus autoUpdate
• accept trackUpdates but update manually
• accept autoUpdate (trackUpdate required) (edited)

Dan Finlay 6:50 PM
Yes, installing a snap should have basically the same permissions constraints as a snap dependency of another snap.
And the dapp suggesting the installation could suggest the default model, but the user should be able to customize it on the approval screen.

Vincent ELI 6:50 PM
And we can also include some security for the user like verifying the origin key and warn if it changed.
On a fresh install we probably also need a way for advanced users to verify the hash or signature