PinePhones are fairly cheap linux phone devices

Surprised Google Meet isn’t on there

Obviously AMD and Intel don’t include HDMI on their cards.

/s

The only real fix to this is to have the extensions confirm that they want their information to autofill. We have come full circle. Users do not like having to confirm autofill on every page.

Also, clickjacking isnt limited to password managers. Even if a user is very careful and manually enter credentials themselves, this can still affect them.

If you do not have autofill enabled, then you are not affected by this vulnerability. It has been recommended for years to not use autofill. Always clickfill your data when you know you are at the trusted destination.

Huge

I thought I saw something that the bazzite project might end once Fedora moves away from the 32 bit packages:

https://www.gamingonlinux.com/2025/06/bazzite-would-shut-down-if-fedora-goes-ahead-with-removing-32-bit/

Turning off secure boot wont turn off your TPM, it just turns off all the signature verifications. Your TPM still stores the decryption keys and you can still decrypt your data.

Now if you do a UEFI/BIOS update without disabling your encryption while using a TPM, and dont have password decryption as a backup, yes, you could potentially lose access to your data.

I wish all the firmware for every motherboard was made public and open sourced. Even if a company has proprietary firmware/drivers, I would hope that once that product reaches end of life that they do in fact open source that code so that someone else can pick up where they left off.

I 100% agree that they should not brick their hardware once it reaches end of life. There might be someone out there who would take on the task of maintaining it, which is better than nobody maintaining it.

Sounds like the devs have spoken then.

Its funny because the release notes for their December '21 BIOS update says:

Major vulnerabilities updates, customers are strongly encouraged to update to this release at the earliest.

And many of their release notes say that they fix security issues. I would say that supercedes the footnote at the bottom that says to update your BIOS only if you’re having issues.

Plus, doesn’t Gigabyte have A/B BIOS updates? So if you have a failed flash, you can switch to the previous BIOS that was working?

No.

You want it, build it yourself. Or pay devs to do it.

Some vendors still have a red flag on their support page discouraging uefi updates unless you’re actively experiencing problems.

I dont know which vendor you are referring to, but that is a horrible practice. There should be active support and release notes stating that “This release is a security fix” at a bare minimum. If your motherboard manufacturer does not offer that, then I could never recommend them to someone. They need to be held to a higher standard.

At least from my experience, ASUS, Dell, and Apple will publish that information.

Even if the code is there, you will need someone to maintain that code. Easier or not, even in a git repository, those individual components will eventually not have the support necessary to patch it.

If an eight year old usb controller has flaws, and the manufacturer is not maintaining that git repository anymore because they cannot possibly afford to hire someone to look at that code after so long, then it is going to keep those flaws. It wont matter if that code is proprietary or open source and included in coreboot. Its just simply not feasible to support hardware properly once most of the world has moved on to other products.

Generally, motherboard manufacturers source their components from other companies. They do not manufacture the entire board themselves. This includes CPUs, Wifi cards, USB controllers, bluetooth, audio, display controllers, etc. Each and every one of them create new products, maintain their own firmware for all those new products, and push updates to the motherboard manufacturers when there are updates.

Coreboot/libreboot do not update those components themselves. They also must be provided that source code.

Just for coreboot alone, the last release had more than 120 contributors push over 900 commits. One person is not able to maintain that piece of software, as it is an enormous task.

AMD are generally quick with providing microcode updates. Once they have them, they provide them to your motherboard manufacturer to include in a firmware update. This is the part that usually takes a while, if done at all.

No idea. You can use something like jackett to generate an RSS feed for you if they dont have one.

Maybe they have a newsletter for updates, or a registration card, social media account, or maybe a security team that announces security updates.

All im suggesting is look into how your manufacturer announces these updates and actively listen to that communication.

IMO, keep an rss feed of your vendors firmware updates being released on their website or periodically check it yourself. As soon as its released, go ahead and install it. If you want to be cautious, maybe give it a week or two to make sure they dont pull the update due to issues with that particular release.

Even better, if the manufacturer offers a utility to keep updates installed, just run that periodically.

As much as I would like to agree with that, each piece of hardware is going to have its own niche set of problems that the coreboot/libreboot team is not going to research and maintain. It wont be because they dont want to. They just dont have the resources and source code from the vendors. You will get your standardized updates, but it will not cover a lot of the proprietary blobs necessary for the hardware to operate.

Once the vendor stops supporting it, thats it. Its a ticking time bomb. Its how we get articles like the one in the OP. The vendor and user are not going to put in work to keep this updated. Even if they had coreboot/libreboot, it wont get updated.

Its a shitty thing that isn’t easy to solve except by tying in hardware and software into single, unified products that are written in perfect code. Its not possible.

I know Ill get flak for this, but you shouldn’t be using end-of-life hardware, including motherboards. Once the vendor stops providing firmware updates, its time to look at replacing that hardware. It doesn’t matter what operating system you use, if there are hardware vulnerabilities, then your OS isn’t able to properly protect you.

If your hardware is still supported, you should regularly be updating the firmware.

What files do you have in /dev/nvme0n1p1?

From the looks of it, that should be your linux boot partition.

If you can, just remove every other drive temporarily while you focus on that specific drive. This will help avoid making changes to the windows bootloader.

From there, boot into an arch iso, mount your btrfs subvolumes (i.e. /mnt and /mnt/home and /mnt/var/logs and whatever other subvolumes you have), mount your boot partition into your btrfs mount point (i.e /mnt/boot), and then arch-chroot into your system (/mnt).

From there you’ll be in your actual system. If you’re using systemd-boot, run the bootctl install command. This will copy the systemd-boot UEFI boot manager to the ESP, create a UEFI boot entry for it and set it as the first in the UEFI boot order.

If you are using grub, follow the grub guidelines for installing their bootloader (im not familiar with grub commands).

Once that is done, go ahead and run mkinitcpio -P to make sure your kernel images are bootable options for your bootloader.

After that, exit and unmount the boot and BTRFS subvolumes and reboot.

That should get you back into your system.