Hacker News Reader

Comment by alberth | Hacker News Reader

[flagged]

I hung out with Theo and his team years ago at a security conference. At the time, Subversion was the new hotness, sweeping away CVS as the source code management system de jour. I asked Theo why they didn’t already move to Subversion. His answer stuck with me: CVS is dead simple, everyone understands it, and it just works. Why complicate things?

And that’s the philosophy behind much of OpenBSD. They focus on being able to understand everything from the build tools to the command line tools. Nothing random ever makes its way into OpenBSD (aside from the random number generator, which is ubiquitous). Only a few chosen hands ever commit a line of code to their holy codebase.

they seem to focus on correctness over features. So jails for example would be a lot of complexity.

Rust, if I am not mistaken, has some quirk with the compiler backend that OpenBSD does not like.

Theo also mentioned:

>Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

Regardless: The system being secure is a secondary benefit to it being comprehendible and coherent to an individual. It's not enough for the output of a magic box to be a better widget, even if the widget is better in every measurable way. The box itself must not be magic.

Using a static code analyzer, as well as adoption of Rust (which reduces the need for a static code analyzer) - squarely fit in the correctness camp, no?

Note: I'm not a Rust fanboy. But it just seems like Rust aligns very well with OpenBSD core principles.

You can be both intelligent and a competent programmer while not liking rust. The same applies to functional programming.

The Rust thing comes up all the time, and Theo already addressed the issue[1]. Basically it boils down to speed and the fact that OpenBSD runs on some pretty slow hardware and require the full OS to be build on actual hardware.

As for the immutable OS, OpenBSD went the other direction and relink the kernel on each boot.

[1] https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

> the fact that OpenBSD runs on some pretty slow hardware

This is one of my favorite aspects of OpenBSD. I play with a lot of retro hardware and running OpenBSD is an excellent way to make any old hardware feel like new.

Oldest real hardware I've run it on is a 486 DX2-66, oldest virtual hardware was a 386 using OpenBSD 4.1. Also ran a Pentium MMX as a WiFi router for a few weeks while sourcing a replacement.

Despite the "i386" name I don't think contemporary OpenBSD will work on a real 80386 or 80486 system. The supported hardware is described as: "All CPUs compatible with the Intel Pentium or later, with Intel-compatible hardware floating point support should work."

There is also a note: "Due to the increased usage of OpenBSD/amd64, as well as the age and practicality of most i386 hardware, only easy and critical security fixes are backported to i386. The project has more important things to focus on."

I would guess they are not too far from dropping support entirely, but as I understand it that all depends on whether there are any developers interested in still working on it. The OpenBSD developers build the OS for themselves. They make it freely available to anyone who finds it useful, but they do not really build it for "the users."

You're correct, 386 support was dropped after OpenBSD 4.1 (May 2007), and 486 support was dropped after 6.8 (October 2020). If I recall correctly, the project compiler changed after 6.8 and wasn't able to build the entire ports tree when targeting the 486, so they now target Pentium (i586) and higher.

Even though it's technically out-of-date and unsupported, an OpenBSD release from 2020 is still pretty impressive for the DX2 (1993). :)

ActionRetro has several videos where he puts it on G3 macs:

https://www.youtube.com/watch?v=rT71HwfiM_A

The root of the issue actually appears to be that OpenBSD still supports extremely old and slow architectures (that struggle to build itself):

  alpha 
  amd64 
  arm64 
  armv7 
  hppa 
  i386 
  landisk 
  loongson
  luna88k 
  macppc 
  octeon 
  powerpc64 
  riscv64 
  sparc64

For a project with such limited resources as OpenBSD, it seems wise for them to drop support for a large number of these legacy platforms and focus on more widely used architectures.

I understand that, supporting more architectures actually help uncover more bugs. But you could still do that with a supported platform list that is 1/2 that size.

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

Look at what DragonflyBSD has been able to accomplish, truly competitive with Linux regarding performance and features, with the smallest development team out of all the BSDs.

They can do this in large part because they focus on only 1 platform (supporting arch64).

But it isn’t a business that can shuffle human resources at will.

Your point reminds me of Theo losing his shit about how long it took me to build the CD release images I was responsible for. Poor machine crunched for more than a week to do it.

Over the years they have dropped support for a number of platforms[1], but they don't do it based on "popularity" but more whether there are developers (with hardware available) who are interested in working on it.

[1] https://www.openbsd.org/plat.html

Not to deny some of those are useful suggestions, but they don't square with the core OpenBSD philosophy. And despite not having these items, they are more secure than products who use them.

It is hard to call OpenBSD an OS focused on security. Beyond pledge their primary focus seems to be "just implement everything correctly and don't run malware". If some utility has an implementation error or you do accidentally run something malicious you are hosed. Compare this to Linux with the extensive use of containerization and things like eBPF for dynamic security measures, or portals as part as flatpak for dynamic application permissions.

> Compare this to Linux with the extensive use of containerization and things like eBPF for dynamic security measures

I think it's an interesting comparison study and I'm not convinced either way of The Right Approach. OpenBSD takes the approach "keep the attack surface as small as possible" while Linux takes the approach "let's bolt a bunch of layers together... good luck making your way through all of it"

So many misconceptions in the same answer. eBPF is for observability, and letting you run privileged programs inside the kernel space (even with protections) can actually increase the potential attack surface. Containerization is not and was never a security measure.

eBPF is used for substantially more than observability.

Most of your comment it's bullshit. Containers are not for security, but for convencience and task separation/isolation to avoid the overhead of a vm. eBPF will expose you further more, not less. Also, how can flatpak secure you against a ~/.profile script run at login or an ~/.xprofile one?

A malicious program is going to have a difficult time adding something to your ~/.profile script if it cannot access your home directory. Although I don't doubt that many flatpak programs have too lenient default permissions, and the various XOrg lack of isolation issues are unfortunate somewhat remedied in wayland.

OpenBSD is implementing Wayland if you like it instead of Xenocara.

Again, in which way it's any GNU/Linux distro better then?

See: https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayla...

Wayland does not stop a process from manipulating the home directory, doing various things on the network, using a ton of memory, recording what other processes exist etc. Once you add all that stuff you start to get something that looks a lot like containers.

OpenBSD has limits.conf and acct(8). Again, RTFM.

Obviously OpenBSD has some limited mechanisms for managing RAM usage and open file descriptors, just like every other system.

> - Rust adoption (for the memory safety benefits & reducing the attack surface of the OS)

For some reason the rust evangelism task force looks the other way when looking at all the claims that OpenBSD does.

Reply on news.ycombinator.com