Hacker News Reader

Comment by RaleyField | Hacker News Reader

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>

View on HN

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

Reply on news.ycombinator.com