CC @sergiusens and @kyrofa
1 Like
I’m not sure where that is documented but I’ve not seen it officially anywhere. People are for example using ssl, system python, etc, etc, etc, etc.
well, it was the initial idea of snappy and is also an essential bit to be able to independently upgrade pieces of the system.
snaps have to be self contained … ssl is a bit special here since we commit to provide access it with a very recent PR (that is only in edge yet AFAIK).
allowing snaps to depend on random bits in core breaks the whole concept of being self contained and independently upgradeable.
if we want to step away from the original ideas we need to start adding dependencies to snaps to allow tieing a snap app to a core api … (i’m fine with that but this wasnt the original concept)
I can’t speak for the design of the whole system, but indeed, in snapcraft we use the contents of the core snap as a list of things not to pull into the snap. Also, as @jdstrand mentioned, we haven’t discouraged people from using the in-core python3. What about awk? Sed?
1 Like
well, interpreters are something different than libraries IMHO …
In my opinion we need to treat available parts of the core snap as a public ABI. If it’s public, maintain it for at least this series. If it’s not public, make sure it’s not accessible through confinement.
It was also stated that once core was stable for a particular series, then people could depend on core not breaking ABI for the duration of the series. This is at odds with the concept that snaps are self-contained. The rsyslog removal changed that in and of itself but also for the dependencies it brought in that are now gone…
If you consider core a runtime and you ship libraries and files in that runtime then IMHO I don’t think we can take the hard stance you are asserting. People are already doing this-- this is but one snap. We’ve allowed use of shipped libraries, utilities, shells, python, perl, etc up until now. We could adjust the security policy to only allow the libraries, utilities, shells, interpreters, etc that we explicitly want to allow, but this has been discussed before and the decision was made that we should allow access to all the libraries. IMHO we should not be removing things from stable series 16 but can revisit for the next stable series.
Rsyslog decision was made and it is gone, so perhaps just seed the libraries that weren’t getting pulled in?
well, if we add an ABI we need to add versioning and dependencies …
The core snap is today our own and only base snap as well, and the point of base snaps as the name indicates it to offer a common base for applications to be built upon. As such, we can’t take content out of them without the due diligence and care for snaps that are already published out there. Being on the consuming side of a thing you don’t control and that offers no guarantees of stability is a nightmare no sane software maintainer will accept.
At the same, and just to be clear, that’s not a promise that the core snap will never change, as we’ve been recently discussing around the issue of rsyslog.
Coming back into the case at hand, this looks like a general and common library that was already accessible, so we cannot take it away.
3 Likes
This is more difficult than might first be thought since if you think about it, all the libraries are on the system because they are needed by the seeded packages for core. In other words, if we allow a utility to be used in confinement, the confinement must allow that utility to use the libraries it needs. If that utility is allowed to use it, the library is available for use by anything in the snap. This becomes a huge maintenance burden to figure out what libraries are needed by what utilities that needs to be coordinated with whatever interfaces use the utilities. Ultimately you end up with a default policy that may have a reduced number of libraries but with each plugged interface you end up with (nearly) all of them, so this exercise becomes impractical and ineffectual.
1 Like
+1 I suggest seeding libjson-c2 and anything else that is missing that rsyslog was pulling in that an snap might’ve been using.
apart from libjson-c2 only libestr0 was dropped alongside when rsyslog went … i have seeded both back now and they should be available again in the next edge core snap.
1 Like
Thanks @ogra I note in your update
dropping rsyslog also dropped libjson-c2 and libestr0 the former is
- apparently linked against inside core from the mir-kiosk-apps snap …
- this is a bug in the snap and should be fixed … meanwhile we’ll seed
- libjson-c2 and libestr0 back into the core snap for now.
We are using the same design in our apps so should we include them as part of the snapcraft.yaml config?
based on the above, you can just leave it as is …
Ok thanks, just with you saying it is a bug in the snap wondered if we should do something differently. Thanks for your help with this one!
Well that is a conflicting statement since we were told by Mark to rely on things on the core snap, it is a base to depend on after all.
Is this why you CC’ed @zyga-snapd? Some context on why would be nice next time.
So I used build-attributes: no-system-libraries, which is why libjson-c2 was not included in the snap originally. Not sure what the guarantees are around that declaration.
Yes and I agree with that statement. I think we must not remove any shared library from the core snap during the 16-series lifetime. I wanted to CC you as this is an important verification of this policy.
1 Like
Hi all,
i did run mir-kisok snap on my ubuntu 16.04. Then i got a colored blank window. It stuck so long like that and even if i reboot i’m facing the same problem,that snap is getting autostarted immediately after reboot. now how can i remove that snap so that i can use my system as before.kindly help me on this.
i managed to recover my system.
Thanks
1 Like