The problem is in the crowd aspect of it. If it’s in development mode, we shouldn’t have too large a crowd installing and using the snap for testing purposes. Either it’s so incipient and broken that only developers can use it, in which case we don’t want it publicly available, or it’s good enough that we can ask people to have a look, and thus we’ll make it visible in finds and anyone can install it.
Also note that --devmode works for strict snaps. That means you can in fact make something available on edge that does not work, and install it under devmode. The difference is that if someone else finds and installs it, it will be broken rather than unconfined. Good trade off if you’re picking something from edge and don’t really know what you are doing, in my opinion.
I’d like to understand the motivation for this publishing change a bit better. Currently, as far as I understand how things normally work, installing a devmode confined snap from the edge or beta channels today still requires the --devmode flag for the snap install <my_snap> command.
Even though you’re going to be enabling snap find <my_snap> to start returning results from these two other channels soon, to me it’s not a significant problem because a user can’t accidentally install a devmode confined snap without explicitly adding the --devmode flag - so it’s an opt-in feature already. So where’s the danger that users might be accidentally using a lot more devmode confined snaps? What am I missing?
Let me try to answer that by offering a different perspective: a snap in development mode is meant for developers. It has features and will soon should have more features that are geared towards developers, for development. You can install any non-classic snap in development mode today, and I’d like to make sure we can install classic snaps in development mode too. So development mode is clearly an orthogonal concern, independent of publishing that snap to the store, or even in which channel in the store the snap is made available.
So why do we allow recommending to general users that they need to install things in development mode?
That’s the piece that makes little sense to me. If a snap is made available to crowd-testing, either it should be ready enough that certain things work confined, or if there’s agreement that it’s one of those cases that need wider system access, it should be classic.
Thanks for the response. I understand what you are saying, but I think I was not clear in explaining the risks if we don’t remove the --devmode flag (at least for snaps installed from the store). And yes this risk already exists, but given we are making the devmode experience more restrictive, it may be a good opportunity to fix this as well.
Suppose there is a snap ‘foo’ which snap.yaml does not define any explicit confinement (so it defaults to strict) or defines ‘confinement: strict’ explicitly. And this snap does all sort of privileged operations in a snappy system. Because it’s strict, the automatic review tools will approve, and the snap owner can release ‘foo’ to any channel, even stable.
Of course that if a user installs this snap with “snap install foo”, and the proper interfaces are not connected, the snap ‘foo’ will not work, which is correct and maintains snappy-world peace.
But what if the publisher of ‘foo’ carefully explains on the install instructions that it needs to be installed with ‘snap install foo --devmode’. Average users will just copy and paste instructions and run it as indicated. So we end up with what it looks a confined snap but that is run with devmode in the wild.
I understand that end users are in control of whether they follow the instructions to use the --devmode flag or not, but this feels like an opportunity to clean this bit up and avoid depending on the user to make a difficult decision.
To be clear, currently the review-tools do not flag devmode snaps for manual review because a) they aren’t findable since they aren’t in the stable channel and b) the user needs to specify ‘–devmode’ to install a strict mode snap in devmode.
Documentation today could already say “sudo snap install foo --devmode” for a foo snap to root your system. Are you proposing something specific (eg, confirmation prompt) to clean this up?
Yes, and I still think this is correct. I did not mean to imply any issue with the review tools, I think they make the right decisions with the information they have.
What I’m proposing(ish) is to remove the possibility to use the --devmode flag with a snap installed from the store (ie with a non-local snap).
This way, no snap can “lie” to the store appearing to be fully confined and then ran by users in the wild as devmode. This also aligns with the latest comment from Gustavo on Sunsetting public release of devmode snaps, where --devmode means “development mode” and not a way to make a confined snap work without connecting the proper interfaces.
If the --devmode flag is removed, the choices that the ‘foo’ publisher has are:
set the proper and “honest” confinement in the yaml: confinement: devmode (thus the store will not allow releasing to any channel)
request classic following the current procedure
request a specific interface if it needs one that’s not available yet
That seems reasonable to me, and thanks for further explaining what you’re thinking about this.
This is the part I can’t quite provide any anecdotal use cases on, but I’m hoping others can chime in if they have real valid cases where this needs to work this way or if it should work the way that you’re suggesting. What you suggest of using strict or classic modes seems like sound reasoning.
To be perfectly clear, are you saying that --devmode should only be valid with --dangerous? Or, remembering that a ‘local snap’ might be fully asserted, are you saying that the following would also be allowed:
$ snap download foo
$ sudo snap ack ./foo*.assert
$ sudo snap install --devmode ./foo*.assert # --dangerous not needed due to 'snap ack'
That would imply there’s no value in devmode at all. I think we already have some development oriented features today, in terms of logging for example, which seem worth having. Also, the logging in this particular case is different from a fully-confined snap, in that you’ll see logs for all denials, instead of stumbling upon the first denial every time.
But your point is an interesting one, that it is perhaps too easy today to encourage people to just go ahead and install things from the store unconfined.
I don’t think I see this. The owner and collaborators of the snap will still be able to install in devmode by revision. I just envision snapd getting a request like:
snap install foo --revision X
and once it gets the actual blob (that was given because the call was properly user authenticated so the store ACL checks decide the user is known and can access a non release revision), snapd installs it with confinement devmode cuz that’s what the store indicates is the confinement for this revision (which is what I first understood from your original post, when you said “But those revisions will only be usable by people with private access into that account, and via the –revision flag”).
My main worry is that the ‘foo’ snap I used as example shows up in the stable channel. So running “snap install foo --devmode --stable” does not fail in any way, nor warms the user about the risk he/she is buying into.
IMO, --devmode is a useful thing, in general. It seems worthwhile thinking through if the store interactions could be better, but I would caution against trading one set of pasteable instructions for another.
Perhaps we can improve it like this: today we consider local unsigned snaps as dangerous, and for those we force the user to acknowledge this fact by stating –dangerous in the command line. We could make snapd a bit more strict than that and also request that devmode be accompanied by either –revision, in which case it’s your own snap, or –dangerous, if it’s anyone else’s.
Are you suggesting to continue allowing devmode snaps in the store but require users to specify the revision and/or use the dangerous flag? That seems reasonable.
I just wanted to voice my opinion against eliminating devmode entirely. Some snaps by their nature tend to brush against the permissions boundaries, e.g. because they perform complicated configuration and system management. I don’t mind if the dangerous flag steers general users away from installing such snaps, but as a developer and system administrator, I would still like to use the snap store to distribute my software to Ubuntu Core devices.
That’s a very interesting point, because it’s both the reason why we want to disallow that confinement mode in channels, in the sense it’s being misused to conduct software unconfined instead of being used for development, but at the same time we want to look into your actual use case because we want to offer you a proper alternative to that which does not involve development mode flags.
Can you share with us what kind of access do you need into the system, and for which application?
I agree this is reasonable and is definitely a step forward. I would add one extra bit of strictness by ensuring that --devmode, in snapd, can only be used with --edge or --beta but never with --stable or --candidate.
Wanting to debug issues on a snap is orthogonal to whether it was released in stable or not. If we add the requirement of –dangerous to third-party snaps, that’s already much better than anything else people can already do by pasting shell commands from arbitrary sources.
