That is why I say embarrassing - they are one of very few projects to lack this feature, and this feature is an important part of a secure system. OpenBSD is all about being "hands off" and "sane by default" and yet paradoxically their update process is much more involved and hands-on!
I fail to see any downsides to this arrangement.
However, it is not ideal to have a security-focused OS not directly provide binpatches for the base system and core libraries like libressl. Trusting OpenBSD.org is one thing, but trusting additional entities like mtier, etc. just to get security updates without having to compile is another.
FWIW, I think we should feel embarrassed about not giving more funding & time to OpenBSD given everything they already do for us.
http://www.openbsdfoundation.org/campaign2016.html
Maybe someone at OpenBSD Foundation should get itself listed at smile.amazon.com and make it even easier for people to contribute.
This is just another convenient option. I fail to see the problem here.
If you want supported first-party binary security patches you should be using a project that provides that, such as FreeBSD, or just about any Linux distro that is not Gentoo.
Additionally, the amount of security patches we're talking about here is so small that just updating from source code really isn't that big of a deal for most people.
Sure, and it really is up to me to keep bitching :)
Besides, the contradiction here is that they are not all volunteers: M:Tier employs some of them exactly to do that job. So, they don't want to do it, but they'll do it if the price is right? Why can't this pricing be done transparently through OpenBSD, rather than some obscure third-party company?
If the problem is funding, why can't they do like RedHat or Oracle, who ask for money to provide automated updates? Oh yeah they do, but through m:tier for some sort of reason (tax? street rep? We can but speculate).
> just updating from source code really isn't that big of a deal for most people.
It's enough to keep the m:tier service running and people like me bitching, so clearly for a lot of people it is. It's enough that every other linux distro out there does it. Denying it over and over won't change that.
So you're begrudging some of the OpenBSD developers for having a day job? That is completely absurd. How are they supposed to feed themselves and their families?
Several of FreeBSD's core developers work for Apple. Red Hat employs a large chunk of the GNU and Linux ecosystems. Red Hat actually does something very similar to what M:Tier does.
M:Tier is really just another example of a company that is providing value added support over the offerings of a freely available open source project. They are even generous enough to provide their openup script under an open source license and binary updates free of charge for the most recent version of OpenBSD. I think that is a pretty good deal for everyone involved.
Au contraire, I begrudge why they have to do their OpenBSD-related day-job, working on what is basically an essential part of any modern OS (update distribution infrastructure), outside of the official project and with no official endorsement. It devalues them, it devalues the project and only invites speculation on the motives of such arrangements.
> Several of FreeBSD's core developers work for Apple.
Do I have to pay an Apple subscription to get automatic FreeBSD updates? No.
> Red Hat employs a large chunk of the GNU and Linux ecosystems
Sure, and I do have to pay to get automated updates from them, but at least I know they are official. M:tier packages are not official but sort-of wink-wink-nudge-nudge. For a project living and dying on trust, it's a poor show.
> M:Tier is really just another example of a company that is providing value added support
Sure, but my point is that OpenBSD is a pretty isolated example of a project that actively refuses to provide what any comparable project provides, with very flimsy excuses. This leaves the space open for m:tier to make a buck that really belongs to the OpenBSD project. IMHO the project (which is otherwise extremely fond of reminding us that they are short of money) gets shortchanged here, even if some individuals might not be.
Well that is because the official and ONLY supported way to patch an OpenBSD system is to compile from source. Like pretty much all of OpenBSD's documentation, the instructions to do so are very clear.
M:Tier provides a service that is merely a convenience. It is not essential and I would suspect that only a small fraction of OpenBSD users even make use of their openup script and binary package updates at all.
I suspect you are being purposely obtuse and cannot understand that the way in which your favorite $OS is not the only right way to do things.
The OpenBSD project has no obligation to provide binary updates. They provide source code patches and clear instructions of how to apply them. This is actually better for security because you can actually see what is being changed by the patch if you know a little bit about programming.
The OpenBSD project actively refuses to provide a service that pretty much any other OS project provides, so that a commercial entity can make a buck, and I am the one being purposely obtuse?
> only a small fraction of OpenBSD users even make use of their openup script
Until it relies on m:tier servers, of course. Why would I have to trust an unrelated company to update a security-conscious OS?
> This is actually better for security
This is actually worse for security because it relies on sysadmins being human robots that constantly check errata, or being faultless programmers who will never botch a hacked-together-enough-that-works custom script to get errata and apply patches. But hey, don't take it from me, hear it from m:tier themselves: "Keeping your installed OpenBSD packages up to date is hard and time-consuming. Nobody wants to read the mailing lists to spot security fixes and/or updates never mind wanting to build new packages from their ports tree and manually install them on each of their servers and/or desktops."
QED.
Following current is pretty simple if you're happy to track snapshots, which are updated regularly (usually every week). If you're worried about stability, remember that -current turns into -stable twice a year, so current is pretty stable, and any issues that do crop up get fixed very quickly, because they impact the developers.
There aren't enough resources or interested developers willing to handle -stable package builds, but the ports tree is tagged each release and receives select backported security updates, which you can build yourself.
Might I suggest looking into who it is at M-Tier that's producing these packages? It's not just some random third-party.
FWIW, the openup tool makes things extremely easy and it certainly doesn't "involves lots of time". Run "openup -c" from a cronjob and, when you get an e-mail saying there are updates available, log in and run "openup". Kick off a reboot if the kernel/base was updated and you're good.
I run several OpenBSD boxes in production. Don't let this be what stops you.
I don't want to seem adversarial, and I want to like openbsd, but it's hard.
Nobody else does this, not even small distributions, and tbh the excuses are really thin - especially for a project so committed to security and transparency.
Most other operating systems are badly run as well. Doesn't mean that adding another layer of potential insecurity is justified.
> Does trusting mtier really make that big a difference?
Yes. Is mtier running similar ship to mint? Do you have convincing argument that they don't?
But if you go with another OS, that's the system you get and you miss out on the nice vulnerability mitigation technologies that are built into OpenBSD. Besides, which harmful thing is more likely to happen, your package repository gets owned, or someone sends a maliciously crafted request to your server?
> Is mtier running similar ship to mint? Do you have convincing argument that they don't?
I have no idea what "running similar ship to mint" means or implies.
If you have ports closed because you run desktop then the former? It's fine do a little admin work (or it be a job of itself) on (production) servers, it's not if you just want to have secure desktop, which was my original complaint. Besides, there are plenty of examples in various projects where downstream got compromised, so why introduce another link that can potentially break.
> I have no idea what "running similar ship to mint" means or implies.
That they shipped infected isos. There are other examples where you'll see brilliant engineers give little to no thought to security, the fact that m:tier guys might contribute great work for openbsd doesn't mean that they can also keep artifacts secure and I as the end users shouldn't have to play sherlock to figure out if I can trust them.
If you don't trust them, then apply the errata yourself and compile from source. It's not that difficult. If you have many machines you can do it on one, build a release and roll that out on the others.