Trying to figure out if we should or shouldn’t use Ubuntu Core for our project. You guys did a great job on Core and Snap(craft) Thank you
To get a fully functional customized image, we read in the documentation (here and there) that we need to customize the gadget snap. That’s great!
Problem is, to include that gadget snap in our image we have to use --snap our_gadget.snap on ubuntu-image which makes it ineligible for updates, ubuntu-image makes that very clear: “WARNING: “our-gadget” installed from local snaps disconnected from a store cannot be refreshed subsequently!”.
That’s no worries, we head to privately releasing this snap, we know we can automate that and benefiting from refreshes will be great! So we published a customized version of the core22 pc-amd64-gadget.
New bummer on the road: (NEEDS REVIEW) type 'gadget' not allowed lint-snap-v2_snap_type_redflag.
As much as we understand anyone could publish a hacky snap with some keylogger or whatever, snap that could then be installed on many machines before being somehow flagged and removed from the store, a manual step in the middle of some snap building/publishing automation seems like quite an issue
Besides, the automated email isn’t answering many questions, which led us to this very topic on the forum
Questions (numbered to ease answers/discussions):
is someone actually reviewing those snaps manual review requests?
do we have to be paying customers for Canonical teams to action those reviews?
should we expect this manual step (and the related, unpredictable wait time) every single time our CI systems push an updated version of our gadget snap?
if we were a paying customer with a dedicated brand IoT store, would we still have to face that manual step?
We’ve read a lot of your documentation, and it isn’t very clear where the line between paying vs non-paying customer/user is
you will need a brand store for using a custom gadget, non-canonical maintained gadgets are only allowed to be uploaded to personal IoT App Stores, not to the global store (same goes for kernels).
Just a friendly follow-up, I find it odd that one would need a private IoT App Store (which is pricey to setup), plus an annual fee per machine, eventually just for one (or any combination) of those pretty common features, which all need an update to the gadget snap:
configure / connect their installed snaps (ie avoiding a manual operation to connect to the machine and launch a custom script once it’s installed)
That’s a hefty price tag for such basic Linux features
Assuming private snaps are installable only by machines provisioned through images built from signed (by the same Developer/Team ID that published the private snap) model assertions, wouldn’t it be better simply disabling publicgadget (and kernel) snaps, but leaving people doing private stuff alone?
I’m guessing currently forcing the need for an IoT App Store might drive revenue for Canonical. But I’m sure that’s a lot of frustration for users, and that probably drives Ubuntu Core adoption down
Not here to rant or anything like that, on the contrary, trying to help, and I know how paid vs free is hard in the Open Source world. Letting people play with their machines configuration through private gadget/kernel snaps might just boost user adoption, everyone of those users will just sooner or later reach a point where being a paying customer to get commercial support will totally make sense!
What I’m thinking is a $5~15k entry ticket is probably a no-go for most starting projects that haven’t made money / sold anything just yet, when it totally seems reasonable after a bit of maturity / market fit. You could even get them to pay only the fee per machine for their private snaps on the global store, but I’m guessing that’s for your sales/marketing guys to crunch the numbers there
Private snaps are not meant as a generic sharing mechanism; they are meant to enable trusted developers to contribute while the snap is under development.
A private snap is only accessible by its owner and collaborators. But also note that all collaborators have read/write permissions to the snap. If you’re using this mechanism to share access to your snap with non-trusted users, be aware any of them can potentially push updates to the snap, malicious or not.
Thanks for the insight, Daniel! In my mind, collaborators of the Ubuntu One / Snapcraft team of the related snaps are developers and it’s okay for them to push updates. Most likely CI systems will push updates with a single user - unavailable to most developers - and developers wanting to try their “deployed, private snap” can just use the image at their disposal, but they can’t use this image to manually push an updated version of the snap. So we’re cool, or I’m mistaken
I totally understand your point. Not meant to, but the fact that they can be automatically refreshed make them candidates for such use cases though, doesn’t it?
Ultimately you decide who you make a collaborator to your snap. I’m just pointing out that whomever has this access can also push updates to the snap and generally wreck things. Do NOT use collaboration as a means to keep your snap private and only allow people who you add as collaborators to download/install it, unless those people are trusted (as you said).
If you are careful and heed the early warning you should be ok. Remember though that a gun can be used to open a can of beer - does this make a gun a candidate for the “opening cans” use case? I’ll let you draw your own conclusions
Thank you 
