StarDreamer

At one point in time, I was obsessed with getting a Thinkpad to the lowest power consumption possible.

I think I managed to drop it down to ~3w, with the screen and radio fully disabled.

That still leaves two out of three questions unanswered. Most importantly the last one, which was addressed towards the original complaint.

1. If your assumption is that X509 is trash, does that mean you hold the same amount of distrust to TLS?
2. How do you propose the scaling of key management? Do you have a reasonable alternative to users blindly trusting every single key they come across?
3. Back to my original question: what prevents a VSCode extension from stealing a private signing key (as opposed to an API key) and causing the same issues described here?

And how would apt help in this particular case? A supply chain attack can happen with any particular package manager. In this case, the compromised package was detected and mitigated within 93 minutes, affecting a total of ~330 users. Which is a lot better than how a lot of distros handled the xz breach last year.

All reasonably secure package managers (and https) operate on a chain of trust. There is little that can be done if that chain of trust is broken.

Based on this the cause was a malicious VSCode extension that stole credentials that were later used to trigger a deployment CI/CD pipeline. If there’s anything to learn from this, it’s probably to not use VSCode.

stares at 300 line shell script+ansible mess that updates/sets up Forgejo, Nextcloud, ghostcms

“Yes… It’s automated”

Exactly. Unless you are actively doing maintenance, there is no need to remember what DB you are using. It took me 3 minutes just to remember my nextcloud setup since it’s fully automated.

It’s the whole point of using tiered services. You look at stuff at the layer you are on. Do you also worry about your wifi link-level retransmissions when you are running curl?

Another thing you can look into is apptainer/singularity. Basically portable container binaries. Executing the binary automatically runs a program/drops you into a shell inside the container with your $HOME mounted inside. Stuff like cuda also work as long as your host system has appropriate drivers.

You can also port docker containers to apptainer directly via cli.

Just in time to move to IPv6!

What someone does with their 16,777,215 private IPv4 addresses is none of our business…

Now just connect all of that with dumb L2 switches and watch those broadcasts fly!

Can’t comment much about the docker side since it’s not something I’m familiar with.

For the kernel part, assuming what you’re referring to as UUIDs is the pid namespace mechanism, I’m failing to see how that would add overhead with containers. The namespace lookups/permission checks are performed regardless of whether the process is in a container or not. There is no fast path for non-containerized processes. The worst overhead that this could add is probably one extra ptr chase in the namespace linked list.

Make sure to test your setup if you are using DAV. Large files can fail if your nextcloud setup is done incorrectly.

Source: idiot who misconfigured PHP that resulted in a DAV client stuck in a retry loop, then getting banned by my own firewall for DoS.

Isn’t the whole point of these things the “bloated” (CI/CD, issue tracker, merge requests, mirroring, etc) part? Otherwise we’d all be using bare git repos over ssh (which works great btw!)

It’s like complaining about IDE bloat while not using a text editor. Or complaining there’s too many knives in a knife set instead of buying just the chef knife.

CrowdSec has completely replaced fail2ban for me. It’s a bit harder to setup but it’s way more flexible with bans/statistics/etc. Also uses less ram.

It’s also fun to watch the ban counter go up for things that I would never think about configuring on fail2ban, such as nginx CVEs.

Edit: fixed url. Oops!