Hacker News new | ask | show | jobs
by cisstrd 3603 days ago
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!)

2 comments

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!