Mad respect to sales guy. I'm doing the same and avoiding arms companies (my background is very useful for military research).
I acknowledge some warfare may be legitimate (having been bombed myself), but arms companies don't stop at selling to your personal favorite army which you consider morally right, they keep looking for more business abroad.
I don't want to be the one realizing I'm sitting in a cozy air-conditioned office and having made money from the messed up warfare in some distant far-away country, having a large financial incentive to cause more conflict there.
So that a root compromise in one service does not escalate to the entire server.
As a concrete example: my personal mail server (on a modern operating system) has its SMTP handling in a separate process from mailbox serving. If the SMTP process is compromised, and the attacker reaches uid=0, it doesn't matter -- no data from the mailboxes can be exfiltrated.
Only SMTP is broken, because mandatory access control prevents the SMTP "root" from doing anything the SMTP daemon would not ordinarily be permitted to do. The SMTP daemon is not empowered to read mailboxes, even if its uid is 0.
I think in this hypothetical scenario the uid 0 attacker can create its own node for /dev/rwd0 and use raw disk accesses to get around filesystem limits.
It's also hypothetical in that there's no known OpenSMTPd exploit that will allow you to get root, and barring a single CVE its record is pretty damn good.
Blind reliance on ACLs/MAC is dangerous itself. I've had the benefit of working on all of the above and ACLs aren't something people get right the first time. Most don't even get it right the 10th time.
We use SELinux in my current place and while it's fine, things break/fail in odd ways and we're always tweaking it.
In the 6-7 years I did Windows administration, I trained a couple hundred people on ACLs and specifically how the SubInACL tool should be used -- for all but about a dozen of them who truly grokked it, that training was an ongoing process over the course of those years...
OpenBSD's advantage is in its simplicity, which ultimately is the best security. If you have a system that you can clearly reason about and design for where it might fail, you are better prepared for "when" shit happens -- because it's not "if". If your entire system is properly architected, this isn't actually an issue.
For that particular example it should be pointed out that OpenBSD chroots the web server by default which ends up running as a non-privileged user. OpenSMTP does as much work as possible in multiple tasks running as a non-privileged user. So even ignoring the access control provided by the pledge system it is really unlikely that anything is going to escape to root or even be able to affect each other.
They're not really names, just "addresses" of a different form --- and of course, 0 is not really a register. x86 register names are supposed to be mnemonic, because certain instructions are only usable with, or have shorter forms when used with, the "right" register: Accumulator, Count, Base, Data/Divide, Stack Pointer, Base Pointer, Source Index, Destination Index.
Those explanations for the x86 register mnemonics were great, thanks!
To me the MIPS registers seem pretty logical too, though: $zr for zero, $sp for stack pointer, $a0-3 for arguments, $t0-7 for temporaries and $s0-7 for saved registers. Much better than the plain numbered registers on some assembly flavors.
I'm assuming you're talking about the reviewer and long term contributor side of it. personally I found initial setup as a drive-by contributor to be very tedious. GitHub is the lowest friction because I already have an account with SSH key etc.
This is one area where Rust also differs from C; assert!s are left on in release mode; you use debug_assert! if you want something only in development.
I would argue the opposite, assert() statements are the best way to write defensive and secure C. There might have been a time when people commonly compiled out assert() statements from binaries, but that is only OK if the software was designed for that. Otherwise, that would be like me saying I am going to compile out all strlen() statements from a given binary and then expect it to behave the same.
Secure code should be correct and robust. To assure correctness assert()'s should be used, to assure robustness you should check return values and buffer sizes.
