Well this is a bit of a tricky question, since the information you refer to about what interfaces will be automatically connected is a function of quite a few things:
- the snap-declaration assertion for the snap
- the base-declaration that snapd has inside it
- some system specific parameters like whether the device is classic or whether the device has slots available to auto-connect to, etc.
- some interfaces are declared by snaps to be used, but are not automatically connected
So you can’t just parse the list of interfaces from the snap itself to figure out what permissions to grant it, this is also a security issue because now snaps uploaded to this repo/alternative store can simply declare interfaces without having been vetted. Ideally your store implementation would either use the main snapstore’s “snap assertion service” or it would have it’s own root of trust for an alternative snap assertion service.
That being said, to properly implement this, you would need to get at least the snap-declaration for a snap from somewhere and combine it on top of the base-declaration from snapd (there’s a debug command for getting the base-declaration - you should use this, since the base-declaration inside snapd often changes) and then the resulting assertion will tell you what can be auto-connected and what can be installed. The assertion part of snapd is incredibly complicated though so this will take a bit of work and (@ogra will prove me wrong on this I’m sure) probably impossible to write in a shell script. At a minimum you will need to parse YAML with nested maps and handle the fact that settings in assertions can have different types, sometimes the value for a key is a concrete type like a string (which is a regular expression), sometimes the value is a list (which means that the values in the list is an alternation, i.e. a logical OR of what the values are), or sometimes the value is a map (which means that the values in the list are required or a logical AND of the nested settings). If you’re able to do all that, then you get to the other critical part of assertions which is the fact that we don’t just use the snap-declaration blindly, we only use the snap-declaration for a given .snap blob when that .snap blob has an associated and correct snap-revision assertion (and from the snap-revision assertion we get the trust for the snap-declaration), which is another assertion signed by Canonical’s root of trust to say that the snap blob has not been tampered with at all. You could either again use Canonical’s snap assertion service to get this assertion or you would need to implement your own mechanism for folks to create their own assertion attesting to the binary bits that make up a .snap blob. If you go the latter route, you will need to rebuild snapd to add this alternate root of trust because currently snapd only ever trusts one root of trust, Canonical’s keys.
I guess one easy thing you could do is to save the .assert file alongside the .snap file on your server and have the lol client download both of them and then do snap ack foo.assert && snap install foo.snap (note the absence of the --dangerous flag), and you just use the .assert files from the Canonical snapstore. That will take advantage of all of the assertion formatting that snapd already does and thus do all of the interface logic that snapd does, but allow people to get the snap blobs initially from a source other than the store. This has perhaps the unintended side effect that now that the snap will be installed as if it was installed directly from the store that now those snaps will be updated when they are updated in the store, even if the user has not run lol refresh foo or the repo the user installed the snap from has not pushed an update there.
As to what dependent snaps should be installed, this is much easier to find out, you can inspect the snap.yaml and look for 2 things
- the base of the snap, if no base is set the implicit base is
core. So install the base snap if it is not already installed
- any content interfaces which have
default-provider set on them. This setting simply says to snapd “if this snap is not already installed, install it too as part of this change”.
Unfortunately I myself can’t commit any development time to this, there is a lot of things we are working on and committing time to reviewing code in depth or writing new code for this project is not high on the priority list. I’m happy to provide input in an abstract sense as to whether the implementation matches what we do with the normal snap store but that’s about the extent of what I can do to help unfortunately though you are in the right place for this sort of project as numerous other people on the forum have talked about developing just such a piece of software.
)