Hacker News new | past | comments | ask | show | jobs | submit login
OpenBSD binpatches and package updates (mtier.org)
65 points by crasm on Aug 8, 2016 | hide | past | favorite | 39 comments



What this means:

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!)


The issue of official binpatches is not a critical problem, but it is still a problem. It is a security and usability issue simply not present in the vast majority of nix systems, and that should be acknowledged rather than downplayed, as this facet of OpenBSD is usually an unpleasant surprise for potential converts.

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.


OpenBSD does not try to be everything for every person and I think it's fair to put some things in context. Just because other systems provide binary patches for security issues (and I haven't so far named and will continue to not name other OSs, but many have a lousy track record of doing so to begin with), that does not make them automatically more secure than OpenBSD, which has so many active pro-security measurements built in from the start and where updates are provided, but not officially via binary patches. I think a lot of the comments did not acknowledge the circumstances and see the greater picture and my sense of a need for some further context was justified.

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...


While mtier may have exaggerated the difficulty of updating from source, "...writing a 20 line script to get notified if the page is updated, that's enough [...] updates are trivial: update, re-compile, reboot" downplays the hassle a little too much. Your procedures are fine if you only have to update one machine, but they are inefficient when you have multiple machines to update. Furthermore, OpenBSD doesn't need a lot of RAM nor disk to run, but to compile is a different matter. This is not a problem (at least for i386 / amd64) for physical machines made in the last 15 years, but is a concern for VMs. IME, w/o X11, OpenBSD (i386 / amd64) runs fine w/ 64 MiB of RAM, but needs 512 MiB of RAM to compile (excluding X11) without swapping.

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.


Appreciate your comment, interesting! :)

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!


"Keeping your installed OpenBSD packages up to date is hard and time-consuming."

I find it very easy. I follow stable and upgrade every six months. Upgrades take about 30 minutes max.


You are talking about base, they are talking about packages (and -current base).


I mean the system in general. I get new ports (like everything else) every six months. And when security flaws are discovered in third party software, they are fixed in the -stable branch of the ports tree.

https://www.openbsd.org/faq/faq15.html#PortsSecurity


Maybe you don't want / you do not have the chance to have sources and build tools installed on your production server and you trust mtier to build the patched sources for you. I find it very useful.


You don't update core/packages when there are security issues? How do you deal with this? I'd like to know alternative approaches to applying patches and recompiling. Thanks!


The alternative is to use openup from M:tier.


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.


The OpenBSD project doesn't have the resources to provide this so m:tier employs a couple of OpenBSD developers to provide this option for people who want it. Not sure what is embarrassing about this.


The fact that virtually every other nix system, large and small, can provide this standard functionality, and the OpenBSD project cannot. Having to rely on third parties for convenient updates is an obvious potential security issue. Firstly because it discourages updates in the first place, but secondly because I now have to trust m:tier as well as the OpenBSD devs.

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!


If openbsd developers do it, why don't they make it official and provide it from openbsd.org? They could still plaster "this is thanks to funding from mtier" on the site prominently.


The OpenBSD developers are unwilling to do anything that makes some architectures better than others, and M:Tier is unwilling to build stable updates for everything. Perhaps this will change one day as hardware continues to consolidate, but that's the way it is for now.

http://www.openbsd.org/plat.html


As far as I know, the patches are submitted to the -stable ports tree. mtier just provides a very convenient way to perform binary updates.

I fail to see any downsides to this arrangement.


Why would anyone find it embarrassing that OpenBSD is not RedHat? They don't have the staff or the funding to curate an operating system and all the ports. Rather than do a poor job maintaining a large code base they prefer to do the best job they can on the core OS. What's embarrassing about that?


Nobody is suggesting OpenBSD not being RedHat should be embarrassing.

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.


The traditional means of patching is recompiling from source. That is the ONLY officially supported method.

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.


I think there would be no problem with OpenBSD supporting an automated build-and-recompile tool, that would be perfectly fine and would stop people like me bitching about updates. Yeah yeah "it's trivial for you to write etc etc" but that's not the point: it's like saying that developing a text editor is simple so we shouldn't provide vi. This sort of thing is better designed and implemented by people who know the OS inside out, not by users.


For what it is worth the project does provide regular binary updates for both the base system and ports for -current (snapshots). If I were to guess, I would guess that one of the reasons that the project does not provide binary updates for -stable is because they are busy providing binary builds for -current. Since all the devs run -current, you can see which one they choose to invest their limited resources in.

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.


The problem is that the OpenBSD team doesn't want to write and maintain a tool like that, and they also don't want to utilize their sparse resources hosting the necessary package build infrastructure for all of the architectures they support. They are volunteers, so it really is up to them to work on whatever they want to work on.

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.


> it really is up to them to work on whatever they want to work on.

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.


> 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?

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.


> So you're begrudging some of the OpenBSD developers for having a day job?

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.


> 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.

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.


> 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 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.


We are not talking about the same thing. I am not arguing they should be more responsible for third-party codebases, this is not an issue of ports vs base. This is far more an issue of infrastructure, of source vs binary. Simply offering binpatches for their core OS would still be a huge step forward.


You can always stick with the release binaries, which are unchanged.. or follow -current development by periodically upgrading to snapshots, where you can find more up-to-date binary packages. This is what developers run on their laptops, and often in production. It's sort of a "rolling release".

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.


It's what's blocking me from trying it. I don't want to spend time to micro manage my desktop system and applying security patches involves lots of time. They should bless certain architectures (amd64) and certain packages (chrome, firefox, one DE) and keep binary patches available for those, everything else can stay the same (i.e. binaries on release). I also don't want to try third party services for updates because I'm not sure if I can trust them. I know core OpenBSD team can run a tight ship but other OS teams have shown that's not always the case. Irc the excuse is that openbsd is now a research operating system, but lack of funding probably plays into this as well. So everything is broken as per usual. </rant>


> ... I'm not sure if I can trust them.

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.


The idea that we outsiders have to research mtier to decide that it's not very much of a third party after all is just odd.

I don't want to seem adversarial, and I want to like openbsd, but it's hard.


I said it before: if the people running mtier and openbsd are basically the same, the fact that they are different organizations invites speculation as to why that might be the case. In the spirit of trust and full-disclosure, it would be good if this situation were made transparent. At the moment there's a lot of "these packages are not blessed but they're from the same people wink-wink-nudge-nudge".

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.


With the amount of software you likely run on a desktop machine, your implicit web of trust is already pretty huge. Does trusting mtier really make that big a difference? How does it compare to the maintainers-and-build-bots infrastructure of other open source operating systems? I think this sort of hang-up is an example of letting perfect become the enemy of good, and it's something I have to push myself through from time to time.


> How does it compare to the maintainers-and-build-bots infrastructure of other open source operating systems?

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?


> Most other operating systems are badly run as well. Doesn't mean that adding another layer of potential insecurity is justified.

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.


> Besides, which harmful thing is more likely to happen, your package repository gets owned, or someone sends a maliciously crafted request to your server?

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.


> 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: