This is a heads up that we have partial agreement to sunset devmode snaps being released into public channels. That’s not final yet, and that is part of the reason why I’m posting this here now, so you have a chance to say something before it is indeed final. The other reason is to give everybody time to move away from this practice if they are today using it.
Note that this change will not prevent snaps from being pushed into the store. That will continue to be accepted. But those revisions will only be usable by people with private access into that account, and via the –revision flag.
Some of the rationale for this change:
devmode means development mode, so we should be more truthful to that and not recommend those to users everywhere; in the future we will implement more features that change the behavior of snaps in these cases, so they are easier to debug, and we will want those going into end systems even less.
In the early days of snapd we had very few interfaces, so almost everything would break until we introduced the interface, so devmode gave people a chance to publish while we sorted the interface requests. Nowadays, we have plenty of interfaces, and we also have classic snaps for cases which can’t be supported immediately by the current confinement system. Classic mode requires approval though, which is good in this context.
Until now we only show snaps if they have releases in stable or candidate channels. For various reasons we are about to lift that, and we’ll show snaps no matter where they are. But devmode snaps again are an awkward case to be recommending openly, and that’s really what a release means.
It seems that devmode confined snaps will gate the publishing into a channel, for which I wonder if this means we should deprecate the grade keyword.
It could still have uses, such as a strictly confined snap which is still not ready to go into the more user oriented channels. But personally, I would like to decouple grade: devel and confinement: devmode, which they already are, but both of these seem confusing in the naming of what they mean.
Just to shoot out some names, I would call them grade: unstable or confinement: non-strict (keeping backwards compatibility).
In summary, my comment is, what about grade and can we take the opportunity to make some tags/attributes clearer.
In summary, my comment is, what about grade and can we take the opportunity to make some tags/attributes clearer.
Maybe it’s a good time for someone to redefine what the exact intentions of grade: vs confinement: are - this could aid quite a bit in the discussion that you and Gustavo both brought up in this thread.
I think grade: devel still has value for strict or classic confined snaps and will prevent developer to release those revisions in candidate or stable by mistake. grade and confinement are not coupled.
The confusion comes from grade:devel, which was a mistake. I would like to fix that, and rename it to grade:unstable.
The motivation for grade hasn’t changed, and is still useful: it ensures the content of the snap defines what is the intention of the snap. It makes it impossible for a revision that is in the store with unstable code and data to be released onto a public channel that goes into end systems that expect stable content. It’s a safety net.
@niemeyer Could you please clarify if the --devmode flag on snap install is going away? And depending on the answer, I have some follow up questions:
If yes (the --devmode flag dissappears), how can someone iterate on the snap development when trying to install it locally (not going thru the store) if the flag is no longer available, and the confinement of the snap hasn’t been fine tuned yet?
If no (the --devmode flag remains), would there be stronger checks for when the flag is trying to be used on install? For example, not allowing using --devmode when the snap is installed from the store.
No changes to the client. What we’ll change if that goes through is only about preventing the release of snaps in channels. You can even upload them to the store still. It’s just that the store will reject attempts to release those.
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
