ports

OpenBSD apparently still uses CVS. I found this GitHub mirror of their ports repo which has the new wine port: https://github.com/openbsd/ports/tree/master/emulators/wine That has a static import from 13 hours ago. Anyone know if this wine port has its own repository somewhere else tracking the history of the development effort?

> At that time, its researchers have modified Chromium to make use of Capsicum and compared how much effort was required to make use of each sandboxing mechanism within Chromium. [..] If you’re only going to study one sandboxing mechanism in your life, it should be Capsicum. To this date, I have yet to see a better sandboxing mechanism than Capsicum. In the years since it was added, there's a reason you can count on two hands the number of programs using it in FreeBSD. Even less using it effectively, with refactoring, and not just calling cap_enter(). Capsicum Chrome has never been committed to the official FreeBSD ports tree, it was an academic research project from 17 years ago. https://github.com/rwatson/chromium-capsicum https://www.freshports.org/www/chromium/ https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=... No browser

I quite like the OpenBSD approach to Go and Rust projects in ports. They store all the dependencies and their hashes in the build recipe, not trusting the project ones. And they’re more readable. Here is jujutsu’s list of dependencies[0] and their hashes[1]. As an aside, that’s why I don’t like those packages managers. Something like Python’s numpy or lib curl, get sliced into atomic portions. [0]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/c... [1]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/d...

You are right, but it's still a manual step I have to remind myself how to perform every time I upgrade. Thankfully the OpenBSD docs remind me, otherwise I wouldn't remember: https://www.openbsd.org/faq/upgrade77.html https://github.com/openbsd/ports/blob/master/databases/postg...

OpenBSD maintained several local patches to nginx, such as chroot [0] by default and reallocarray fixes, but it was rejected by the upstream and too big to maintain locally. OpenBSD httpd would probably have never existed if nginx upstream reacted differently. https://www.openbsd.org/papers/httpd-slides-asiabsdcon2015.p... [0] The OpenBSD nginx port still includes the default chroot patch, ~8 years later, see https://raw.githubusercontent.com/sthen/nginx_chroot_patch/a... and https://github.com/openbsd/ports/blob/master/www/nginx/Makef...

I think OpenBSD comes the closest to what you want with its two easy to use syscalls that provide syscall filtering and restricting access to paths: https://man.openbsd.org/pledge.2 https://man.openbsd.org/unveil.2 A few random examples: https://github.com/tmux/tmux/blob/c8494dff7b6b9a996866edaf8c... https://github.com/openbsd/ports/blob/master/www/mozilla-fir... https://github.com/openbsd/ports/blob/master/www/mozilla-fir... To get the best isolation you need to patch the source — the application needs to go through initial setup and then drop privileges to the absolute possible minimum. But it's easy to make custom wrappers for third-party applications — the above profiles taken from the OpenBSD ports tree are the proof.

> https://github.com/openbsd/ports/commit/bf33ea5f3ff390d8cde3... Now, this is surprising. I randomly clicked on that link and I immediately see that the code and the patch has a bug. It only checks the first 8 characters: - if (gr != NULL && strncmp(gr->gr_name, "operator", 8) == 0) + if (gr != NULL && strncmp(gr->gr_name, "_shutdown", 8) == 0) so it will also match a group named "_shutdow" or "_shutdow1234" because only the first 8 characters matter. A trivial silly mistake like this is... not what I expected considering OpenBSD's reputation for security.

Oh, the irony of linking to GitHub. https://github.com/openbsd/ports/commit/bf33ea5f3ff390d8cde3... https://github.com/openbsd/ports/commit/469b0a4b0a1152576d93...

For me it's the ease of management and good documentation. For example, during 6.8 to 6.9 upgrade, there was a major postgresql upgrade. It is mentioned in the doc https://www.openbsd.org/faq/upgrade69.html (see Special packages at the bottom). You're redirected to the package README with special instructions on how to setup and upgrade: https://github.com/openbsd/ports/blob/master/databases/postg... Et voilà, everything is explained. On debian, if I am not careful, I'll do an upgrade and risk breaking something during a db migration (I'm looking at you MySQL upgrades...).

> OpenBSD has handled this case for some years. I do not know if there was any breakage or fallout from this. The other thing about OpenBSD is that when they make a change to their OS, they also go through to make sure all the (third-party) ports/packages: * https://cvsweb.openbsd.org/ports/ * https://github.com/openbsd/ports do not break. So they're create patches for the software and and submit them upstream.

> An old and somewhat crusty cross-platform daemon replaced by an OS-specific set of daemons, that takes care of managing /etc files that have been there forever. The older solution remains available, but may bitrot or otherwise become harder to maintain in the future. > Wait, isn't this what systemd is "accused" of doing all the time? Each of these do one thing and one thing only. The code is loosely coupled between the two, so you can use or not use either/both. Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. And while it is likely that dhclient will eventually be removed from OpenBSD Base, it will live on in Ports, where it will be available to those who desire to use it: * https://cvsweb.openbsd.org/ports/net/isc-dhcp/ * https://github.com/openbsd/ports/tree/master/net/isc-dhcp Th

Browsers having unfettered access to users files is something which should be mitigated against on all platforms, not fleshed out into an ill-conceived feature, it goes in complete contrary to browser sandboxing efforts in Chrome itself for different process types (renderer/gpu/utility), but also work like OpenBSD has done with pledge(2)/unveil(2). On OpenBSD, all processes of chromium, including the main browser process are tightly pledged and unveiled by default, write access to the users home directory is limited to only a few paths (~/Downloads), and a few config directories. As a consequence, users are rather forcibly taught safer usage pattern of copying files into the unveiled paths when uploading, which as Bob Beck alludes to in his slides below, is a reasonable compromise to every website having access to your ssh keys. https://w

"FreeBSD 11.4-RELEASE Announcement [...] Some of the highlights: The clang, llvm, lld, lldb, and compiler-rt utilities as well as libc++ have been updated to upstream version 10.0.0. [...]" I found this interesting. Seems like FreeBSD is more pragmatic than OpenBSD. They are using the latest and greatest llvm/clang series. For license related reasons OpenBSD is stuck on an older version of gcc. I understand that OpenBSD has now _also_ become stuck on an older clang/llvm due to license changes there too. In the long run, not upgrading the compiler is going to hurt OpenBSD a lot, I think. A lot of mitigations are now built in the compiler and languages (e.g. C++) are accumulating features at quite a fast pace. I was wondering if users of OpenBSD have thoughts on the above. Do you think its a bit deal? What is the solution?

> OpenBSD, which uses X11 that Chromium already has a native backend for, has thousands of lines of patches they have to maintain (and spend hours and hours rebasing every upgrade). Wow, you're not kidding. https://github.com/openbsd/ports/tree/master/www/chromium/pa... is positively scary.