aomix

Or least if you drink most of the six pack you stop caring about taste. Unlike Soylent.

Disclaimer: I drink Soylent's Coffiest every morning.

Every few months I get caught up on these and secretly wish I worked with a testing infrastructure even a quarter as robust. Working on an emulator seems like the most finicky development work out there but the Dolphin group can hack without fear because they can be reasonably confident that a change to fix one issue didn't have an impact elsewhere.

I've fallen into doing something similar. I read the mailing lists regularly try to look over the source for something that gets a proposed patch. Because OpenBSD boils down their software to the essentials and tries to make their APIs impossible to misuse I find it pretty easy reading even though I'm not very experienced with C.

I have nothing useful to add to this discussion. I just like that this idea is a core part of the TV show Person of Interest.

I got so used to listening to a relative explain how IBM is run by incompetents that when that person retired I felt like we lost a family tradition.

I still don't understand the strong reactions Soylent gets on either side. There's plenty to criticize and to like but reactions to it cluster around it being the end of the world or solution to all your problems.

I'm a fan of the breakfast Soylent (Coffiest). To me it's the best form of the Soylent idea.

I've read the OpenBSD developers poke fun at Linux by saying the same thing. During the 2000/XP time frame security became a serious threat to Microsoft's market dominance. Since then Windows has kept up with the best security practices and technologies better than most. It's very impressive considering I can still run Windows 2000 binaries on Windows 10.

To me it seems like Rust has an additional wrinkle with safe and unsafe code. A new Rust user needs to figure out both "How do I do this" and "Is this possible in safe code". The limits of safe code seems to be something people are figuring out at all levels. Rust projects seem to start out with a relatively high amount of unsafe code. Then as the project matures the unsafe sections are reduced or eliminated.

But that is nearly a two sentence summary of the post.

  -The API changes are needed and good
  -The migration to 1.1 will be difficult

The argument is just that it's not realistic for many OpenSSL users to drop 1.0 for a variety of reasons.

I do like it when security polices are compiled into the program and like it even better when they are impossible to disable. That way programs avoid getting out of sync with best security practices since they will start crashing for all users/developers. Not just users of X but not Y. However programs that try to work with pledge/capsicum/seccomp/others are great but always going to be in a very small minority. So something like SELinux and Apparmor being able to enforce policies on arbitrary software seems like a necessary seatbelt.

You can't beat Clonezilla for personal or small scale use. It's pretty basic compared to other tools but that also lets it be dead simple to use. I've migrated or restored so many systems with it I can't remember the last time I had to do a from scratch reinstall.

Well, to the best of my understanding. FreeBSD will generally have better performance while OpenBSD has the latest pf syntax and features. This is a source of animosity between the two projects that I don't fully understand.

FreeBSD has done a lot of work to enable SMP for their pf so that gives it the edge on modern multicore systems. This work wasn't able to be used in OpenBSD so that was unique to FreeBSD for a long time. Right now OpenBSD is in the middle of doing the same for pf and their network stack. So the performance difference shrinks on every release. The newer pf syntax and features make writing rulesets easier, like replacing ALTQ with prio for traffic shaping.

This summer I had a router running OpenBSD on the older apu1d and was seeing nearly 700mbps on iperf with a basic rule set. But I don't know how iperf relates to real world performance.

That's really cool, thanks.

That statement was comparing capsicum being applied to programs that were also pledged in around 2 lines of code. A few of the programs on the wiki as examples of capsicum applications originated from OpenBSD so they were primed and ready to go. Even those best cases are much more involved than pledge.

To use the example of the unix tr utility, the change to use pledge required the standard two line diff.

  if (pledge("stdio", NULL) == -1)
		  err(1, "pledge");

tr.c was the one of the earliest programs pledged (back when it was called tame). The original diff was a one liner before they start doing the "pledge or error out".

http://marc.info/?l=openbsd-tech&m=144070638327053

  +	tame(TAME_STDIO, NULL);

The capsicum diff required the following

https://reviews.freebsd.org/D7928 https://reviews.freebsd.org/file/data/4exxbzvuc3dayrvdj6qe/P...

  +	cap_rights_t rights;
  +	unsigned long cmd;

(...)

  +	cap_rights_init(&rights, CAP_FSTAT, CAP_IOCTL, CAP_READ);
  +	if (cap_rights_limit(STDIN_FILENO, &rights) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit rights for stdin");
  +	cap_rights_init(&rights, CAP_FSTAT, CAP_IOCTL, CAP_WRITE);
  +	if (cap_rights_limit(STDOUT_FILENO, &rights) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit rights for stdout");
  +	if (cap_rights_limit(STDERR_FILENO, &rights) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit rights for stderr");
  +
  +	/* Required for isatty(3). */
  +	cmd = TIOCGETA;
  +	if (cap_ioctls_limit(STDIN_FILENO, &cmd, 1) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit ioctls for stdin");
  +	if (cap_ioctls_limit(STDOUT_FILENO, &cmd, 1) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit ioctls for stdout");
  +	if (cap_ioctls_limit(STDERR_FILENO, &cmd, 1) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit ioctls for stderr");
  +
  +	if (cap_enter() < 0 && errno != ENOSYS)
  +		err(1, "unable to enter capability mode");

No one would dispute that capsicum is more capable but is significantly more complex. Pledge trades finer control over capabilities for the ability to have a "work or die" usage model. Capsicum requires that you be aware of all the potential failure cases and account for them.

That is probably the reason for the quick uptake of pledge in OpenBSD's tree. A lot of their software had already been restructured or rewritten for privilege separation. But looking at a few capsicum diffs in the FreeBSD codebase I'm not sure I'd call those trivial. You can do more with capscium so there is more code to deal with those abilities. But even simple cases hit 20+ lines of code with multiple failure states to deal with. Compared to the usual two line pledge diffs that's quite a bit more work to do.

The testing infrastructure they've built up around the project is incredible.A handful of developers spent years building it out and now the entire project benefits immensely from it. It's the kind of thing developers fantasize about having on a project they work on.

DNS doesn't seem very well secured against determined attackers. But at the same time I almost never hear about attacks done via DNS spoofing. So I guess it harder to attack than I think.

I've read other people make this point. There are a lot of TLS implementations out there but OpenSSL was so synonymous with SSL/TLS for so long that it became a fundamental building block. If an API could be established that lets the-thing-that-does-TLS become a minor detail that's easily configured we'd all be better off.

Removing the dependency on OpenSSL is going to be a challenging, messy job. OpenBSD has mostly transitioned over to their LibTLS API but even they had difficulty moving some projects over.

I thought spamd passive aggressively insulting spammers and tarpitting their connections was a good effort at wasting their time. This is a big step up from that.

Cool approach, you need to compromise two separate servers just to have a usable password database you could run tools against. A key compromise can be fixed quickly and a password compromise is useless without the key.

There seem to be slightly fewer Lets Encrypt and ACME implementations than stars in the sky. Which is fantastic. Last week I read about a privsep/chroot/pledge'd (OpenBSD thing) C implementation https://kristaps.bsd.lv/acme-client/ .

Yep, here's a brief overview of that from 2007 https://youtu.be/NJ9Jml0GBPk?t=1937 . SPARC64 is a favorite of this developer because it's some Alice in Wonderland stuff where up is down and left is right compared to other architectures. So it exposes a number of bugs that others don't.

Bugs exposed by moving to different architectures are fascinating. They always originate from assumptions that just happen to work on the architecture they were designed on. But when you go to a different arch they go from being sort of harmlessly incorrect to crash and burn type of incorrect. Or, infinitely worse, a sort of works but not in the way you expect it situation.

Making a diy router is a fun project if you're interested in the nitty gritty details of things like firewall rulesets and dns resolving. And in the end you're left with a powerful and flexible router.

I'm reading over the diff and this is a very interesting 9 line changelog.

I believe the router relies on a binary blob that lets EdgeOS (based on Vyatta which is based on Debian) offload routing to some specialized hardware.

I run a OpenBSD router in a PC Engine Apu1d and it's more than fast enough. I can hit 700+ mbps on iperf with a basic pf rule set. Since OpenBSD is in the middle of updating their network stack to enable SMP I'd bet that number will rise with the next couple releases. I found mailing list posts from a year ago that have the iperf benchmarks of the apu1d right at 500 mbps. I'm interested to see if the network changes that landed in 6.0 will mean a measurable difference. This is entirely academic on a 30 mbps connection but I like it when numbers change.

It's worth noting that hitting that performance relies on hardware acceleration not available on OpenBSD. I've read it can still manage ~100 mbps on OpenBSD which should be good enough for most people. But keep that in mind if you want serious routing performance and OpenBSD.

Pretty much any security measure in isolation can be bypassed. So you need to stack as many as are reasonable on top of each other to limit the attacker's toolkit.

This change is basically free and makes certain things more difficult for attackers, so why not?

Years ago there was a short lived VPN service that tried just that. Making sure their service was on non congested optimal routes to game servers. But it didn't really take off, I assume because of that reason. All they could offer was what your ISP should hopefully be doing in the first place but nothing more.

The OpenBSD devs were really enthusiastic about reallocarray as a way to catch some integer overflow issues like the OpenSSH issue.