I like the ingenuity of this, but doesn’t it result in the same problem? Third parties would include this step in the instructions for users to copy and paste, and the user wouldn’t know any different.
IMHO, this is no different than where we instruct snap authors to not include --classic in their snap installation instructions, in that we ask folks to abide by this but at the end of the day we can’t really control what instructions folks put up.
Additionally, the instructions that they would need to post would then become:
$ snap set certbot plugin-accepted=ok
$ snap connect certbot:plugin some-plugin:plugin
Which actually thinking back on it, perhaps we can make it more obvious to the admins who might run into such commands by changing the name of the configuration option. Something like:
$ snap set certbot trust-plugin-with-root=ok
Unfortunately we don’t have a way to interactively block from inside the hook, save a GUI portal which wouldn’t work for users with headless setups which seems likely given the sort of application that certbot is.
This makes total sense to me.
I haven’t looked into what snap offers us yet, but for what it’s worth, I personally like something like snap set certbot trust-plugins-with-root=ok if its absence causes snap connect certbot:plugin ... to fail. A user could still copy and paste the command, but one would hope trust-plugins-with-root=ok would make people think twice about doing so.
Just to make sure we’re all on the same page, based on @jdstrand’s message, I’m planning for us to implement something like this and go forward with this plan. If there are any concerns about this, please raise them now because I’d hate for us to start migrating our users over and find out that the snap store team isn’t OK with Certbot doing this.
As a member of the reviewers team, IMO this is in alignment with @niemeyer’s points. @pedronis, as architect, can you comment one way or the other if you feel differently?
@jdstrand this is fine in the terms of respecting the spirit but in general is problematic to be up to the snap to enforce this kind of policy. The snap can change after the fact.
Not a blocker for this case here in particular, and we don’t have many classic snaps with slots or plugs ATM and we haven’t fully worked out the semantics in the classic case for those.
But in principle, perhaps if an interface could potentially let a confined snap escape that confinement by a connection to a classic snap, maybe snapd itself should warn when connecting ? similarly to snap install vs snap install --classic ?
Would we do this for any interface? A clear subset? The problem here is that if the set is not well defined automation/use of this via the API might get fragile. Also --classic wouldn’t be quite the right flag to connect for these cross-confinement connections.
I agree in principle snapd should be issuing this warning. I think we need the semantics in place first before we can consider UX. Snapd is in the right place to issue the warning, but it doesn’t really know the context of the connection and the actual consequences of it, so the messaging/arg string would have to be just right. Not saying this is the string, but something like --connection-allows-classic conveys that the connected snap may run with classic permissions so perhaps something along those lines makes sense.
@bmw - ok, feel free to proceed with your implementation. At some point we’ll have something that is better integrated that you can move to (see previous comments).
@jdstrand the snapctl method agreed in this thread no longer works since this upstream regression. It doesn’t look like it’s going to be fixed any time soon, and in the meantime this requirement is causing the certbot plugin mechanism to be broken on Debian stretch.
Could we remove this requirement, please, or have some alternative, if/until upstream fixes the issue?
1 Like