I've swinged between Go and Rust for my personal projects multiple times. For work, it is decided by the management so not my problem.

The biggest gripe I have with Go is the lack of *any* compile time check for mutex. Even C++ has extensions like ABSL_GUARDED_BY. For a language so proud on concurrency, it is strange not to have any guardrails.

The guardrails are channels.

If you have a mutex on a structure, linters such as are packaged into Goland will catch oversights quite effectively.

If you are using fancier concurrency structures, you should consider channels instead.

Channels are not for everything. Plenty of mutex cases cannot be rewritten as channels, or will be very unwieldy so. In fact, every large Go project I have seen uses mutex here or there.

Theoretically you can use channels to simulate a mutex, but I agree with you there are use cases where a mutex makes more sense. They are even used in the standard library, for instance to implement sync.Once.

But generally I would agree that if you need to code parallel execution, channels are a good way to do it, because you can avoid race conditions if you share data only over channels. The biggest problem is that a lot of people don't understand, that channels with a buffer larger than 1 are a sign of problems in the architecture.

There is a type of parallel programming with workers for specific functions, that always leads to performance issues. The problem is you need to right-guess the distribution of work, when you have to define the amount of workers for a specific function. At least one go routine for one request is a much better approach than function-specific workers.

We need an easy way to ensure that only kernel modules in an whitelist can load. I’m tired of blacklisting modules I never need.

You are assuming that LPE only applies to the user that holds all the sensitive stuff. But it also applies to users created specifically for isolation. Without LPE they would not have access to anything important even if they were compromised.

It doesn't matter which "user" this goes through. If an attacker can get hold of a users control to the point where they can execute arbitrary scripts, you have already lost.

If the goal is just preventing full root privileges, a CapabilityBoundingSet in a systemd unit will do.

However copy fail can be used in many other ways not contained by containers or the above settings. For example it can modify the /etc/ssl/certs to prepare for MitM attacks. If you have multiple containers based on the same image then one compromised CA set affects another.

I added these

    AmbientCapabilities=CAP_NET_BIND_SERVICE
    CapabilityBoundingSet=CAP_NET_BIND_SERVICE
    NoNewPrivileges=yes

to my .service. Is it good enough?

Good enough for what?

I could be wrong, but I’m not sure those settings are enough to mitigate Copy Fail.

If your distro offers a patched kernel, it’s best to upgrade to that one and reboot.

You can also disable the vulnerable module (how to do it depends on what distro you’re using). But if you stay on an old unpatched kernel you might be exposed to other vulnerabilites.

You are misinterpreting my goal here. I have patched my kernel against copy fail but I am thinking of ways to harden my setup against future CVEs in the kernel.

So the question is, before I learned about copy fail, what could I have done that would have limited the possible damage this vulnerability could do to me? CapabilityBoundingSet is one answer and rootless podman as mentioned in this article is another. They don’t prevent all but at least `su` is useless.

If so, I would look into applying a decent seccomp profile.

Other hardening solutions could be to run the workloads inside of a VM such as Firecracker, or gVisor. But that might be more work to implement compared to seccomp.

Does this work from a fork? That is, can I file a stacked PR to a project not owned by me, by creating branches in my forked project? Previously I asked AI about how to contribute stacked PR, it told me that I can only do it when I have push privileges to the repo, not from a fork, and the doc here is ambiguous.

----

OK, I found this from official docs, so this feature is now quite useless to me:

> Can stacks be created across forks?

> No, Stacked PRs currently require all branches to be in the same repository. Cross-fork stacks are not supported.

ETH is not afraid of doing hard forks, so I'm expecting that they will lead in adopting post quantum cryptography. And then BTC ecosystem participants can learn from ETH.

even if btc does a hard fork, you'll need to "reshim" the encryption on each wallet. and you can only do (n) tx per block. and only 1 blocks per unit time. this limits the speed of bitcoin moving to PQC, it must take at leaat ~3 years iirc

It would still tank the price. Right now many Bitcoins are lost because no one holds the keys any more. When they can hack it, suddenly the sell pressure significantly goes up.

I don't count that Xi losing, but Xi winning. He's very conservative in China's sense, and he's basically crushed less conservative forces in the Party. A crackdown on clothing "detrimental to the spirit of the Chinese people." doesn't serve any real interests of Xi other than enforcing the ideals of China's conservatives.

Similar to how the Republican party always try to inhibit abortion wherever they can. You won't say that Republican party successfully passing an anti-abortion law indicates they are losing, will you?