Balokzx Having a PC with Coreboot or Libreboot, that doesn’t change anything, right ?
Open-source BIOS is a nice to have but it, in absolutely no way, makes the desktop ecosystem any more secure. If you want to discuss this more, there are many threads about it in the forum already and we can pick up the discussion there.
To answer your main question, a recent Pixel (preferably a 9), running GrapheneOS will run laps around the most secure desktop hardware + software solution.
Balokzx The audio editor software "Audacity" is open-source but bought by MUSE GROUP so it is not open-source software anymore.
Is there a source for that?
For example, Wikipedia reports:
In April 2021, it was announced that Muse Group (owners of MuseScore and Ultimate Guitar) would acquire the Audacity trademark and continue to develop the application, which remains free and open source.
de0u https://github.com/audacity/audacity/
Audacity is open source software licensed GPLv3. Most code files are GPLv2-or-later, with the notable exceptions being /lib-src (which contains third party libraries), as well as VST3-related code. Documentation is licensed CC-by 3.0 unless otherwise noted. Details can be found in the license file.
It's not enough even if Coreboot is open-source, Gnu/Linux is not secure. GrapheneOS is recommended for people who want a secure device and software, easy to use, not often to break a system
The only problem I have with GrapheneOS is that it doesn't support ext4 or btrfs. I have no choice of using exFat for my future HDDs
Which threads are you talking? Because there are a lot
I will do that. I hope GrapheneOS will improve their own apps like gallery, video player... (and of course security/privacy)
You mean I configure my ext4 HDDs to exfat? No thanks, because it's a lot of work for me. I prefer not to modify my current HDDs, I buy a new HDD in exFat to use under GrapheneOS. Apparently, exFat is better than ext4 for external hard drives. That's not me saying that. See GrapheneOS's message response about ext4, FAT32, exFat, NTFS
DeletedUser88 Most code files are GPLv2-or-later, with the notable exceptions being /lib-src (which contains third party libraries), as well as VST3-related code.
It appears that the Audacity project distributes (under GPL) some libraries that they receive under other licenses, and that the Audacity project additionally distributes those libraries under their original licenses, which are also open-source licenses (source: https://manual.audacityteam.org/man/license.html#Third-party_libraries).
Is there an identifiable part of Audacity that is genuinely not open-source?
From time to time telemetry concerns are raised about various open-source projects (see OsmAnd issue 15058). Telemetry is an independent issue from whether or not a project is open-source.
Balokzx Anyway, I don't trust Audacity anymore since Muse Group bought it.
That is of course each individual's decision.
PC with coreboot or libreboot
These are not security hardening. They exist mainly for highly insecure devices other than where coreboot is used on certain reasonable Chromebooks. They're a way to implement a boot chain leading to the OS which is generally an insignificant factor in security unless you're trying to provide full verified boot and protect against both persistent remote compromises and physical attacks. The hardware you're talking about cannot defend against either in any significant way so it's really not a relevant aspect of security to those devices.
Kicksecure
This is one of the least secure mainstream distributions (Debian stable) with insignificant changes to supposedly improve security. It lacks proper privacy/security patches and has frozen versions of packages with an extreme level of misguided changes rolling back their security. Debian is infamous for consistently adding security vulnerabilities to packages along with not patching anything without a CVE assignment, while it's extraordinarily rare for them to obtain a CVE assignment themselves. Most of the projects do not do this and therefore the whole approach doesn't work.
Balokzx ext4 and btrfs are non-portable and insecure choices for an external drive. It's highly unsafe loading an untrusted ext4 or btrfs filesystem and they are not portable between machines. It's a good thing Android doesn't misuse them for this purpose. exFAT is one of the only portable filesystems supported by Linux.
Balokzx DeletedUser43 The devices you're talking about do not support secure/verified boot in a real way. x86 ecosystem Secure Boot is an insecure and incomplete implementation. It doesn't matter what coreboot does or doesn't support because you can't actually benefit from it on the hardware you're talking about, which fundamentally can't be used that way regardless of which boot chain and OS is being used. It's pointless to talk about what coreboot can support on devices like ARM Chromebooks if that's not the hardware you're asking about.
If people want to talk about desktop operating systems here, that's fine, but people spreading misinformation will receive suspensions for it. We've cleaned up the thread and dealt with a case of that. The linked thread was a lost cause and has been removed.
DeletedUser46 I wouldn't agree with that. Installing distros or systems like Debian or Arch are very insecure in compairson with Windows and MacOS but its very much less targeted than Windows and MacOS. Typical malware and ransomware are exploiting the layer 8 (mostly), of course there are exceptions.
Hardening Linux is a task you have to invest time and its never a finished product (security is never a product), instead its a task you have to do while using the os. Getting software which will harm you as a normal user is pretty unlikely if you stick to the offical repositories and only use trusted packages from user repositories.
Talking about security problems where the user has no interaction in the process of beeing compromised is a different thing. Linux is pretty minimal in compairson with the alternatives. Attacking Linux devices via network is hard and you can migrate many problems by using AppArmor or SELinux which many distros are using by default. Securing Linux devices against physical access is a harder task. Using MacOS and wiping the device remotly is a very helpful feature and a feature like this for linux devices is currently unavailable.
At the end you will get a secure and user friendly device if you use MacOS. Securing linux to a degree as the same level of MacOS needs some technical knowledge but is not a hard task. You can get linux to a level of security which is more than needed for the normal user because the question is who do you try to protect against. If its some hackers trying to get some bank information you are pretty safe using chromium browsers and isolating apps, which could be an entry, inside AppArmor and SELinux. Hackers are not wasting time for that because they need fast money and investing hours or days just to hack you is a really unlikely scenario and if this would be the case that a group of hackers are explicit to hack you, and only you, then you have a different problem than securing your bank data or other personal information by using a different operating system.
GrapheneOS It would be interesting to hear your perspective of Heads, TPM and hardware key attestation of boot chain. Especially when ported to the recent Intel based x86 systems and running QubesOS or Fedora silverblue/secureblue. I guess it does not match the security standards of GrapheneOS but for x86 it would maybe be a relatively good choice taken the threat model in consideration.
GrapheneOS can you expand on why btrfs and ext4 are insecure?
Obviously not an official response, but you may find these two links helpful.
A preview post from Privsec.dev on Heads.
A X thread about TPM (Nitter link)
DeletedUser46 I can confirm that the Apple world is the simplest and most secure for 95% of people, while the rest have to be dealt with on a case-by-case basis.
