Possibility to port snapd/flatpak for FreeBSD

bledyzer

bledyzer

Hi partners!

I recently studied about sandboxing formats of package distribution like Flatpak and Snap, and I realized that don´t exist ports our plans, at least from the flatpak / snap community, to port snapd or flatpak for others Unix-like operating systems, after some research I undestand that the port efforts is very huge due a hard dependency of Linux kernel features like namespaces, apparmor/Selinux, and seccomp, but I thinking if is no possible adapt some of dependencys for a existing FreeBSD features like apparmor/SElinux to FreeBSD MAC using their resources for substitute a necessity of apparmor for example, or use Jails for substitute namespaces, do you think that the supposed benefits of snap / flatpak packages such as security by isolation and non-need for external dependencies justify port effort?

I personally do not use many snaps or flatpaks on my linux systems, but I like the proposal itself and would be interesting to see on BSD systems, none of the answers I got in the Linux and Snap communitys were very encouraging:

print0.png


print2.png



I do not know how viable such an idea would be, but I do not see any bad in opening the discussion .... Thanks for attetion!
 
I think the bigger issue here is that even if you did manage to port Flatpak or Snapd to FreeBSD, the packages wouldn't necessarily run because their libraries and other dependencies are expecting a modern Linux environment. The FreeBSD compatibility layer for Linux isn't going to work with a lot of existing Flatpak/Snap packages.

Another problem, at least with Snapd, is that it requires systemd. Linux distros without systemd cannot run Snaps. And, as pointed out above, Flatpak requires namespaces, which isn't available.

So porting these frameworks is going to be a huge undertaking that will require a huge amount of work in the kernel and low-level libraries and in many cases will not result in a working package.
 
The FreeBSD Capsicum framework is used for sandboxing and compartmentalizing file descriptor rights for applications.

As far as automatic deployment of sandboxed applications, this can be somehow tied to pkg, but I think the apps themselves would need to incorporate the 'Capability mode' APIs in FreeBSD. I'm not sure though.

Flatpaks/Snaps really have no place on a FreeBSD system. It's a bandaid to a more fundamental problem in Linux IMO.
 
Other than the above I seriously fail to understand the extra gained value here. In my opinion there is absolutely 0 value to gain from porting this stuff over.

Do you need sandboxing for your packages? Get a Jail. Remember: FreeBSD is NOT Linux, ergo it often has different solutions for the same problems.

Best of all is that this solution is available 'out of the box' (no 3rd party software required) and the only possible strain is storage capacity. And even that can be circumvented with some smart nullfs mounts.
 
I don't know what it means, but every FreeBSD11.2-RELEASE-p4 system I've installed this month seems to have an empty /.snap directory in the root directory, which came as part of the install, and would like to know why. It's not a big worry but it is a bit of a concern.

Code: 
$ ls -la /.snap
total 16
drwxrwxr-x   2 root  operator   512 Nov 15 14:55 .
drwxr-xr-x  19 root  wheel     1024 Nov 30 16:45 ..
$ freebsd-version
11.2-RELEASE-p4
$
 
I'm relieved to learn that this comes from snapshots and not snap. I had seen snap residue in the / directory and root account PATH environment variable previously, not on FreeBSD but rather on Ubuntu and/or Linux Mint systems. One of the things that led me away from those systems was realizing that there were a lot of non-standard, seemingly hidden things going on behind the scenes which I didn't understand, and didn't really have the time or inclination to research. For instance I don't like administering a *nix-style system where I'm not allowed to know the root password. It reminds me too much of working in Windows-world. My thanks to you and to Polytropon for this information.
 
Vull said:
I don't know what it means, but every FreeBSD11.2-RELEASE-p4 system I've installed this month seems to have an empty /.snap directory in the root directory
Click to expand...
Your question has nothing to do with that of the OP, please don't hijack a thread like this. It is highly impolite and only diverts the attention away from the actual problem at hand: porting snapd/flatpack to FreeBSD.

Next time please start a new thread and show some consideration.
 
Please accept my apologies. Although I was clearly mistaken I did think it might be related. Exiting thread now & have a good evening.
 
I bumped into this thread by chance today and it made me remember the old PBI Packages of PC-BSD. Many years ago I checked it out on my FreeBSD system and it was great, because I could install OpenOffice as a PBI, which did not exist as a FreeBSD package back then. So my first thought was, why not recover PBI instead of trying to port snapd / flatpack? But then I found this here:

unix.stackexchange.com

PC-BSD PBI, what reasons made it to be scrapped?

What are the detailed specific technical/organizational reasons that the PC-BSD team faced that ultimately lead them to scrap PBI and return to ports? Was because of the difficulties compiling and
unix.stackexchange.com unix.stackexchange.com

The long answer to this question is very well explained there. So the conclusion that I draw from this is that the best thing would be to port desired software to pkg.
 
Yes, please forget about all these things immediately!

There's nothing wrong with wanting an application to run in some isolated environment, but you can easily achieve that yourself, putting it (and its dependencies) in a jail.

The real reason for stuff like flatpak is a different one. It kind of reminds me of the situation on Windows, that always suffered from "DLL hell", so nowadays, software binaries are distributed with all their dependencies bundled.

Software has dependencies, and the root of all problems with that is: different versions might be incompatible. For shared libraries, *nix systems already have a simple and effective solution: libraries have versioned SONAMEs, the version must change on breaking changes, so you can have multiple versions of the same lib installed and the dynamic linker is able to find the correct one. For other dependencies, similar solutions are possible, like e.g. just versioning the names of the binaries. This is also done on FreeBSD, e.g. with python.

But now have a look at Linux world: There are myriads of distributions, and the problem gets worse by them using different, potentially incompatible, compilers, standard C libs, and so on. If you want to distribute your software for Linux and don't want to hope for each and every distribution to get active and provide an up-to-date package, flatpak et al actually help you. But as was said earlier, that's a bandaid. You end up distributing your own little userland with everything-but-the-kernel needed for your app. Another simpler and much older solution would be to distribute a statically-linked binary, but people seem to have forgotten how to do this. 🙈

On FreeBSD, you have a defined base system (including compiler, c lib, etc...). Everyone uses the same, no incompatibilities to expect here. The ports tree is also the same for everyone, if a software needs another library or a newer version of it, update/add the ports. There's no sane reason for such monsters on FreeBSD.

Having said all that, I worked on updating a port these last days where the upstream build system is entirely focused on building such an "everything but the kitchen sink" package, even downloading and building dependencies automatically. It was a major PITA to convince this beast to just build the actual application. It seems devs got tooo used to these stupid bandaids. Not great...
 
Zirias said:
There's nothing wrong with wanting an application to run in some isolated environment, but you can easily achieve that yourself, putting it (and its dependencies) in a jail.
Click to expand...
I am not so sure if that is the intention of people who would like to see snapd / flatpak implemented, but rather to be able to (easily) install certain programs that have not been ported to FreeBSD.
And I must say that your input on this is indeed very informative and explains another point why FreeBSD in some way is better than Linux...
 
cabriofahrer said:
install certain programs that have not been ported to FreeBSD
Click to expand...
FreeBSD can't run linux binaries without a compatibility layer, which is not perfect, specially about those package manager that uses special linux features. Even so, why you need a second package manager that will be used to install an application that will only be used in one OS? Because the selling point of flatpak/snap is "make an application in whatever distribution and run in whatever distribution", while in FreeBSD you'll make a package that will only runs on FreeBSD (which is obviously in the ports). Unless we're talking about contraptions that can't be accepted on ports...
 
Snap and flatpack should probably be supported by the Linux compat environment in the same way that msi, setup.exe and all that other crap is supported by the Windows (Wine) compat environment.

Your best bet is to just extract the Linux binaries out of all that cruft and run them in a Linux emulation chroot. These "technologies" do little more than that anyway minus all the weird loopback mounting and messy stuff like that.
 
kpedersen said:
Snap and flatpack should probably be supported by the Linux compat environment in the same way that msi, setup.exe and all that other crap is supported by the Windows (Wine) compat environment.

Your best bet is to just extract the Linux binaries out of all that cruft and run them in a Linux emulation chroot. These "technologies" do little more than that anyway minus all the weird loopback mounting and messy stuff like that.
Click to expand...
The best shot would be appimage, appimage is pretty much a squashfs with everything inside, so less things to get bored to.
 
Let me share a bit about AppImage. Since I was curious about it I installed it on Linux and found it has no checksums at all. Therefor I contacted the developers. Their answer was:

It is all hosted on github, we trust that.
 
hansw if only checksums were the real issue with weird ideas like AppImage 🙈

But still an interesting anecdote. So, trusting github magically avoids any MITM. Or just some upstream re-rolling a tag, which is typically the base for fetching distfiles of a specific version directly from github. Oh, my. Just adds to the impression they have no damn idea what they're doing. 😳
 
To be honest, I did not even respond to them after that statement. I've seen to many problems with such systems. Old ssl libs in c# by using Xget (can't even remember the name) and so one. Developers stating "I will keep it updated" and then getting bad iso audit results ....

Yuk
 
I would say that, judging from various forums and mailing lists, many Linux users also dislike flatpack and snap, especially snap. The general consensus seems to be that they're very bloated, and slow to start. So, as we've been resurrecting this old thread, I would go with the others who say there seems to be no added value in adding either of them to FreeBSD. (Nor, appimage, going by hansw's post).
 
I think bloated and slow might be annoying but that could be fixed. From a technical view it is just a fat binairy. Some thinks like Flatseal might even do good but damn, it is such a waste of resources.... Most Linux users do not care I think, or are not even aware (pointig at the Ubuntu users). They might have read it makes it possible to do more.
 
hansw said:
I think bloated and slow might be annoying but that could be fixed. From a technical view it is just a fat binairy. Some thinks like Flatseal might even do good but damn, it is such a waste of resources.... Most Linux users do not care I think, or are not even aware (pointig at the Ubuntu users). They might have read it makes it possible to do more.
Click to expand...
Fat binaries. To me, these packaging things aren't much different from old fashioned static binaries. "Lets bundle everything our application needs into a single executable" vs "lets statically link everything our application needs into a single executable"

Yes I know that's a gross over simplification, but the end result is basically the same.
 
mer said:
Yes I know that's a gross over simplification, but the end result is basically the same.
Click to expand...
Agreed. And I strongly suspect that if developers hadn't made this too hard for themselves (i.e using languages requiring big interpreters, incorrectly engineered libraries like Gtk that can't statically link), we would likely just be doing that. Clean and simple.
 
You must log in or register to reply here.
Back
Top