People easily install these without being concerned about security or privacy. I am actually more curios if these are audited at all or the risk is solely on users?
I use GNOME only in throwaway VM, but even there - only the extensions available in official repository are used.
If you cannot audit it and supervise it, do not offer a point-and-click way to install it. Do not rely on end-users experience and sanity nor the good intentions of random people online.
Installation of Gnome extensions or KDE themes (unless official package from distribution's repository is used) always seemed as unnecessary risk to me.
I posted an idea about sandboxing that I think is a middle ground between doing away entirely with the idea of gnome/kde extensions and themes using sandboxing:
Although I do prefer look and feel of the GNOME and most of the software I use is GTK, I use Plasma as well. The main issue I personally have with GNOME is it's dependency on 3rd-party extensions. For start, it's missing clipboard manager and notification tray that you get with Plasma out of the box (as well with other DEs and OSes). You want the dock? Again, you need the extension. Then you upgrade and at least one of the extensions is lagging behind.
I knew about Trinity right from the beginning of project (back then it was available in one of the Gentoo's overlays), but I am genuinely surprised it is still running and they actually introduce new features to the DE and applications. It is remarkable effort.
I went this rabbit hole roughly 2 years ago and I just quit at the very end, because my focus went from using the OS for something productive to maintaining it, securing it and becoming home sys admin.
Since then, I’m simply “ignorant” and sane - use it, update it regularly, use official software sources (so official distros repos and Flatpaks), FDE, SecureBoot, do not run random net stuff (like scripts, “Git” etc.), try to stay as default as possible and use a VM to experiment if I really need to.
I am curious - how many of you regular desktop Linux users actually had security issues (or at least suspected something shady)?
As great as flatpaks are for providing sandboxing, the problem with them is that they are upstream software. When Audacity added telemetry it only affected binaries downloaded from them, not distro-compiled binaries. When firefox stops you from loading your own extensions, that's because you're using a binary downloaded from them, not distro-compiled binaries. A decade ago I used to think distro package maintainers were unnecessary middlemen who were just introducing failure points (like the Debian openssl fuckup), but today they are truly the last line of defence from malicious upstreams.
Even if something sneaks into a distro package it's possible to convince the distro package maintainer to disable it, because the maintainer's interests are aligned with you and not upstream.
1. My point was about using upstream software, not about the Audacity flatpak specifically. Audacity binaries downloaded from upstream's website have the problem I mentioned.
2. The Audacity flatpak is maintained by a Flathub dev only because Audacity upstream has not expressed an interest in maintaining it themselves, not because of some Flathub policy to reject telemetry etc. If they wanted to maintain the flatpak themselves they would be allowed to do that, since Flathub policy is to have upstream developers maintain their flatpaks. And that would lead to the problem I mentioned.
But you can get alternatives which have the telemetry removed. Like VSCodium and some Firefox forks. And instead of every distro needing to do those patches themselves, they can share the effort.
Maintaining a firefox fork is a much bigger job than putting `--with-unsigned-addon-scopes=app --allow-addon-sideload` in the package build script.
Distros already share effort implicitly because maintainers of distro X often look at what distro Y is doing for that package. Also users compare distros frequently and will tell the maintainer of distro X that the same thing works with distro Y.
I misremembered. The effect is that you don't get the "Restart required" message, but the implementation is that they just postpone applying the update until your next re-open.
> We also are not trying to force you to install updates before you can keep using Firefox. Firefox's update mechanism downloads updates while it is running and installs them at startup. ... In the case of Bug 1705217, the package manager updates Firefox's files on its own schedule that is outside of Firefox's control ... Firefox had no intention of forcing updates to be installed at an inconvenient time.
That is not a difference in behavior between distro packages and upstream Firefox. If an update gets installed then FF requires you to restart it. So just like the upstream binary's updater doesn't install the update while you're still running it, you shouldn't update the distro package while you're still running it either.
No, if you update upstream Firefox you'll see a prompt inviting you to restart when you want. If you update distro Firefox you'll see a page blocking everything telling you you need to update now.
That's because upstream Firefox separates out downloading and applying the update.
> Correct. And that's what I'm telling you to do with your package manager as well.
Please inform me how to automatically have my distro package manager download updates and install them on the next open. Note that it's critical here that the install is perceptively instant: it means I'm never waiting for my browser to be available.
Now why would I do that? You originally asserted "Conversely Debian broke Firefox's ability to update without requiring a restart" and now you know that Firefox doesn't have the ability to update without requiring a restart. Any further shifting of your goalposts is your problem, not mine.
I did shift the goalposts once because I was wrong. In my second post I expressed that Firefox's built-in update manger still did something much better than the distro package manager.
You asserted that was not the case, so I asked you to prove it. If you don't want to you don't have to, but I'll assume you admit that the distro package manager is in fact inferior.
This doesn't make *any* sense. Even in the example you gave, Mozilla really wanted to block you from using extensions, they will just remove the entire store.
It doesn't make sense because you need to read carefully. I said "loading your own extensions", ie loading extensions not from their store but by dropping a .xpi in /usr/lib/firefox/browser/extensions that you made running `zip` and changing the filename.
This is pretty much the best approach, currently, and probably into the far future.
When I need to run a program from a dev I don't fully trust to behave well (e.g. the app is closed source for no particular reason, has known extensive telemetry, or has an unhealthy tendency to fuck with configuration files), I run it in a firejail, container, or reboot to windows.
For everything else I fancy the thought that everything I install being open source and looked at by multiple people including a package maintainer means that there's a significantly lower chance of easily exploitable vulnerabilities (e.g. in system config and general program behaviour), and an almost nonexistent chance of outright malicious code.
I recently shut down my last Linux box and I do not run Linux at home anymore. However, I did run various distros of Linux on the desktop from 1999-2022. Prior to that, I ran Minix and OpenBSD on my desktop machines, starting around 1992. So let's say 30 solid years of Linux on my desktops.
I never ever, never once had any security issue. I never had an issue with malware being installed. I never had an issue with external malicious users accessing my system - not even DDOSing my network.
In fact, I have run Windows as well since version 3.1, and DOS before that, and I've never had a virus or malware on Windows, either. Not a single compromise or glitch at all.
Once, I was a guest at a friend's house and I discovered that he had fallen victim to some sort of replicating virus on his Windows 98 system. I was able to manually eradicate it for him, without resorting to commercial anti-virus software.
A few weeks ago, I did discover that my home router had been compromised and some sort of malicious DNS service had been installed on it. So, I must confess to my first-ever home network compromise, albeit an embedded router OS I had little control over.
That's how Rust installs. I'm not that happy with it but at the time (years ago) the distro (Debian) packages were incomplete. From https://www.rust-lang.org/tools/install
It’s hard to prove a security issue but “shady” describes my experience with most all modern OS’s. I trust Linux the least but it’s my daily driver. I just assume it’s comp’d because at some level (NSA at least) it is. I also try to reinstall a fresh distro at least quarterly, but even on a fresh install don’t trust it. If I can’t trust all of the devices on my network (I don't) then I also don’t trust my network. If that’s true then no device on the network can be trusted. Until I own and administer every device on my network, there’s no way around that. Even if I did trust all the devices I also have to trust the isp and the router manufacturer (which I certainly don’t).
>I am curious - how many of you regular desktop Linux users actually had security issues (or at least suspected something shady)?
Replace Linux with OSX or even Windows in this statement and i wouldn't expect crazily different results from a crowd that follows the best practices you outlined.
Have you got SecureBoot working well on Linux? My last try was with Fedora 34, and I had to manually reinitialize TPM with every kernel upgrade. One of the serious issues that keeps me on Windows.
Don't worry about it: Secure Boot is (currently) 100% pointless on Linux because the initrd is not authenticated.
Once the work described at https://lwn.net/Articles/918909/ this will change, and , and kernel updates should no longer require will (hopefully?) no longer require re-initializing the TPM.
Well, all my machines use Arch Linux with custom Secure Boot keys and unified kernel images (essentially, the kernel, the initrd, the command line, and the splash screen fused into one EFI executable and signed as a whole). So on my machines, the initrd is definitely verified. Thanks to Foxboron who made this easy with sbctl.
An entirely different matter is that the default Microsoft keys allow running all other distros, with their GRUB which allows to load initrds without authentication - which would allow evil-made style attacks by replacing the whole boot chain and the kernel. So in my world, all builds of Shim and GRUB are malware, and keys that allow booting them are not allowed in the DB.
It is about full disk encryption with automatic unlock during boot. One needs to make TPM dependent on a successful secure boot to allow access to decryption. The boot completes no problem, but the TPM entry that controls access needs to be manually recreated with each new kernel update.
To defend against an attacker with physical access to an offline machine you need to verify anything that the attacker can overwrite without the encryption key. Aren't bootloader and kernel on the writable unencrypted partition?
The signature that's validated by secure boot. If you don't have secure boot turned on then there's no point in verifying PCR 7, because all PCR 7 contains is the secure boot data.
Gentoo ended my distro-hopping phase back in high-school/college student days (17-18 years ago). Top class documentation (the title moved to Arch in the meantime) and helpful, supportive and knowledgeable users of their community taught me so much about Linux. Additionally, although I'm not educated nor working in CS field, Gentoo got me curious about programming languages, build systems and compilers (as a hobbyist). I used it happily and exclusively for 6-7 years (then moved to Windows at work and Mac at home).
From summer of 2020 I restarted with Gentoo on my new home desktop.
I've been using Gentoo for years on my home desktop. Nothing has ever broken. Things are so much easier now than they used to be 10 years ago. I do run a very minimal system, though. I use sway as my window manager and no desktop environment. My hardware is pretty basic (mostly Intel).
I run Ubuntu on my work laptop (with i3 WM). Despite my desktop having a very measly dual-core Intel Pentium G3258 (a 10 year old budget CPU, although admittedly overclocked to the max) and my laptop having a much more recent quad-core i7, the Gentoo box absolutely flies compared to the Ubuntu one.
I've also successfully run Gentoo on an old Atom powered netbook. The only problem is it's too slow to run Firefox and the "modern web", but that can't be helped. I compiled the whole system on the netbook, although nowadays I would set up cross-compilation if I were to do it again.
I am running “full-blown” desktop with relatively minimal Plasma (I installed only the KDE software I actually need). The initial setup was quite straight-forward, without any tweaking or particular issues. I do use binary packages (available in Portage) for the stuff I do not care - like LibreOffice or Rust compiler.
Upgrades where you are expected to do something rarely happen and even then it is fairly simple.
The major downside is when you want to try out something - it takes time usually, so it is not instant as with binary distros and other OSes. For now, when I am not willing to wait, I just use Fedora VM to test stuff first.
Kde, wayland and pipewire are alright... I'm not sure what desktop apps you use, but I don't run into many cases where something isn't in portage... My personal overlay only has 3 packages in it.
