Haven't seen any of those myself. I don't think they appear if your PC isn't compatible.
skullgiver
I mean I didn't set it up for this, but it was fun. The point is you can't really rely on this info. I imagine plenty of Fediverse software will render 1970-01-01 as the registration date simply because they don't track that info.
I don't know what systemd-boot does, but the normal way to install a bootloader is to copy an efi file to the right folder (/EFI/archlinux/grubx64.efi or whatever) and register the bootloader in the boot configuration store. This allows you to pick the OS from a list by hitting the boot menu key for your device (f8/f12 usually I think?) rather than having to rely on something like systemd-boot or Grub to list all of your operating systems. This way, you can also boot UKIs and other Linux kernels compiled to simple EFI files, without ever even touching an independent bootloader.
As a fallback, both Windows and some Linux bootloaders copy their files to the /EFI/Boot/bootx64.efi directory. This makes the drive bootable in cases where the boot configuration store is broken, or if the drive wasn't hooked up to the same motherboard when the installation was done. This is particularly important for installer drives, because you don't want to add a boot entry to your motherboard for every installer you plug in.
The downside of this fallback file is that it's just one single file in a preset directory, like the MBR of old. Some motherboards come with a file browser to select the EFI application you want to boot, but many will just give you a boot menu and nothing more. Because it's a single file, that bootloader can either be Windows or it can be Linux. This isn't a problem normally, but on broken motherboards this can render a system Windows-bootloader only or Linux-bootloader only. You can add both Linux and Windows to either, but the file being booted it always the last one that got updated.
There's also a weird edge case for when you install Linux on a GPT disk from CSM mode, where the GPT disk will have an MBR. That makes the Linux system incapable of using any UEFI features and it has the same problem: if Windows puts its bootloader there, the drive will boot Windows.
As for bootloaders themselves, you generally only install one (though there's nothing preventing you from installing both and having both be bootable, because they're just entries in the UEFI menu!). If you want, you can install bootable Linux kernels as well, without any bootloader, though those don't let you pick your boot options.
The security setting is bypassable by the user. It's just not a "hit enter to install a virus" popup, but the "disable secure boot" toggle in the UEFI firmware settings.
As anyone working in customer support will be able to tell you, if you give people a warning message they can bypass by hitting a button, they'll smash their face into their keyboard until the unexpected message goes away and blame you for not telling them what they were doing.
The only exception are those weird machines that were built specifically to only run Windows. They're not compliant with the secure boot standard. Don't buy those if you don't want to run Windows, because they're designed not to. Or hack them, I guess, but that's a lot of work.
They're not selling anything, they've signed the shim loader in collaboration with the Linux community, which then takes control. The shim (the part printing the error message everyone is reporting) didn't get an update, nor a new signature, because it didn't need one. It was designed so that distros can compile and run Grub without having to go through the certification process.
Grub was patched two years ago to not execute code at ring 0 when a funky font file gets placed on the boot drive. If you don't care about that, just disable secure boot entirely and the message goes away.
Linux distros could've prevented this problem by fixing their vulnerable signature when the security flaw was found two years ago. All they needed to do was regenerate the SBAT when the security update came in, but as far as I can tell the broken systems just patched the code (allowing anyone to still exploit it by replacing the Grub executable with a broken version). This is hardly a Microsoft conspiracy. Microsoft gave Linux users two years more than they gave Windows users (and, more importantly, system administrators) when they had a vulnerability like this last year.
Windows users aren't going to switch to Linux, they use Windows because they want Windows. If they don't want to make it easy to get infected, they can buy critical security updates beyond the 10 years of standard support Microsoft provided Windows 10 with (the ESU program) or they can keep using their old Windows 10 install without security updates.
Realistically, as long as Google maintains Chrome for Windows 10 (so all those Chrome derived browsers still receive updates), most people are going to be fine when it comes to viruses. The 4% using Firefox may receive even more support through the ESR programme.
I'd expect Microsoft to care more about ChromeOS Flex than they do about Linux on the desktop. Would be nice if Linux would become usable enough for normal people, but it's still a pretty rough experience if you don't have a Linux expert around. Maybe one day!
Bottom line is that Linux distros never really bothered to apply a real fix for a security vulnerability and decided to muck on with a quick patch and a lot of hope. This wouldn't have been an issue if distros fixed their boot configuration two years ago when the problem became publicly known.
They updated the system key store to invalidate known vulnerable boot configurations. One of those configurations was old versions of Grub, which had a pre-boot exploit a couple of years ago.
The issue has already been patched for years, but it appears some Linux distros never bothered to update their system configuration. Not sure if this is a shortcoming of Grub or one of the distro maintainers that were affected, though.
In fact, Microsoft tried to not apply this patch on dual boot systems, leaving them vulnerable but working, but clearly their detection failed. I think their detection required chainloading the Windows bootloader or something?
Either way, the only Linux file that Windows will ever touch with updates is the "fallback for when the boot configuration is completely fucked" bootloader, which both Linux and Windows overwrite after installation, incase the boot configuration gets completely fucked. If you're relying on that bootloader, you were always going to get fucked by some update eventually; either your installation failed or your motherboard is broken.
I've set my age to 100 years as a gag, I don't think you can rely on that stuff. Plus, creating an account is free, so spammers can just create a bunch of sockpuppets beforehand.
I can still see a use for a moderation bot, though; piping everything through a tool like SpamAssasin could filter out those kbin spam waves that happened every now and then almost automatically.
It'll try to restart the affected services after updating, but doesn't always auto restart everything; sometimes it'll leave services running if you'd otherwise need to deal with dependencies and such. In that case, it'll touch a reboot-required file that'll inform you a reboot is necessary next time you log in.
Scheduling a weekly/daily reboot should take care of that, as well as applying kernel updates.
Ik heb gemerkt dat de NOS naar de daders verwijzen als "kwetsbare" meisjes, maar wat ze nu zo kwetsbaar maakt wordt nergens uitgelegd. Ik ben toch benieuwd wat voor kwetsbaarheid iemand brand doet stichten in een winkel. Zijn ze mentaal gehandicapt of zoiets?
Ik hoop dat hun ouders goed verzekerd zijn, dit gaat deze meisjes en hun familie nog jarenlang achtervolgen als de verzekeraar niet uitkeert, los van het straftraject dat de rechter gaat opleggen.
Yes, I think you did. In that case, I don't think Linux will claim the fallback loader entry. Windows doesn't always copy its files there, so the file may not even exist. If that's the case, you'll only ever encounter the fallback paths on an installer/recovery disk.