> Docker's currently broken.
that leads to this: https://reviews.freebsd.org/D21570
Similarly Docker was easy to use with images but security was a mess. The first couple of years Docker stance was actually that their container wasn't to be considered a security boundary and being able to access the host system "wasn't a bug". This in total contrast to FreeBSD jails which were always regarded as a hard boundary.
Docker in FreeBSD is not as simple as you might think. FreeBSD has a Linux ABI compatibility layer in order to be able to run Linux binaties (just like WINE is a Windows ABI compatibility layer). Docker itself, the CLI application, the API, etc. is probably the easiest part.
On the more "heavy side" I know that for example Project Fifo has experimental FreeBSD support [2] in case you want to host multiple FreeBSD machines with jails on them.
[1] https://mwl.io/archives/2291 [2] https://docs.project-fifo.net/docs/freebsd
On the official IRC chat some people tried to help, however this patently is not a common issue. How weird. Who wants to install an OS without being able to verify the image seal? Downloading through HTTPS may be MITM'ed, or the image replaced on the server.
I reported the problem. Somebody also reported it more than a year afterwards.
More than 2 years after my initial report... the ticket remains open. At best the BTS seems neglected.
The FreeBSD maintainers probably agree upon the relative importance of those seals, because they publish them at https://www.freebsd.org/releases/12.1R/signatures.html , however this is neglected in documentation ( https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/b... ). BTW I just noticed that the signing key isn't in the strongset ( https://pgp.cs.uu.nl/mk_path.cgi?FROM=8D12403C2E6CAB086CF64D... )
Everyone involved probably thinks there are more important things to do. I don't complain, as nobody "has to" do anything upon this matter.
My point is that such a way to handle this may reveal that most FreeBSD "hacktivists" just aren't willing to do such menial but necessary onboarding-facilitating job, which would IMHO be useful.
It may be part of the reasons why FreeBSD has way less users than it could and should. In a way it is related to "ease of use", however this "image sealing" is more fundamental than bells, whistles and porcelain.
The ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222044
I would like to gain understanding as to why the BSD maintainers + developers invest the time they do into their projects. They are awesome projects, but... who are they for? The 0.1% of people who lie to themselves saying "FreeBSD makes a great desktop/laptop?" Mac OS X makes a great laptop, that's why it is in every coffee shop around the world. Linux must beat BSD server usage 10:1, if not 100:1. I'm sure somebody below will prove me wrong but I strongly feel it's just the echo chamber effect of reddit/Hacker News. I can't think of any good reasons somebody would use *BSD over Linux and "their man pages are great + the clib is written in the same repo as the kernel + userland utilities" isn't good enough of a response for me.
Well one reason could be that you are a commercial company and you make a proprietary appliance. FreeBSD's license (3 clause BSD) is way easier in that case then the GPLv2, let alone GPLv3 (which a lot of userland is licensed in most Linux distro's). Examples of some high profile appliances running FreeBSD: Sony's Playstation 4 and Juniper's Junos OS which runs on their firewalls and routers.
Ubiquiti is getting a lot of flak for not being GPL compliant and the only thing I can think of when I hear this is: "Why did they use Linux if they wanted to make a proprietary product? They wouldn't be in this mess if they had used FreeBSD.".
Another reason could be FreeBSD ships ZFS out of the box because combining the CDDL + BSD licenses is not a problem. However GPLv2 (Linux kernel) + CDDL is a problem.
Any other use cases other than licensing that would make somebody want to use *BSD instead of Linux/Mac?
I've used FreeBSD on my production systems instead of Linux since I started this whole bit 15 years ago. Linux surprises me. FreeBSD, for example, does not. I do not walk away from production FreeBSD systems and have them fall over for reasons other than hardware failure. Full stop.
While it should be fixed I think your overstating the importance here.
99.999% of the world doesn't care about that; No one who installed Windows verified the image. No one who installed macOS verified the image. No one who gets a notebook from a store verifies the install. Let alone everyone who runs stuff in the cloud on a VM, those people have no way at all to verify the OS they are actually running.
> It may be part of the reasons why FreeBSD has way less users than it could and should.
Linux became popular over BSD mostly due to the unix wars [1].
There is no easy or obvious solution here. You can not verify anything PGP unless you can directly (!) obtain the public key from the person in question. So-called Web of Trust is a theoretical construct.
> Who wants to install an OS without being able to verify the image seal?
Well, for example, Ubuntu downloads (and checksums) were available exclusively over plain http until 2018 or so. Flavors are still http.
Jails and Docker are different, but they are both used for process isolation.
It's very common in backend development to run a Dockerized version of Redis/Postgres for local testing/development. A lot of developers develop Go/Python/Rust/node.js/etc. on a Mac, then deploy it to nix. They would need to deploy the same Docker containers built locally (or in CI/CD) to BSD, which seems unsupported given the comments.
I think docker is a glorified zip file, but if that would help popularize FreeBSD more I wouldn't mind that feature. I guess linux compatibility layer could help here as well.
What makes you say that?
Dockerfile is not ensuring that build is fully reproducible, it's just list of steps to build the image. There are many issues with it, but biggest offender is due network access, if you're updating your package repo or downloading a file, there's a high chance that the resulting image is different every time. Dockerfile is as reproducible as a bash script. The only thing that's reproducible is the resulting image, but at that point so is a zip file.