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!
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.
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 find it very easy. I follow stable and upgrade every six months. Upgrades take about 30 minutes max.
Some people wanted bin-patches apparently, openbsd is heavily focusing on using its resources as efficiently as possible and doesn't provide them, a reliable 3rd party stepped up providing them for free, charging for binpatches for older versions (a service model built on top of open source software, nothing wrong with that)
A few points:
-) since mtier here tries to basically sell you something, they make it sound harder than it seems, checking the errata page, writing a 20 line script to get notified if the page is updated, that's enough
-) not every bug found is critical towards your own security, not every bug does need you to update (you can decide on an individual basis)
-) micro-managing (as one comment stated) is pretty much the opposite of what you do with openbsd, openbsd is secure by default, if you want to have anywhere near the same amount of security with some other OS have fun reading tons of documentation to harden the box yourself (and you still won't have all the same security mitigations)
-) updates are trivial: update, re-compile, reboot, if the bug is not critical for you then don't, or use -current (rolling release "development branch"), or use the bin-patch by mtier
-) I doubt some of the people here criticising "having to use" 3-rd party binpatches practice the same scrutiny in day-to-day life regarding it-security (seeing how other OSs deal with security they would probably be using openbsd by now then if they were)
-) considering the size of the openbsd project and how many critical pieces of security-focused utilities they maintain (openssh, libressl, opensmtpd, ...), how many security mitigations they implement, how well they do in regularly auditing their code and actually addressing bugs across multiple architectures quickly with patches provided (especially compared to so many so much larger projects), it's somewhat ridiculous for an outsider to criticise how they spend their time or resources (because in my opinion and in the opinion of many others, they actually do hell of a great job!)
Repeating "secure by default" seems rather disingenuous when a freshly-installed system needs extra attention, and cannot automatically fetch the latest security updates.
Updates may be "trivial" to you, but they are still clearly more complex than the average system, as they require individual attention and recompilation. These speedbumps to security are not what "secure by default" implies.
Alternatively, relying on a third-party tool (and having to vet that extra party) is not "secure by default" either.
Your final points are distracting from the issue and verging on ad-hominem. Firstly, first-party binpatches are so prevalent that noticing their absence is hardly significant scrutiny. Secondly, just because OpenBSD is very good in some areas doesn't mean we can ignore deficiencies in other areas.
But your original comment was: "Does it seem a little embarrassing to anyone else that this is necessary? OpenBSD is supposedly the most secure nix platform available, and yet users have to resort to third-parties to get functionality that is available on nearly every other nix system by default."
So no, I don't consider it to be embarrassing for a little project that does so much in so many ways (part of it being that every single security issue is addressed and patched swiftly across multiple architectures, full disclosure is practised et cetera) to not provide binary patches while having an experienced community accepting of this. This last part actually what makes OpenBSD such an efficient catalyst for innovation, since people accept breaking backwards compatibility, turning on security mitigations while it might brake some stuff here and there, et cetera...
For my use case, I set up a dedicated builder VM, have it build a full release, then "upgrade" the other VMs with my local build. Although the installer only officially supports upgrading from version N to N+1, IME it seems to work for N -> N "upgrade" as well. This is workable and not too complicated, but it's definitely not trivial.
That said, to me mtier doesn't provide enough value, either. Prior to me setting up a dedicate builder, I probably would be interested, if they provide support past upstream's support period. 1.5 years is not "LTS" to me.
Maybe I downplayed it a little bit too much, probably can't deny it, but it was in reaction to people making (imo) too big a fuss about it, while criticising a project which - with limited resources and manpower - does an extraordinary job on the whole (as many - myself and most likely you included - could agree on).
A lot of people who utilize OpenBSD like you do most likely have the skill-set to deal with it in a similar manner as you have though, or can pay for commercial support. Thanks again for the insight!