Head to https://squarespace.com/thelinuxexper... to save 10% off your first purchase of a website or domain using code thelinuxexperiment

Grab a brand new laptop or desktop running Linux: https://www.tuxedocomputers.com/en#


👏 SUPPORT THE CHANNEL:
Get access to:
- a Daily Linux News show
- a weekly patroncast for more personal thoughts
- polls on the next topics I cover,
- your name in the credits

YouTube:    / @thelinuxexp  
Patreon:   / thelinuxexperiment  

Or, you can donate whatever you want:
https://paypal.me/thelinuxexp
Liberapay: https://liberapay.com/TheLinuxExperim...

👕 GET TLE MERCH
Support the channel AND get cool new gear: https://the-linux-experiment.creator-...

🎙️ LINUX AND OPEN SOURCE NEWS PODCAST:
Listen to the latest Linux and open source news, with more in depth coverage, and ad-free! https://podcast.thelinuxexp.com

🏆 FOLLOW ME ELSEWHERE:
Website: https://thelinuxexp.com
Mastodon: https://mastodon.social/web/@thelinuxEXP
Pixelfed: https://pixelfed.social/TLENick
PeerTube: https://tilvids.com/c/thelinuxexperim...
Discord:   / discord  

Timecodes:
0:00 Intro
0:41 Sponsor: SquareSpace
01:45 App Verification and security
04:36 Distro packages aren't really safer
06:46 Sandboxing: no silver bullet
09:07 Distro dependencies are better?
13:07 It's your responsibility to check
14:50 Sponsor: Tuxedo Computers
15:43 Support the channel

Verified apps are an implicit guarantee that this thing is as the developer intended. What app verification isn't, is a guarantee that the package you're downloading is safe, or has no security problems.

If the repo has been hacked, if one of the maintainers for the app is malicious, then the official package will also contain that code.

The security argument will often be used to push people towards distro packages instead of flatpaks and snaps, but this is also not really how things work.

The general view of distro packages is that they can be safer, because there's a trusted maintainer that will create the package, and thus can detect any unwanted change, backdoor, or problem, and prevent you from getting the infected or buggy version of the package.
This is not really the case though.

Log4J, the recent SSH vulnerability, the XZ backdoor, and basically every CVE ever discovered points to the fact that maintainers DO NOT do security reviews on most packages they build. That's not what is expected of them either. A lot of maintainers aren't developers and couldn't conduct these audits in the first place.

https://unixdigest.com/articles/how-s...

https://flameeyes.blog/2022/02/15/on-...

Another big misconception is around the sandbox for Flatpaks and snaps. A sandbox basically just means that the app you're running has a system of permissions that limits what the app can do, and how it can interact with the system. It CAN be more secure than not having a sandbox, but it doesn't mean it IS always more secure.

Another example of the sandbox not doing anything to protect the user is with the recent scam crypto apps on the snap store: these WERE sandboxed, because they scammed you through a web view, a website basically.

Another common misconception around packages is how dependencies work. You'll often read that distro packages use the system dependencies, and thus use less disk space, and are more secure, because you know that the library the app relies upon is updated by your distro, compared to a flatpak, snap or AppImage, where the dev might have bundled a dependency on their own, and never bothered to update it.

First, you CAN check which versions of dependencies the package comes with. A flatpak is open, you can see how it's built. Second, distro packages aren't always up to date either: just because it's a shared library doesn't mean it has all the latest security fixes.

This example will be clearer: MariaDB got a security update in 2021 in November. While Arch and Artix updated things the same day, Debian took 3 months to apply it, and Alpine took 4. Same goes for fixed linux kernel versions: when your distro is locked to a specific kernel version, it's been factually proven that this version becomes more and more buggy and vulnerable over time, as maintainers simply don't apply every fix, and don't backport everything. For example, the current RHEL 8.8 kernel had more then 4500 bugs open that have fixes in later kernel releases.

https://unixdigest.com/articles/how-s...

https://ciq.com/blog/new-research-the...

https://www.debian.org/devel/wnpp/orp...