The delay is certainly frustrating. I use a patched version of kitty terminal that moves starship prompt to the bottom of the window, similar to vim and emacs. Since modeline updates are asynchronous, the shell prompt is very snappy even in big git repos. The downside is that you have to patch kitty and I never bothered to test my personal pet project on anything else than Linux.
Same and it's my favourite Kobo feature. I hope Mozilla releases Pocket source code for people willing to self-host it. Kobos are highly hackable and I'm sure the community will find a way to change getpocket.com domain in the built-in Pocket app, even if Rakuten chooses not to provide this option.
The article says "[she] was told she should have applied for a working visa, instead of a tourist visa", so it's fair to assume she had a proper B2 tourist visa, which lets you stay for 6 months.
VWP/ESTA is a "tourist visa" in all but name, and it's much more likely that a UK citizen would be using this instead of going through the full B2 visa application rigmarole.
It may work for top, but not ps among others. The only reliable way is clobbering argv. That's just the way it is. In my opinion, glibc should finally provide setproctitle(), so programs like postgresql or chrome (https://source.chromium.org/chromium/chromium/src/+/main:bas...) don't have to resort to argv hacks.
> Fortunately, despite the scary log entries showing attempts to change privileges and delete critical folders, it seemed that all the malicious activity was contained within the container.
OP can't prove that. The only way is to scrap the server completely and start with a fresh OS image. If OP has no backup and ansible repo (or anything similar) to configure a new home server quickly, then I guess another valuable lesson was learned here.
Not 100% what you mean with "scrapping" the server, you suggest just a re-install OS? I'd default to assuming the hardware itself is compromised somehow, if I'm assuming someone had root access. If you were doing automated backups from something you assume was compromised, I'm not sure restoring from backups is a great idea either.
I'm guessing it's an automated attack, where it found running services and then threw payloads at it until it got something. Once they're there, since docker isn't a real security barrier, I'd consider it all bets off.
Especially when it comes to my home network, I would rather be safe than sorry. How would you even begin to investigate a rootkit since it can clean up after itself and basically make itself invisible?
Particularly when it comes to Kinsing attacks, as there seem to been rootkits detected in tandem with it, which is exactly what OP got hit by it seems (although they could only see the coinminer).
For crypto miners, it’s pretty easy to tell if your servers are in your house. Even if they aren’t, if you have any kind of metrics collection, you’ll notice the CPU spike.
My general feeling is that if someone wants to install a hardware rootkit on my extremely boring home servers, it’s highly unlikely that I’ll be able to stop them. I can do best practices (like not exposing things publicly), but ultimately I can’t stop Mossad; on the other hand, I am an unlikely target for anything other than script kiddies and crypto miners.
> For crypto miners, it’s pretty easy to tell if your servers are in your house. Even if they aren’t, if you have any kind of metrics collection, you’ll notice the CPU spike.
Sure, but if you already know since before that this specific cryptominer has been found together with rootkits, and you know rootkits aren't as easy to detect, what's your approach to validate if you're infected or not?
Maybe I'm lucky that I can tear down/up my infrastructure relatively easily (thanks NixOS), but I wouldn't take my chances when it's so close to private data.
NixOS isn't going to do anything against a hardware rootkit, which is what I originally mentioned. My home infra's base layer is Proxmox, with VMs built with Packer + Ansible, but that still has the same problem.
That's my point – you can do best practices all day long, but short of observing sudden shifts (or long-term trends) in collected metrics, you're not going to be able to notice, let alone defend, against sophisticated attacks. There has been malware that embeds itself into HDD firmware. Good luck.
> Notably I thought the issue would be the throwing of `std::bad_alloc`, but the new version still implements std::allocator, and throws bad_alloc.
The new version uses `FMT_THROW` macro instead of a bare throw. The article says "One obvious problem is exceptions and those can be disabled via FMT_THROW, e.g. by defining it to abort". If you check the `g++` invocation, that's exactly what the author does.
