On Neon in Wayland it moved the application launcher and notifications to the center of the screen. I saw an issue opened for it just now, so hopefully it will be fixed soon. But I’m expecting it will likely just be a thing until Plasma 6 because that is likely where 100% of their resources are right now.
And yes, Plasma6 is usable now, it seems like everything is just working and I am close to rebasing. There is a Fedora Kinoite variant which is in my experience way better than Neon Unstable
Most fastboot options dont show the logo until windows bootloader comes along.
Though i am not sure how or why the logo is displayed when windows loads? Is that the same image? Loaded and displayed again or just didnt clear the display?
Warp has discoverability features that would actually convince me of using a “modern” terminal - like instant tooltips with documentation.
That said, call it trust issues, but I’ll never use a closed source terminal.
I’d like to see more user-friendly features like this that are terminal-agnostic. Manually checking manpages is so slow and fickle. Having the equivalent of an intellisense for the command line would be awesome.
Yup, I feel you. It’s something I’ve always wanted myself, and I find myself hoping the OSS alternatives eventually implement something similar. For now I just make do with things like tealdeer and whatnot.
Edit: Just stumbled upon navi, the interactivity looks a lot closer to what we want than tldr and friends at least
They do have Linux and Windows versions coming and claim they’re going to gradually open source it so there’s that, but yeah, doesn’t exactly inspire that much confidence lol
I think Tabby is a similar project, but personally I spin up and throw out terminals very liberally. Tabby had a horrendous launch time, something more than a second which constantly bothered me while trying to work. I’d love to see how quick this is though!
As its name suggests, LogoFAIL involves logos, specifically those of the hardware seller that are displayed on the device screen early in the boot process, while the UEFI is still running. Image parsers in UEFIs from all three major IBVs are riddled with roughly a dozen critical vulnerabilities that have gone unnoticed until now. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process, which is known as DXE, short for Driver Execution Environment.
So, does disabling the boot logo prevent the attack, or would it only make the attack obvious?
Not necessarily, I guess. They’re talking about a firmware upgrade of sorts, and, at least on the machines I own(ed), performing it didn’t reset user settings (which disabling the logo is)
Yes, in my opinion. The configuration of grub (boot loader) is just another step to go wrong, and this will eliminate that possibility. Additionally, it will prevent stupider operating systems (cough Windows) from accidentally overwriting the boot loader during an update.
It basically means instead of relying on a bootloader (e.g. GRUB or systemd-boot) the computer boots the kernel directly. Generally there should be no change besides having to use the BIOS menu to manually select a kernel.
FWIW, a lot of the DIY distros (Arch and Gentoo being the ones on most minds) allow this already so it’s nothing new. It’s just Fedora implementing it that’s new I guess. If you’re curious, the term to search is “EFISTUB”.
I think for most people they won’t care either way.
Some people do legitimately occasionally need to poke around in GRUB before loading the kernel. Setting up certain kernel parameters or looking for something on the filesystem or something like that. For those people, booting directly into the kernel means your ability to “poke around” is now limited by how nice your motherboard’s firmware is. But even for those people, they should always at least have the option of setting up a 2-stage boot.
There are several ways to exploit LogoFAIL. Remote attacks work by first exploiting an unpatched vulnerability in a browser, media player, or other app and using the administrative control gained to replace the legitimate logo image processed early in the boot process with an identical-looking one that exploits a parser flaw. The other way is to gain brief access to a vulnerable device while it’s unlocked and replace the legitimate image file with a malicious one.
In short, the adversary requires elevated access to replace a file on the EFI partition. In this case, you should consider the machine compromised with or without this flaw.
You weren’t hoping that Secure Boot saves your ass, were you?
Ah, so the next Air Bud movie will be what, Hack Bud?
“There’s nothing in the specifications that says that a dog can’t have admin access.”
“Nothing but 'net!”
Doesn’t this mean that secure boot would save your ass? If you verify that the boot files are signed (secure boot) then you can’t boot these modified files or am I missing something?
If it can execute in ram (as far as I understand, they’ve been talking about fileless attacks, so… Possible?), it can just inject whatever
Addit: also, sucure boot on most systems, well, sucks, unless you remove m$ keys and flash yours, at least. The thing is, they signed shim and whatever was the alternative chainable bootloader (mako or smth?) effectively rendering the whole thing useless; also there was a grub binary distributed as part of some kaspersky’s livecd-s with unlocked config, so, yet again, load whatever tf you want
Last time I enabled secure boot it was with a unified kernel image, there was nothing on the EFI partition that was unsigned.
Idk about the default shim setup but using dracut with uki, rolled keys and luks it’d be secure.
After this you’re protected from offline attacks only though, unless you sign the UKI on a different device any program with root could still sign the modified images itself but no one could do an Evil Maid Attack or similar.
The point with m$ keys was that you should delete them as they’re used to sign stuff that loads literally anything given your maid is insistent enough.
[note: it was mentioned in the arch wiki that sometimes removing m$ keys bricks some (which exactly wasn’t mentioned) devices]
Well, not an expert. We learned now that logos are not signed. I’m not sure the boot menu config file is not either. So on a typical linux setup you can inject a command there.
In many of these cases, however, it’s still possible to run a software tool freely available from the IBV or device vendor website that reflashes the firmware from the OS. To pass security checks, the tool installs the same cryptographically signed UEFI firmware already in use, with only the logo image, which doesn’t require a valid digital signature, changed.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.