Flatseal VS coreboot

And not only that, the idea of portals is, IMO, misguided. See this view/bugreport when a flatseal user understands that even though they restricted permissions to access a certain area, the flatpak, itself, can ask to open files there and if OK'd that will be allowed. Their expectation is that with the overrides say "no access" it means "no access even if the flatpak asks very nicely". https://github.com/tchx84/Flatseal/issues/196

Since you installed the programme via Flatpak, you should simply lack the necessary rights (https://docs.flatpak.org/en/latest/sandbox-permissions.html). You can extend the rights quite easily with https://github.com/tchx84/flatseal.

Yes, filed https://github.com/tchx84/Flatseal/issues/196 a while ago, got no joy.

One design feature than can turn into an issue in some scenarios (usually dev tools) is the permissions of a flatpak. In case I need to tweak things, I use Flatseal. I know you can manually do this from the command line but I don’t change permissions that often so I don’t bother learning how to do that.

Does the Flatpak Permissions Settings replace a tool like Flatseal?

What about flatseal then ? https://github.com/tchx84/Flatseal

https://github.com/tchx84/Flatseal (Also on Discover. For security reasons, the Discover store installs apps as sandboxed "flatpak" apps. This one is used to view what each up can do and change the permissions of apps. May be required if the sandboxing breaks something, though usually not required.)

I believe it does. As an example if I try running Godot from the Steam flatpak, it won't be able to see any of the contents of my ~/Projects folder unless I explicitly allow the steam flatpak access to that directory that via flatpak's CLI options or using Flatseal

Why BIOS (did you mean UEFI?) when it runs the best boot loader, which is Coreboot¹. Many users would love to re-flash their bios/uefi for it, if it’s supported.

1: https://www.coreboot.org/

Coreboot is 0.6% C++.

NovaCustom ; some models come with Dasharo a coreboot distribution.

You can also use Mr. Chromebox Script to install Coreboot on your chromebook to get a UEFI BIOS on your Chromebook and then you can go an install either a linux distro or even Windows if you want. It's a pretty straightforward process and also reversable if you want to go back to just using ChromeOS.

Some models are available with Dasharo a [coreboot]https://www.coreboot.org/) distribution.

why no haswell_ult_dmi_registers for broadwell? in https://github.com/coreboot/coreboot/blob/master/util/inteltool/pcie.c

use croshfirmware.sh from https://github.com/coreboot/coreboot/tree/master/util/chromeos

There may be other protections to restrict SPI flash access for security reasons (so you might not be able to flash your custom firmware in the OS), but worst case you can use a HW flasher (or maybe USB flashback). Still, this doesn't address the elephant in the room - platform initialization code might be open-sourced, but that isn't everything. You'll still need to figure out the board-specific stuff (the Super I/O chip, chipset GPIOs, other peripherals, etc.). Using coreboot as an example, Intel provides the Firmware Support Package blob to handle platform initialization. I think AGESA is somewhat similar to this, though Intel publicly releases the binaries for use in coreboot/etc. Thanks to the FSP, coreboot has support for recent Intel chipsets. However, there is only support for two recent consumer boards: the MSI PRO Z690-A WiFi DDR4 and DDR5.

does anyone know what is https://github.com/coreboot/coreboot/blob/b12caef23bc1b29c2e658f2b728cc4beac1e62b9/src/northbridge/intel/haswell/vcu_mailbox.c

Download crosfirmware.sh and run it from command line: bash crosfirmware.sh droid