There’s also no livepatches from Ubuntu Pro, and I thought this was the whole idea of livepatches, to patch critical bugs before you have a chance to update the kernel.
This also isn’t the first time I’ve been annoyed at Ubuntu’s response time. Luckily I mostly run Debian, but I certainly won’t be using Ubuntu for anything else in the future.
AI; Didn’t read. It’s the AI version of tl;dr (too long; didn’t read).
Well you can’t sign new certs (with the current date) with an expired root/intermediate cert, but the root/intermediate cert expiring doesn’t strictly invalidate the already signed certs.
But I was more talking about the end-user certificates in the previous comment.
Because these are root certs which are still fine, it’s the intermediate certs that are compromised.
I still disabled eMudhra’s emSign G3 anyway, but that’s probably why Google hasn’t disabled the ones shown.
Yeah, my understanding was they’re not issuing new certificates, but the current ones are still valid until they’ve expired.
FYI, G3 is the only one listed with the issue, the others are fine AFAIK. But if you don’t trust eMudhra at all after that, then that’s fair.
Edit: Actually it’s the intermediate certs that are compromised, the roots are still fine, but many of them come from the G3 root cert (and Sectigo’s AAA Certificate Services)
Fluxer are also moving away from LiveKit, so hopefully that means it’ll require less ports soon.
Some servers do publically list their PHP version, and as an example there are currently ~23,000 that list PHP 8.5.11: https://www.shodan.io/search?query=PHP%2F8.5.11
Sure these could be a manually patched version of 8.5.11, but I find that pretty unlikely.
They were proper 384bit certs, just the upper 376 bits were 0 in all the listed certs. So it’s different to setting the key size in OpenSSL, and they were most likely rolling their own crypto.
If you don’t mind using alternative DNS servers, meaning this won’t be accessible to the average person, you could try OpenNIC.
Unless there are vents underneath, you might also want to flip that power supply around, so the fan’s on top.
Yeah, although Cockpit is a web UI thing, while systemd pilot looks like a proper GTK app.
Cloudflare, Inc., is an American technology company headquartered in San Francisco, California
So it seems I was wrong about Cloudflare having seperate prefixes for WAF and workers. And these are all WAF/workers IPs (but not warp). My guess is that someone’s made themselves a http proxy worker, and are using that to proxy their bot’s requests.
What’s the IPv4? I believe Cloudflare has different prefixes for WAF, warp, and workers.
2a06:98c0:3600::103 is definitely a Cloudflare WAF IP, so my guess is someone using either warp or workers is sending requests and added that IP to X-Forwarded-For as a red herring.
It also stands for Immigration and Customs Enforcement in the US.
Also like the other guy, when you spam all your blog posts within the same hour, it’s annoying and most people will ignore them. At least limit yourself to once a day.
Switching ttys wouldn’t have done anything. The kernel logs are usually saved to efi_pstore (or sometimes erst) by default though.
Edit: you can also set drm.panic_screen=kmsg as a kernel parameter to print the logs instead of the QR.
Nah, when a kernel panic hits then everything’s screwed.
Pressing ESC does work for systemd-bsod (which is different) and as you mentioned Plymouth; but not drm_panic.
Edit: yes, it was Systemd who implemented it.
Nah, systemd-bsod is different and designed to show info about boot failures:
It’s rather quite useless.
drm_panic on the other hand has nothing to do with systemd, and is what’s shown in OPs post. The link can be quite useful for users to post their issues on bug reports or whatever. But if you know what you’re doing, then it’s pretty easy to configure it to print text instead.
Also remember, the reason drm_panic exists is because graphical outputs would otherwise freeze during a kernel panic, and not show anything useful.
Nah the hash function gives up after 256 bytes and outputs
*, matching the ‘hash’.Edit: it’s unix tradition to put
*as the hash for system accounts that should never be able to be logged in, this bug now means you can login (with the right config), using any password longer than 256 characters.