It seems relatively clear at this point that we (the wider industry) now have an extremely good C/C++ linters, with the only downside that they are expensive (relative to previous tools) to run.

Much like the "if your company depends on running other people's x86 code, then Spectre/Meltdown/etc are devastating", I think if your company is/was depending on the user separation boundaries in the OS to work, then you are in a lot of trouble.

[Unauth'd file read/Local Priv Esc]'s have always kind of been low(er) hanging fruit, but they are nowhere near as cool/good at RCEs.

Now that we have machines to find these at reasonable competence and speed, it is probably a good time to look at anything that you run that [processes user supplied data, or speaks over the network] that is written in C/C++ and find memory safe alternatives. It's not those memory safe alternatives are going to be bug free, but they are far less likely to cause you to need to upgrade your kernel every few days to urgently catch up with local LPE's

Even if you are not going to use the new auditing systems for whatever reason, the "enemy" (whether that is your intelligence agencies, ransom gangs, etc) will have no problem trading a few 100$ for what used to cost $10,000's to do.

In related news, I am happy to have just finished moving away from OpenSMTPd, there are basically only 2 C/C++ components left in the whole of bgp.tools stack that speak to things over the internet:

Unbound DNS

(which has recently eaten a bunch of vulns)

rpki_client

(which I need to figure out a good solution for, because I depend on a bunch of it's quirks, the solution probably being extreme bomb proofing of the container/vm/whatever)

@noisytoot https://www.xmox.nl/ !

It's excellent, remarkably user forgiving, a single integrated binary written in Go by someone who I view a quite competent.

I moved my corp mail from Google Apps to it (for mostly sovereignty concerns), and then after a month of that, moved the transactional email to Mox as well.

@benjojo

What did you replace OpenSMTPd with?

@remmy https://benjojo.co.uk/u/benjojo/h/rsVZMC7RbKjt4Jyw7n

@benjojo @noisytoot I like xmox as well, but as a 1-person project, it is kind of a risk. especially since the latest stable release is from last year

@benjojo coincidentally, OpenSMTPd just became the new default and suggested mail server in FreeBSD

@madduci Yeah I mean, I do trust the OpenBSD people to probably write better C than others, but I've have had (and now somewhat vindicated) this view that it's almost impossible to write 100% safe C when you consider the wider ecosystem, and if there are alternatives that don't run that risk, then what are we doing...

@benjojo I still think it's a little optimistic of people to assume that modern hypervisors with all their complexity when it comes to passing through hardware etc don't have similar levels of bugs. But given we don't have the same level of discovered vulns there yet perhaps I'm wrong.

@srtcd424 To be fair a lot of the CPU Vulns are not a (paraphrased) " Hello, here is a 1M lines of C code can you find problems? " type of problem.

But yes, it was a bold assumption that hardware virtualisation totally sealed away from other guests, I think/suspect proponents of such technology decided to overlook it because for most people other than AWS/Azure/etc a data side channel between VM guests is not company breaking

@madduci @noisytoot Sure, I also have my own fork of Mox to tweak the bits I wanted, it's a reasonably easy code base to work with.

I am also trying (somewhat unsuccessfully) to give the guy money because Mox matters to me now and I am than willing to put money where my mouth is in this regard.

@benjojo though if your stuff is hosted _on_ AWS/Azure ..

@srtcd424 Well that is a entirely different set of problems :) with upsides and downsides

@benjojo @noisytoot

This does look very interesting, though unfortunately I don't think I could reasonably switch to it right now as I really want to maintain my centralized user database and Kerberos auth, hmm.

@benjojo indeed, just I believe that the project still has some.important CVEs to address, since go stdlib has only fixed them in very recent versions

@madduci what kind of stuff are you talking about?

@benjojo the rpki-client Debian package has extensive systemd sandboxing.

@rfc1036 yeah I ended up talking to Job about this a whole bunch last night, I would still like to get away form it, but it feels less urgent

@benjojo try any security scanner against the xmox binary

@madduci I gave https://github.com/securego/gosec a go, and it printed a lot of "CRITICAL" things that were either not relevant (turns out, SASL has to import crypto/md5) or low stakes lints like file permissions not being 0600 at all times.

Can you give me more clues on what I am suppose to be looking for / worried about?