6 ms·

OpenBSD binpatches and package updates

65 points by crasm 10y ago

w8rbt 10y ago
"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.
- phaer 10y ago
  You are talking about base, they are talking about packages (and -current base).
  - w8rbt 10y ago
    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 https://www.openbsd.org/faq/faq15.html#PortsSecurity
- invernomut0 10y ago
  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.
- carlesfe 10y ago
  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!
  - ams6110 10y ago
    The alternative is to use openup from M:tier.
can09 10y ago
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.
- OrpheanBeholder 10y ago
  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.
  - can09 10y ago
    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!
  - saean 10y ago
    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.
    - sdkmvx 10y ago
      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 http://www.openbsd.org/plat.html
cisstrd 10y 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!)
- can09 10y ago
  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.

65 points by crasm 10y ago

w8rbt 10y ago

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

phaer 10y ago
You are talking about base, they are talking about packages (and -current base).
- w8rbt 10y ago
  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 https://www.openbsd.org/faq/faq15.html#PortsSecurity
invernomut0 10y ago
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.
carlesfe 10y ago
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!
- ams6110 10y ago
  The alternative is to use openup from M:tier.

can09 10y ago

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.

OrpheanBeholder 10y ago
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.
- can09 10y ago
  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!
- saean 10y ago
  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.
  - sdkmvx 10y ago
    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 http://www.openbsd.org/plat.html

cisstrd 10y 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!)

can09 10y ago
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.