> The discussion is relevant if you believe that an OS should have some responsibility for memory-related security issues. Pedantically speaking, your point is

> The discussion is relevant if you believe that an OS should have some responsibility for memory-related security issues. Pedantically speaking, your point is valid. But as a practical matter, OpenBSD is the operating system that takes these issues the most seriously. They formalized the notion of Unix-based privilege separation, and systematically employed it across the system. They regularly perform system-wide code audits (including of bundled software, such as Apache back when they actually bundled Apache) to identify and remediate high-risk source code patterns (e.g. strcpy -> strlcpy, realloc -> reallocarray, etc). While people [still] debate the merits and performance of things like seccomp or Capsium, OpenBSD has incorporated pledge(2) into the vast majority of binaries on the system. They were the first to apply stack canaries, ASLR, W^X, and most recently PIE globally by default. And apropos the article, they were the first to implement their system malloc in a robust way that maximized the chances of catching memory bugs, sometimes sacrificing performance in a way that would be inconceivable for Linux distributions. And all of these things have resulted in a steady stream of bug fixes upstream to third-party packages from the ports collection. One of the reasons OpenBSD forks projects like openssh or libressl, or implements from scratch services like iked, httpd, ntpd, relayd, smtpd, and many others, is precisely so they can assume full responsibility and control for things like memory management. See https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html When a researcher points out a potential issue on OpenBSD, they're emphasizing their point by leveraging OpenBSD's credibility and the hard work put into the system.