Snapd is outdated in many distros (Debian, Fedora (though only just - how long does it usually take for a new version to get into Testing and then how long into release?), Gentoo, openSUSE), not in Mageia or RHEL/CentOS at all, and for Arch, Gentoo, and openSUSE is not in the official repositories.
I think this person’s approach is a little unfair since they’re taking a particular point in time that may not be representative of other points but snapd should be up-to-date in all supported distros at all times really…
I’ve just noticed Zyga’s comment on that post, re-exec is apparently going to be available soon on Fedora and openSUSE, so if they opt-in then it will be up-to-date there (though not necessarily always up-to-date in the repos).
The re-exec functionality is disabled in Fedora’s snapd. I do not intend on allowing re-exec in Fedora because it makes it impossible to make adjustments to snapd specific to Fedora. The fundamental issue with re-exec is that there’s only one provider of the “inner snapd”, and that’s the Ubuntu one. As there are differences between Fedora and Ubuntu for most functionality, this wouldn’t work well in practice.
In addition, I fundamentally find it difficult to trust giving privileges to a binary that wasn’t built by us in Fedora Infrastructure, especially given that this is a system for confining arbitrary applications that aren’t vetted by people generally. If you think about it, it makes no sense to allow a foreign trust like that for something that ultimately could control the entire system.
I would be very surprised if someone in another distribution shipping snapd discovered this and could not control the re-exec target would be happy about this. In fact, I would expect that most distributions, once they know about it, will disable this functionality because it’s fundamentally very dangerous due to the inability to re-exec to trusted binaries.
What do you mean by this? That the core snap is too Ubuntu-based? Perhaps the snapd team could provide more guarantees on this… But yes, I guess due to the fact that snapd is exclusively governed by Canonical it’s going to be hard to trust to quite that level. If the governance were more collective then maybe that would be different. Like, yes, it’s open-source, but it’s Canonical who ultimately push out the core updates which is what would be of concern here…
Aren’t users are responsible to trust certain developer instead of distros? If the user doesn’t trust snapd they shouldn’t install it in the first place.
I think @Conan_Kudo’s concern is that it’s in the official repositories (so people would be trusting it because the package has been checked by Fedora devs) but updates would be rolled out before Fedora can approve them (and has a lot of access to the system)… Though the access point is a tad problematic, because no application has root access without asking for the password?
Well, snapd is being split out of the core snap, but the problem is that it’s still built by Ubuntu for Ubuntu. Which is fine for Ubuntu, but most distributions would probably not like this idea.
That’s one part of it, but the other part is that in the event I need to patch snapd, re-exec effectively nullifies my patching to fix things. From time to time, I have to make special adjustments for snapd to work correctly in Fedora, either in the form of backports or something else. However, re-exec effectively makes those pointless because the functionality won’t ever take effect.
This is actually a rather scary proposition, because if I had to modify something in snapd to be able to make it behave correctly in Fedora (or do something completely different for reasons), then it wouldn’t be able to take effect because I cannot publish the necessary snapd snap using Fedora tooling to make sure my changes take effect.
This is effectively a trap, because I don’t actually have the ability to improve the software for Fedora users if re-exec is enabled.
Do you have a link for this? I thought the idea was that snaps are now core[+base+content]+app? The core snap is still essential, but there can be a base snap too?
Can’t you submit a PR or bug against snapd to indicate that it’s broken on Fedora? Also, shouldn’t regressions with new versions of core be caught during beta/candidate and then you can ask for it to be blocked from stable until the regressions with core on Fedora are fixed?
I don’t think it has been formally announced yet, but it’s mentioned throughout the various PRs going in to support Ubuntu Core 18 (which is sadly being called core18 instead of ubuntu-core18). The PR to remove the core-support interface, for example, mentions it.
Sure, but that’s fundamentally worse than what I can do now, which is more or less fix things relatively immediately. As for blocking things based on Fedora issues, I don’t know if the team would be willing to do that. To be quite frank, our testing of snapd in non-Ubuntu is somewhat buggy and incomplete.
Testing against Fedora and openSUSE gets regularly disabled or thrown to manual activation due to issues in the infrastructure, which means that the testing picture is nowhere as complete as it probably should be.
Honestly, I don’t think so. Testing being better would obviously be great, but there are fundamental issues with the whole concept of re-exec that I don’t think I’d ever really consider allowing it. The only reason it exists is to bypass the distribution for snapd itself, and that’s a problem, since you can’t confine the thing that runs the confinement.
Fedora users trust me to make sure that I provide them with what they expect. And re-exec is pretty much counter to that.
That doesn’t sound like a good experience either, I think the one enabling re-exec should be an unofficial package provided in an external repo, if we have to have non-re-exec by default. Two official packages sounds less user-friendly.
I was about to say that this shouldn’t be a problem since traditional packages don’t have any confinement anyway but I guess what you mean is that unconfined apps do have the safeguard of being upgraded by the distro and re-exec wouldn’t have that. It’s a fair point… I guess Firefox in Ubuntu repos, for example, doesn’t automatically update even though it could.
