No, rust is stricter because you need to think a lot more about whether weird edge cases in your unsafe code can potentially cause UB. For ex. If your data structure relies on the Ord interface (which gives you comparison operators and total ordering), and someone implements Ord wrong, you aren't allowed to commit UB still. In C++ land I'd venture to guess most any developer won't care - that's a bug with your code and not the data structure.

It's also more strict because rusts referencing rules are a lot harder then C's, since they're all effectively restrict by default, and just turning a pointer into a reference for a little bit to call a function means that you have to abide by those restrictions now without the help of the compiler.

The vulnerability has nothing to do with accidentally logging sensitive information, but crafting a special payload to be logged which gets glibc to write memory it isn't supposed to write into because it didn't allocate memory properly. glibc goes too far outside of the scope of its allocation and writes into other memory regions, which an attacked could carefully hand craft to look how they want.

Other languages wouldn't have this issue because

1. they wouldn't willy nilly allocate a pointer directly like this, but rather make a safer abstraction type on top (like a C++ vector), and

2. they'd have bounds checking when the compiler can't prove you can go outside of valid memory regions. (Manually calling .at() in C++, or even better - using a language like rust which makes bounds checks default and unchecked access be opt in with a special method).

Edit: C's bad security is well known - it's the primary motivator for introducing rust into the kernel. Google / Microsoft both report 70% of their security vulnerabilities come from C specific issues, curl maintainer talks about how they use different sanitizers and best practices and still run into the same issues, and even ubiquitous and security critical libraries and tools like sudo + polkit suffer from them regularly.

git commit -a --amend

Not in this one, iirc they actually reverse engineered and were working off of apple libraries, rather than proxies.

The idea is malware you installed would presumably run under your user account and have access. You could explicitly give it different UIDs or even containerize it to counteract that, but by default a process can access everything it's UID can, which isn't great. And even still to this day that's how users execute a lot of processes.

Windows isn't much better here, though.

Containers don't typically have inits, your process is the init - so no extra processes are started for things other than what you care about.

According to the benchmark in the article it's already way faster at n = 1000. I think you're overestimating the cost of multiplication relative to just cutting down n logarithmically.

log_2(1000) = roughly a growth factor of 10. 2000 would be 11, and 4000 would be 12. Logs are crazy.

The point is to minimize privilege to the least possible - not to make it impossible to create higher privileged containers. If a container doesn't need to get direct raw hardware access, manage low ports on the host network, etc. then why should I give it root and let it be able to do those things? Mapping it to a user, controlling what resources it has access to, and restricting it's capabilities means that in the event that my container gets compromised, my entire host isn't necessarily screwed.

We're not saying "sudo shouldn't be able to run as root" but that "by default things shouldn't be run with sudo - and you need a compelling reason to swap over when you do"

Only for it's child processes, e.g. call a bash script with a modified PATH. Still problematic though.

...I suppose they could also modify your .bashrc equivalent.

Kanidm wants to directly have access to the letsencrypt cert. It refuses to even serve over HTTP, or put any traffic over it since that could allow potentially bad configurations. It has a really stringent policy surrounding how opinionated it is about security.

Instances aren't banning other instances for federation with communities they dislike. Instances ban other instances for hosting content they dislike. The benefit of starting an instance is you choose who to federate with.

Web 3 is different things depending on who you ask. Block chain, decentralization, or whatever else. We dunno, we aren't there yet. I personally believe federated services have a chance of being web 3 (and Blockchain is not relevant).

Web 2 is basically big tech on the internet, everything becoming centralized. Everything became easy to use for the end user, all point and click.

Web 1 was the stuff prior to that, when the internet was the wild west.