I think is also worth to point out that these issues are the same for exes on Windows, in case someone thinks this is specific to how Linux distributes software
Generally with computers that arent "smart" devices. When using a personal computer, it's the user that has to trust what they run, not some supervisor. That's the difference between a device you own and a device you use within limits.
It should be pointed out that 1) With an unverified Flatpak, you have to trust the original dev *and* the maintainer not to be malicious, hence the "security" argument 2) Would have appreciated more details on Flatpak de-duplication. Because it uses shared runtimes, installing a Flatpak for the first time can often be a big download, but these runtimes will be shared among your installed Flatpaks - this is the same for Snap. 3) On top of that though, *Flatpak goes the extra mile* by using de-duplication, which ensures that if any of your apps or runtimes have the same libraries or components, those will be reused between them and not re-downloaded, saving both network and disk space.
Deduplication does not work properly unfortunately, it has a lot of bugs, especially when it comes to Nvidia driver versions and Gnome platform versions.
That would be a very much appreciated topic. I have yet to set up one of them, but have no idea on the pros and cons of each. I believe apparmor supposedly has more overhead, but SELinux is more symptomatic and retrofitted in it's restrictions.
Naa, create your own operating system. In fact create all you components from scratch, create your own cpu architecture and case, make your own colour and if you are super paranoid, create your own universe.
@@k1ry4n more so than most typically do, i may not be able to write code but i have mot had a program hijack any computer i have had or currently do. Even if that does happen i can wipe the entire pc and reinstall, i keep isolated backups precisely for that purpose.
@@patryn36 I used to write code but I would never gave a statement like yours. I don't fully understand anything, especially the true nature of the world (whatever it means). All our knowledge is partial at best and we can be expert in a very few selected things, while being ignorant about everything else (that means 99,9% of human knowledge). It's not my intention to attack you because I understand what you really meant. I just wanted to underline how even in a specific field our understanding is very far from being 'full'.
@@pyepye-io4vuyou almost always run all payloads on top of the container orchestration platform anyway. The underlying OS is only used to run that container platform. At least that's how a server is usually configured.
On debian I use apt packages as much as I can. Because debian has a security team that audit them and has a massive infrastructure for that. But I also have some flatpak apps. I also have some web apps that I installed with gnome-web.
Regressions are also a thing - I have now multiple times witnessed python just breaking stuff and saying, we'll eventually get around to fixing it in some future versions. And users complaining about broken things. So as a maintainer, you might want to lock to an old version, which you can do in flatpak. All while arch users are complaining and windows installs are crashing.
@@pyepye-io4vu the average user is also the one most targeted by anyone who wants to make money. Something Linux doesn't have, which is why its still so low in terms of usage. They need to cater to these people.
The real issue is the theater. Like when we become convinced that something is safe, then we will be more likely to engage in reckless behavior. The more secure we think our computers are, the more we forget good practices. A lot of things are that way too, other then computers.
Definitely the truth, like the people who brag about linux being used on servers as if they have the same security suites, IDS (Intrusion Detection System) and EDR (Endpoint Detection and Response), when really they dont even have SELinux or App armour configured for a majority of their apps
Imo deb is the best we have right now. I see the potential in flatpaks, but a couple of flaws are quite critical imo. See my post in the main level for why.
I have been Linux-ing for about 15 years now and have used nearly every distro at least once. Distro packages suck, plain and simple. Maintainers LOVE adding their own special sauce to packages and this creates situations where there were different config files, default options, binary locations, package names, and even package contents between distros. To say this hurt Linux adoption and made life harder for everyone (even experienced users) would be an understatement. Flatpak has completely changed the game. Portable apps running as the developers intended from a centralized repo that is noob friendly? Incredible. Now we just need an official GUI.
Thanks for explaining about package security and glad there is effort to make it more secure. I often wonder about Linux having malware; on Windows we were quite use to it.
As a general rule of thumb, I use the distro package. If there is an official/dev supported flatpak or snap, and the distro package isn't official/dev supported, I might use that instead. That's pretty much it.
I migrated to mint and installed some flatpaks. Install was easy, to make them run was somehow a quest because I needed flatseal to manage how the sandbox permissions. The biggest problem with flatpak is: updates for flatpak runtimes EVERYDAY. That’s insane
At the end of the day, installing an app on your personal computer is like inviting someone to your home. Will you let any random ass enter your house? I imagine not. The good part about pcs is that you can make a "fake home" and install all the trash there.
@@tablettablete186 There are ways to lock down the app absolutely so it's impossible to escape, but things tend to go both ways and now you can't access the app at all and you may as well have never installed it.
An awesome afternoon surprise. Nick is back. As I have said over and over -- Linux as an OS is solid as a rock - period. The thing holding it back is the application layer. The Linux desktop needs an integrated layer of core apps to make Linux pleasant and easy to use for day to day computing. Getting coherency on DEs and the "app stores" are key to that.
Regarding the security, XZ is in fact a good example. I suppose distros can improve based on this experience, and might add some automated scans of the code in their build pipelines ? If we have a centralized build pipeline we can do this kind of things, and improve the pipeline each time we can, whereas when it's built by a project directly for a flatpack we cannot set security standards (it's obviously a lot worse for proprietary code for which a package is built by a company and pushed to flathub).
xz was a social engineering attack. There is very little that can be done about that from the technical side. It's the human factor we need to tend to: support good devs, push the political activists out of software (see recent stuff like Nix).
I still trust packages created by the actual developers of the application more than some (often unknown) third party doing it. Hence I rarely use the app portals that come with many distros nowadays and always try to find the website of the software I'm looking and follow their installation instructions instead, even if that means I've got to install a deb. I'm aware this isn't necessarily more secure, but at least I know who's responsible when something goes wrong (besides me for my decision to install a .deb).
You're right. This should be everyone's 101 security practice. No one is checking Flatpak's manifest every single time before they update each of their apps. Unverified apps should not be taken lightly.
I like that this video tangentially tackles the lasse faire bro attitude towards security it seems many linux bros have where they say things like linux doesnt have malware or linux is more secure but in reality, who is setting up app armour or selinux for every app they havent personally verified. They talk as if they have the same security suites, IDS (Intrusion Detection System) and EDR (Endpoint Detection and Response) as servers when really they dont even have SELinux or App armour configured for a majority of their apps
I install a lot of native software. People who say it use the OS dependencies aren't right. There's a lot of packages have their own bundle of libraries and dependencies. Not rarely, you need to install dependencies from third-party sources. It can also pretty messy and cause conflicts. Wasn't able to install Proton Pass along side to Proton Mail and Proton VPN because of dependency conflict between the fork of a Proton dependency in Proton Pass with the original version used in the other Proton products. They solved it in the meantime but it was there.
except for system packages I really do not see the point of distro packages. They sound good in theory but in practice why distros must invest so much time in maintaining lots of apps? Just the system packages is enough work and it is not like they have a lot of resources.
6:11 However, the maintainers of the distro packages were informed before the regreSSHion vulnerability was officially revealed. So they could prepare updated packages.
The issue already starts with the phrase "X is is more secure then Y": As if security would be a value on a scale from 1 to 10, which you can compare. Security has so many aspects, that you cannot claim X is more secure then Y for any piece of real piece of software, without limiting yourself to a certain aspect of it. As a community, we should focus on identifying security issues and find a way to fix them as good and fast as possible, instead of doing pseudo-discussions, which method, software or approach is in general more secure then another.
Snap is pretty secure too but similar issues as with Flatpak. It's bulletproof depending on the caliber. If the caliber is big enough, means if the software has the right exploits, it still can penetrate. But like armour, some protection is better than no protection. Even if a tank can resist any weapon, it is still better than a normal car when it comes to protection.
Missing the entire point of the video. No system is inherently safer than the other. You can have a perfectly safe AppImage and Malware Flatpak App that nukes your system.
@@alicethegrinsecatz6011 Problem is with snap the community can do nothing about its security. Snap's distribution is closed source, with no ability for other people to host their own services. This means the people whom use it are at the mercy of Canonical and their interests, if someone makes a pull request to change or improve the security model of snaps Canonical could deny it for any reason they wanted. Flatpak could do the same yes, but developers could also fork the project and introduce the changes themselves.
The only things I'll use are flatpaks and distro packages. These seem to be the most reliable and fastest. As for security, its pretty much a non-issue. There is nothing that is 100% safe.
Finished rewatching your package formats vid and this one. Interestingly I've learned most of the stuff you mentioned in one way or another from your videos, documentation of packages, forums, and just exploring stuff. I'll be looking more into the Flatpak permissions management, maybe using Flatseal since I don't use Plasma. I still like your stance of using whatever works as it is very open to people using whatever they want instead of what the elitists from a lot of Linux forums do and push people to use Arch for the AUR or compiling everything by hand like the Gentoo way (which honestly starts to look more like a meme the more packages one has to maintain on X number of systems). For me that's a mix of native packages (DEB), Flatpak, and rarely AppImages and compiling from source.
While getting apps from the distro store is always going to give the best performance, being able to use something like Flatpack that is essentially able to run the software in its own dedicated software environment without relying on all the system apps the particular app you want to run needs being either pre-installed or in the distro store. The reason I feel the need for this is that I have had several instances of where an app needed a certain version of some background app that has either been depreciated due to a newer version being available or just not available in my distro which stopped the native program running.
Sandboxing frustrates me. Ive had a couple of apps now where i couldn't load files from my data drive and had to copy them to home before using. And OBS is a major complaint i see from youtubers, with specific hardware not visible in the flatpak version, but visible in the deb version.
You have to give flatpaks access to your data drives, obs has been working perfectly for me with hardware accelerated video encoding including av1, and I haven't had a single problem with light/dark theming issue since I've been on gnome.
cool video. i think that sandbox with permissions are better than normal packages in the sense that they have security switches like camera, files etc. but they are not a big deal because most apps wont work without most of permissions on, which inutilizes the security aspect, but its better than nothing. but, conteiners have the other good aspect that is it is easier to mantein for the developer and easier to install for the user. also you can install multiple versions of programs i believe. the advantages of normal packages is that use less disk space and the dependencies are easier to be manteined and updated as you only have to do the work one time, contrary to the flatpak where if the library is in multiple packages every developer would have to update the library. although the normal package approach is not perfect as explained in the video. the good thing is that with Nix like approach you can also have the benefit of having multiple package versions which increases the value of normal packaging. so i think Nix like packaging is the future and is somewhat better than conteiners/flatpak, though flatpak is nice as alternative if not spend that much resources in that
Just goes to prove that every time a human being creates something, another human comes along and figures out how to turn it into either a weapon or a tool to gain advantage with or both.
Not true. Portals let sandboxed apps access content of the system but in a controlled manner. For example, say Firefox is a flatpak and has no access to your home folder. But you want to upload an image to a website. Through portals, Firefox can access just the image you to upload.
@@that_leaflet If a user takes away filesystem permissions of a flatpak knowingly, it should therefore not be able to get any files at all, shoud it? But what you are saying, if I understand correctly, that if I interact with the filesystem in such an app, that has FS permission, it would ask the host system to open a file browsing dialog, let the user chose the file or folder, which then gets passed into the flatpak app via a portal? And for that whole process the flatpak can not access anything in that dialog or the filesystem?
@@mayonaiseking Yes. The app doesn’t have access to the file until you give it permission to it (by selecting it into the file picker). Portals were made so that permission can be dynamically given (with a permission system) rather than static locations listed in a flatpak’s manifest file.
To be fair Users don't want safety. The point of those formats was to keep a compiled package working for at least 2 major releases with no need to rebuild
Imo the what Mint team said does not sound confusing to me at all. Who knows what an unverified app that a random joe put together might contain. so yes, of course, it is a security risk. We all accept that legit apps can have security flaws, nothing is completely secure, whether it be a flatpak or coming from your distro package manager. This was an L take tbh
Yeah, this is just people hating on Mint for the sake of hating on Mint. "Why don't you ditch Ubuntu and go Debian?" "Your distro looks so old and dated" bla bla.
With openSUSE for example to get full codec support you need to enable a 3rd party repo. In that case it probably makes more sense to install the flatpak version with integrated codecs. For not only "security" but also potential breakage since packman replaces a lot of openSuse provided stuff and it often lags behind a bit so you can get errors when updating. And installing flatpak as user instead of system seems to be a good choice as well.
Those breakages can be prevented with Distrobox. It's much better to use Distrobox than Flatpak in some cases, e.g. Chromium-based browsers, as they have to circumvent Flatpak's sandbox with Zypak, in which doesn't comparable to Chromium's native sandbox, security-wise. Moreover, they all lack a proper support for PWA. Widevine support is also not possible without exposing filesystem=host-os, hence making Flatpak sandboxing with Chromium-based browsers not relevant.
Very informative, thank you. Still, I've been using Linux for 17 years now and have never had a virus or security-related problem, unlike my experience with Windows..
The issue with "verified" tag, it is his name. It verify the origine, which *we want* to have. But it doesn't verify the code itself, which we should know. It should have an other name ! There is also the issue of alternative version where their alternative origine has been verified. Instead of "verified" or nothing. We should have "Original origine", "Alternative version", or "Unverified origine".
Tbh I don't think it's possible to make a package safer than what we have. At the end of the day you can always find a point in the development process where one can inject bad code, and if you paid attention, all the ways the current formats became unsafe nick mentions basically boil down to "the app dev is malicious/made a mistake" or "app is outdated in some way" which, how are you gonna stop it with the package at that point? If you download malware, it's still gonna be malware. The only way to make malware "safe" through packaging is to lock it in a private airtight room without an unlock option. At that point, that format is useless for packaging. Linux formats and apps are safer bc you can audit them. You can independently verify if someone is trustworthy. That's how exploits are caught. Literally, the only reason xz was found is that someone compiled it on their own and noticed an anomaly.
As you say, we can audit our open source codes. What would be safer for Linux is to create a network to share what audit has been done on what (even on what version and what parts of software (we can do partial audit on most critical parts which is better than nothing and less than everything) ) to know how much safer each thing is, and what needs more to be audited (base on how much people use it vs his known audit and his criticality).
Also "verified" is a very misleading name for origine verification. Instead of "verified" or nothing. We should have "Original origine", "Alternative version", or "Unverified origine".
Currently a lot of good work is duplicated across all the different package formats/distros. If something like Flatpak or Nix became more common, instead of 10 maintainers each having to package the same package for each of their distros, they could be working together or each have fewer packages to maintain. As a result perhaps there is more time for spotting security flaws or bugs, and the quality and thus the user experience would improve. The packaging process itself might become a bit more complicated when they're targeting a wider variety of distros, but I'm guessing it would still be a favourable trade-off.
A little out of the scope but what about Bottles ? I use Bottles to run Windows visual novel that aren't available on Steam. I don't change any of the default settings and it works great out of the box. Are these Windows executables only able to act in the folder and subfolders from which they are launched maybe ? I wonder what a designed for Windows malware would be able to do if executed through bottles. Unable to steal anything because it's not in the location it supposed to be or because it can only view what appears to be an empty Windows ?
You interpret what I said. I didn’t make it sound like it’s insecure, I said it took away user agency and went against developer’s wishes. A maintainer DOES NOT decide for the users or the developers. If you don’t like how the app works, you stop packaging it. The maintainer did something stupid, virtually everyone agrees, and it goes against Debian’s guidelines as well…
@@TheLinuxEXP >>went against developer’s wishes The dev allows modifications, redistributions. Read the licence. >>A maintainer DOES NOT decide for the users You pick your favorite distro based on what the maintainer will decide, based on packaging policy of that project, if the decisions is somewhat unpleasing to you then, its fine, but clearly you're using a wrong distro; >>If you don’t like how the app works, you stop packaging it. This is a fake dicotomy. No, if it's FOSS you can modify it to work as you like and you're allowed to redistribute it. >>The maintainer did something stupid, virtually everyone agrees, and it goes against Debian’s guidelines as well… Your opinions, and i respect that.
To me, I don't want to be inconvenienced. All the package managers are great until you have to deal with them in the terminal because commands aren't universal but have to be individually referred, they have pros and cons but as a user, I shouldn't get stuck in between.
One of the biggest weakpoints of Snap and Flatpak is, that they are not packaged by my distributions maintainer and are coming straight from the developer. This is something I don't want. I want my distribution to repackage.
Why? It just means more hands touch the pie, and like covered itsa not like the maintainers are doing security audits the vast amount of the time. Its placebo safety vs efficiency and a lessened workload for the developer. Run the apps without full permissions istead. Containers, mandatory access control systems like SELinux and app armour etc.
@@BeefIngot Flatpaks are designed to run everywhere, therefore they are not optimized for my system. I want the middle man, as this is another step to pass. Just because an application comes directly from its developers does not make it better than one from third party. Its like installing any software directly downloading from the website, like on Windows. I don't want that. I also do not expect my distributor to audit the code, but that's not the point. Besides that there are other reasons, like not being able to do everything with one package manager (listings and what not). The file paths are different, its run different and other things. And often trying to figure out why the Flatpak does not work, if I ever figure out it is the Flatpak that is causing the issues, then its wasting my time even more. Flatpak has its place and I even use it, but not because its my first choice. I do not want to use any operating system that relies on Flatpak or Snaps. My OS should have native packages as first class.
6:38 distro do however have a security team that does audit the code, debian has one, ubuntu has one, pretty sure fedora has one too Granted this is also true for flatpak and the snap store (tho still unrelated to unverified/verified)
The rust ecosystem has gone with a redeploy everything "for each application" design, there is shared code but each binary has copies of all it's dependencies internally.
Didn't debian, arch and rpm packages have a integrity checker and if it's not valid they don't install. I don't think apps run by root by default. Never had I run vlc in admin mode in windows and Linux for more than 15 yrs
Windows : Here is the .exe in zip archive. (What do you want auto-updates for ?) Linux : Here are the 7 ways you can install different versions of this app, for your kind of distro. (If none of them work, you can always compile it from source.)
12:12 "this (kernel) version becomes more and more buggy" - To me this wording seems a bit misleading, because it makes it sound like somehow bugs are being *added* to an old version (which kinda doesn't work because changing something would basically make it a new version). A not-so tech-savvy person could entertain the notion that software versions somehow "decay" with age, like hardware (or like humans :-D ). What actually happens is that more and more bugs are getting *discovered* - and thus made public - over time, which is why their list becomes longer, and the potential attack surface - publicly! - increases over time (in some cases though, the publishing of a bug will actually contribute to improving the software's security, provided that bug is fixed swiftly, because before the time of publishing, attackers who knew about the bug, were able to exploit it in secret). It may sound like a nitpick, but I know for a fact that to whoever doesn't undersand software development cycles and security, most statements about security are unintelligible, and they have the weirdest notions about what is "secure" and so on.
There is no controversy on packaging system. There are the old linux users, veterans, with a lifetime of knowledge, who keep using what they have used, trusting on old and solid official projects and maintainers like they always did. And there are the newcomers born from the linux hype in recent years, who know pretty few about anything related to linux, but watch a lot of influencers and blindly repeat what they say to pretend they know more than they actually do. This apparent controversy, which is nothing more than kids noise, also occurs in other subjects such as window managers, text editors, distributions, etc...
Exactly... there is nothing wrong with distro packages (sure it's not 100% but nothing is), distro packages worked for 30+ years, still working. I hope they never change. This is what happens when Linux gets popular and more users...
Traditional distro-based packaging is still the best for you as the user. It requires more work for the developer, but the user benefits most from this packaging format by having a much leaner system that uses less storage and memory resources. In my opinion, there's really no debate here, distro packages are the best for you the user. I only resort to flatpaks if I have no other choice.
@2:05 the demonisation of community packagers and maintainers (the volunteers who build and maintain all the DEBs, RPMs, etc) is a sad development in Linux. They're not just "randoms" you can't trust. They're very experienced, knowledgeable, and they have an impeccable record. Debian is over 30 years old and all in that time there hasn't been a single instance of a community maintainer deliberately inserting malware into a Debian package. Where malware has been discovered, like the recent xz-utils backdoor, it has always come from upstream. I just don't understand the attitude or where it comes from.
Agreed... I am starting to think it's all deliberate. The old neckbeard guys who have been thanklessly doing the hard work for 30+ years are now slowly being pushed out by political activists so they can take over. (Many similar things happening elsewhere too like NixOS) I hope Debian NEVER CHANGES until the end of the universe.
The picture is not as bleak as this, because "Linux" strides both the FOSS and the commercial sectors. So say you are part of the coders/development team at Red Hat Enterprise Linux for example. Your company wants to sell secure servers and workstations. So you will grab some open source code, and test it out in all sorts of ways. Is it functional, is it secure, is it efficient, and so on? Of course, a full commercial version of Linux won't release the propriety bits of the code to the public. But I don't believe that they "re-invent the whole wheel". What would be the point? People can put back-doors and malicious code into programs for a hundred different reasons. You are never going to prevent that 100%. So let's consider a totally closed code. All you have are the compiled binaries. You can't still do behavioral forensics on what is essentially a black-box. Is the app sending excessive telemetry, and to where? Now imagine that most of the code is based on open source. You not only have the forensics as before, but most of the source code as well. So if you suspect malicious programming, that narrows down your search. For example CentOS behaves pretty much the same as RHEL. The main difference is that you can get support from Red Hat if RHEL breaks, and if CentOS breaks, you have to make your own arrangements. Not selling Red hat, or criticizing it. It is just an example. At the end of the day, total objectivity is hard, if not impossible. All we have, all we can have is inter-subjectivity. I will use a religious example. Suppose a devout Catholic has a vision of the "Virgin Mary". No surprise perhaps, but was it true? Unless you can read the person's brain, you will never find out for sure. But suppose an atheist, a Buddhist, a Jewish person, etc, all claim to see the same vision? You still have not got to absolute proof or disproof, but you DO have something interesting. That is why there is such consensus over stuff like gravity. Nationality, religion, ethnic background, age, gender, etc, etc, it is all a common experience. Gravity could be a "shared delusion" of course, but we do have to take it as "working knowledge", because we don't have any other option. Hard Solipsism [we could all be living in a matrix] is simply absurd, because even if we knew the absolute "truth", it would not change anything.
So if I create a random repo as a reupload (not a fork) and the use that to autenticate with flatpak (or another store), and then package someone else's app, will that show up as verified?
Apparmor profiles for snaps are generated on the fly at snap install time and re-generated during snap updates from the interface definitions of snapd. Editing them on disk is a rather pointless action.
I wish AppImage was mlre hewvily invested in for Linux. It makes entry level for new Linux users easier. No looking up how to sudo dpkg -i FileName and what each part means for safety. Honestly wish I understood making AppImages to create ones most new users would want en mass. Ah well, even if I did the originals would probably find some reason to complain.
To be fair it is a mess because you cannot bundle every library you use, most of them can be bundled but the ones interfacing with the host system like x11/wayland library should not be bundled.... making them complicated to make, so the responsibility of the appimage working is fully on the appimage developer.
I use EndeavourOS with arch repo, aur and flatpak. I don't care if it safe or not. I just use what i want. So people have strange paranoia that EVERYONE/EVERYTHING want to hack your pc with everything.
@@AresydatchThe only packages you should NOT trust in the aur, are random packages with like, 1 upvote and 0.00 popularity. Other than that, aur is safe.
I used to be very careful too. Nowadays, I just use Windows to save a lot of headaches. Of course, I still maintain Linux servers, hence why I'm watching a Linux channel.
Head to squarespace.com/thelinuxexperiment to save 10% off your first purchase of a website or domain using code thelinuxexperiment
I think is also worth to point out that these issues are the same for exes on Windows, in case someone thinks this is specific to how Linux distributes software
Yep, I made the same point at the end of the video: no OS is free of these issues
same with steam too
@@TheLinuxEXP Ops, I guess it's a reminder to watch the whole thing before commenting 😅
Generally with computers that arent "smart" devices. When using a personal computer, it's the user that has to trust what they run, not some supervisor.
That's the difference between a device you own and a device you use within limits.
To me, both FlatPak and distro packages have their places, and combining the two is probably the best.
Agreed!
Yep
Yeah, using one or the other exclusively is not sensible, each of them have their advantages and disadvantages
When using one or the other? Is there a pripority decision tree to decide if should go one way or the other?
I don't see the advantage of using Flatpak over system native packages
It should be pointed out that
1) With an unverified Flatpak, you have to trust the original dev *and* the maintainer not to be malicious, hence the "security" argument
2) Would have appreciated more details on Flatpak de-duplication. Because it uses shared runtimes, installing a Flatpak for the first time can often be a big download, but these runtimes will be shared among your installed Flatpaks - this is the same for Snap.
3) On top of that though, *Flatpak goes the extra mile* by using de-duplication, which ensures that if any of your apps or runtimes have the same libraries or components, those will be reused between them and not re-downloaded, saving both network and disk space.
What happens when you download new software that uses components of an existing one and then you uninstall the existing one?
@@D.von.N it keeps the parts it needs
Deduplication does not work properly unfortunately, it has a lot of bugs, especially when it comes to Nvidia driver versions and Gnome platform versions.
@@pyepye-io4vu are you sure, the nvidia drivers are supposed to be fixed in the nightly AFAIK
@@pyepye-io4vu also that's not the deduplication we're talking about. In fact, I don't think what you mean is deduplication at all
I’d love to see you do a video on AppArmor and SELinux!
That would be a very much appreciated topic. I have yet to set up one of them, but have no idea on the pros and cons of each.
I believe apparmor supposedly has more overhead, but SELinux is more symptomatic and retrofitted in it's restrictions.
And Landlock!!!
I use firejail to remove internet permissions per application
Avoid all malware. Build Linux From Scratch. Learn to code and write your own apps!🤣😂😆😁
Naa, create your own operating system. In fact create all you components from scratch, create your own cpu architecture and case, make your own colour and if you are super paranoid, create your own universe.
@@TheSuperTiger2011 there will still be OTHER universes around you🤔🤨
nearly impossible for newbies
Avoid all malware. Build a home in the mountains. Learn to grow your own food and life off the land!
@@balsalmalberto8086 No, that would be for avoiding Genetically Modified Foods
I don't understand how people could think that software could be 100% safe or even invulnerable.
Because they do not fully understand what they use or the true nature of the world.
The average user doesn't even know, basically
@@patryn36Do you and the 10 people that liked your comment fully understand what you use and the "true nature of the world"?
@@k1ry4n more so than most typically do, i may not be able to write code but i have mot had a program hijack any computer i have had or currently do. Even if that does happen i can wipe the entire pc and reinstall, i keep isolated backups precisely for that purpose.
@@patryn36 I used to write code but I would never gave a statement like yours. I don't fully understand anything, especially the true nature of the world (whatever it means). All our knowledge is partial at best and we can be expert in a very few selected things, while being ignorant about everything else (that means 99,9% of human knowledge). It's not my intention to attack you because I understand what you really meant. I just wanted to underline how even in a specific field our understanding is very far from being 'full'.
flatseal serves as a GUI to manage permissions for installed flatpaks
Yeah, Flatseal is very useful and frankly should be a standard install for any distro that supports Flatpak
Plasma has a similar thing integrated to the settings app!
@UrbanistBloomsdo you mean the kde flatpak settings or flatseal
8:20 flatseal is one example to graphically adjust permissions of installed flatpaks, and works like a charm.
I trust the slow but trusted Debian more than anything. It's slow but mostly safe.
Slowness is part of the safety, remember xz backdoor? Didn't reach Debian stable (thanks to slowness).
@@pyepye-io4vuyou almost always run all payloads on top of the container orchestration platform anyway. The underlying OS is only used to run that container platform. At least that's how a server is usually configured.
On debian I use apt packages as much as I can. Because debian has a security team that audit them and has a massive infrastructure for that. But I also have some flatpak apps. I also have some web apps that I installed with gnome-web.
Regressions are also a thing - I have now multiple times witnessed python just breaking stuff and saying, we'll eventually get around to fixing it in some future versions. And users complaining about broken things. So as a maintainer, you might want to lock to an old version, which you can do in flatpak. All while arch users are complaining and windows installs are crashing.
Reminder : The average user just wants to install and use the app and does not care about (or understands) the different packaging formats.
Windows sounds better with each of these videos
@@dageta7742 Except it isn't.
Reminder: the average user is by far the biggest source of security issues, and feels proud of his ignorance and apathy.
@@dageta7742 Windows has the same issues with its packaging formats
@@pyepye-io4vu the average user is also the one most targeted by anyone who wants to make money. Something Linux doesn't have, which is why its still so low in terms of usage. They need to cater to these people.
The real issue is the theater. Like when we become convinced that something is safe, then we will be more likely to engage in reckless behavior. The more secure we think our computers are, the more we forget good practices. A lot of things are that way too, other then computers.
Definitely the truth, like the people who brag about linux being used on servers as if they have the same security suites, IDS (Intrusion Detection System) and EDR (Endpoint Detection and Response), when really they dont even have SELinux or App armour configured for a majority of their apps
Flatpak is not perfect but it is the best we have right now.
Agreed
Imo deb is the best we have right now. I see the potential in flatpaks, but a couple of flaws are quite critical imo. See my post in the main level for why.
Disagree here. Bloat is a thing.
I don't need seven versions of a full runtime just to have several libs.
Nix? Guix?
@@sheikhshakilakhtar1865 What about them?
4:20 this this still on the top of the weirdest moves I have ever seen within the linux community in my life
For real, how do you get such an ego boost for maintaining (not even making) a piece of software for only one specific linux distro? That ain’t normal
I have been Linux-ing for about 15 years now and have used nearly every distro at least once. Distro packages suck, plain and simple. Maintainers LOVE adding their own special sauce to packages and this creates situations where there were different config files, default options, binary locations, package names, and even package contents between distros. To say this hurt Linux adoption and made life harder for everyone (even experienced users) would be an understatement.
Flatpak has completely changed the game. Portable apps running as the developers intended from a centralized repo that is noob friendly? Incredible. Now we just need an official GUI.
As of now, I simply use the GNOME Software GUI with the Flatpak plugin
Crazy that "open source drama" is a big enough topic that you can make legitimately informative and entertaining videos on it.
Thanks for explaining about package security and glad there is effort to make it more secure. I often wonder about Linux having malware; on Windows we were quite use to it.
As a general rule of thumb, I use the distro package. If there is an official/dev supported flatpak or snap, and the distro package isn't official/dev supported, I might use that instead. That's pretty much it.
I migrated to mint and installed some flatpaks. Install was easy, to make them run was somehow a quest because I needed flatseal to manage how the sandbox permissions. The biggest problem with flatpak is: updates for flatpak runtimes EVERYDAY. That’s insane
The runtimes shouldn’t be updating every day. Maybe it’s an issue with Mints GUI for it. Try from the terminal.
It should be noted these are delta upadtes though - the whole runtime isn't downloaded every tile, only the parts that changed.
@@Blueeeeeee you also don't NEED to update daily
At the end of the day, installing an app on your personal computer is like inviting someone to your home.
Will you let any random ass enter your house? I imagine not.
The good part about pcs is that you can make a "fake home" and install all the trash there.
The only problem is that they can escape from the basemen... I mean, "fake home"
@@tablettablete186THEY'RE COMING IN!!!
@@tablettablete186 There are ways to lock down the app absolutely so it's impossible to escape, but things tend to go both ways and now you can't access the app at all and you may as well have never installed it.
People sometimes really think that their packaging format has no disadvantages or issues
If you have ever had to compile a piece of software yourself, you would be happy with any of these package formats
you just install dependencies and run one command, wym
@@lobotomy-victim Man, it ain't never that easy
@@lobotomy-victimTell me you never had to compile a very complex application with lots of features and components without telling me.
@@shayanmoosavi9139 I compile applications for a living buddy
I knew almost nothing about this topic, so thank you.
An awesome afternoon surprise. Nick is back. As I have said over and over -- Linux as an OS is solid as a rock - period. The thing holding it back is the application layer. The Linux desktop needs an integrated layer of core apps to make Linux pleasant and easy to use for day to day computing. Getting coherency on DEs and the "app stores" are key to that.
Regarding the security, XZ is in fact a good example. I suppose distros can improve based on this experience, and might add some automated scans of the code in their build pipelines ? If we have a centralized build pipeline we can do this kind of things, and improve the pipeline each time we can, whereas when it's built by a project directly for a flatpack we cannot set security standards (it's obviously a lot worse for proprietary code for which a package is built by a company and pushed to flathub).
xz was a social engineering attack. There is very little that can be done about that from the technical side. It's the human factor we need to tend to: support good devs, push the political activists out of software (see recent stuff like Nix).
I still trust packages created by the actual developers of the application more than some (often unknown) third party doing it. Hence I rarely use the app portals that come with many distros nowadays and always try to find the website of the software I'm looking and follow their installation instructions instead, even if that means I've got to install a deb. I'm aware this isn't necessarily more secure, but at least I know who's responsible when something goes wrong (besides me for my decision to install a .deb).
You're right. This should be everyone's 101 security practice. No one is checking Flatpak's manifest every single time before they update each of their apps.
Unverified apps should not be taken lightly.
I like that this video tangentially tackles the lasse faire bro attitude towards security it seems many linux bros have where they say things like linux doesnt have malware or linux is more secure but in reality, who is setting up app armour or selinux for every app they havent personally verified. They talk as if they have the same security suites, IDS (Intrusion Detection System) and EDR (Endpoint Detection and Response) as servers when really they dont even have SELinux or App armour configured for a majority of their apps
I install a lot of native software. People who say it use the OS dependencies aren't right. There's a lot of packages have their own bundle of libraries and dependencies. Not rarely, you need to install dependencies from third-party sources. It can also pretty messy and cause conflicts. Wasn't able to install Proton Pass along side to Proton Mail and Proton VPN because of dependency conflict between the fork of a Proton dependency in Proton Pass with the original version used in the other Proton products. They solved it in the meantime but it was there.
except for system packages I really do not see the point of distro packages. They sound good in theory but in practice why distros must invest so much time in maintaining lots of apps?
Just the system packages is enough work and it is not like they have a lot of resources.
This is a really great video!!!
Stay safe on the streets of France. I will really miss your channel if something happens to you. Thanks for your great Linux news and reviews.
6:11 However, the maintainers of the distro packages were informed before the regreSSHion vulnerability was officially revealed. So they could prepare updated packages.
The issue already starts with the phrase "X is is more secure then Y": As if security would be a value on a scale from 1 to 10, which you can compare. Security has so many aspects, that you cannot claim X is more secure then Y for any piece of real piece of software, without limiting yourself to a certain aspect of it. As a community, we should focus on identifying security issues and find a way to fix them as good and fast as possible, instead of doing pseudo-discussions, which method, software or approach is in general more secure then another.
Flatpak is safer than AppImage, not sure about snap.
Snap is pretty secure too but similar issues as with Flatpak. It's bulletproof depending on the caliber. If the caliber is big enough, means if the software has the right exploits, it still can penetrate. But like armour, some protection is better than no protection. Even if a tank can resist any weapon, it is still better than a normal car when it comes to protection.
Missing the entire point of the video. No system is inherently safer than the other. You can have a perfectly safe AppImage and Malware Flatpak App that nukes your system.
@@alicethegrinsecatz6011 Problem is with snap the community can do nothing about its security. Snap's distribution is closed source, with no ability for other people to host their own services. This means the people whom use it are at the mercy of Canonical and their interests, if someone makes a pull request to change or improve the security model of snaps Canonical could deny it for any reason they wanted. Flatpak could do the same yes, but developers could also fork the project and introduce the changes themselves.
Snaps are a tad bit more secure because of Apparmor embedded on them if you use Ubuntu. You can find more info in Privsec desktop hardening Linux page
Ubuntu 24.04 has a GUI for snap permissions management in Gnome settings, under applications.
Also previous to Ubuntu 24.04, there is a permissions management for each snap at the Ubuntu software center app
The only things I'll use are flatpaks and distro packages. These seem to be the most reliable and fastest. As for security, its pretty much a non-issue. There is nothing that is 100% safe.
Finished rewatching your package formats vid and this one. Interestingly I've learned most of the stuff you mentioned in one way or another from your videos, documentation of packages, forums, and just exploring stuff.
I'll be looking more into the Flatpak permissions management, maybe using Flatseal since I don't use Plasma.
I still like your stance of using whatever works as it is very open to people using whatever they want instead of what the elitists from a lot of Linux forums do and push people to use Arch for the AUR or compiling everything by hand like the Gentoo way (which honestly starts to look more like a meme the more packages one has to maintain on X number of systems).
For me that's a mix of native packages (DEB), Flatpak, and rarely AppImages and compiling from source.
While getting apps from the distro store is always going to give the best performance, being able to use something like Flatpack that is essentially able to run the software in its own dedicated software environment without relying on all the system apps the particular app you want to run needs being either pre-installed or in the distro store. The reason I feel the need for this is that I have had several instances of where an app needed a certain version of some background app that has either been depreciated due to a newer version being available or just not available in my distro which stopped the native program running.
Snap has a graphical ui for permissions on at least ubuntu, it is integrated into system settings
I have to rewatch your package formats vid first before watching this just to be sure I'm up to speed somewhat haha
Sandboxing frustrates me. Ive had a couple of apps now where i couldn't load files from my data drive and had to copy them to home before using. And OBS is a major complaint i see from youtubers, with specific hardware not visible in the flatpak version, but visible in the deb version.
Also integration is still wonky. Qbittorrents flatpak can't detect the gtk theme (dark/light) I'm using, for example
@@SnowyRVulpix is it an upstream issue or a qbitorrent problem?
Kdenlive was the same for me, couldn't use the speech to text Whisper model with the Flatpak. It works with the AppImage though!
You have to give flatpaks access to your data drives, obs has been working perfectly for me with hardware accelerated video encoding including av1, and I haven't had a single problem with light/dark theming issue since I've been on gnome.
@@SnowyRVulpixYou need to specify the theme in flatseal, otherwise it will not work.
cool video.
i think that sandbox with permissions are better than normal packages in the sense that they have security switches like camera, files etc. but they are not a big deal because most apps wont work without most of permissions on, which inutilizes the security aspect, but its better than nothing. but, conteiners have the other good aspect that is it is easier to mantein for the developer and easier to install for the user. also you can install multiple versions of programs i believe.
the advantages of normal packages is that use less disk space and the dependencies are easier to be manteined and updated as you only have to do the work one time, contrary to the flatpak where if the library is in multiple packages every developer would have to update the library. although the normal package approach is not perfect as explained in the video.
the good thing is that with Nix like approach you can also have the benefit of having multiple package versions which increases the value of normal packaging.
so i think Nix like packaging is the future and is somewhat better than conteiners/flatpak, though flatpak is nice as alternative if not spend that much resources in that
Just goes to prove that every time a human being creates something, another human comes along and figures out how to turn it into either a weapon or a tool to gain advantage with or both.
Defenders of snaps ... ? Never heard of em ... 😏
I'm sure some of them exit somewhere!
very helpful; thank you for the video
Great video. Very enlightening.
Thanks Nick.
Flatpak permissions are underminded by portals afaik. For example file system permissions are circumvented that way.
Not true. Portals let sandboxed apps access content of the system but in a controlled manner. For example, say Firefox is a flatpak and has no access to your home folder. But you want to upload an image to a website. Through portals, Firefox can access just the image you to upload.
@@that_leaflet If a user takes away filesystem permissions of a flatpak knowingly, it should therefore not be able to get any files at all, shoud it? But what you are saying, if I understand correctly, that if I interact with the filesystem in such an app, that has FS permission, it would ask the host system to open a file browsing dialog, let the user chose the file or folder, which then gets passed into the flatpak app via a portal? And for that whole process the flatpak can not access anything in that dialog or the filesystem?
@@mayonaiseking Yes. The app doesn’t have access to the file until you give it permission to it (by selecting it into the file picker).
Portals were made so that permission can be dynamically given (with a permission system) rather than static locations listed in a flatpak’s manifest file.
@@that_leaflet Thanks for the insight. Should probably have looked further into this instead of splurting it out like that.
Great topic
To be fair
Users don't want safety. The point of those formats was to keep a compiled package working for at least 2 major releases with no need to rebuild
Imo the what Mint team said does not sound confusing to me at all. Who knows what an unverified app that a random joe put together might contain. so yes, of course, it is a security risk. We all accept that legit apps can have security flaws, nothing is completely secure, whether it be a flatpak or coming from your distro package manager. This was an L take tbh
Yeah, this is just people hating on Mint for the sake of hating on Mint.
"Why don't you ditch Ubuntu and go Debian?"
"Your distro looks so old and dated" bla bla.
With openSUSE for example to get full codec support you need to enable a 3rd party repo. In that case it probably makes more sense to install the flatpak version with integrated codecs. For not only "security" but also potential breakage since packman replaces a lot of openSuse provided stuff and it often lags behind a bit so you can get errors when updating.
And installing flatpak as user instead of system seems to be a good choice as well.
Those breakages can be prevented with Distrobox. It's much better to use Distrobox than Flatpak in some cases, e.g. Chromium-based browsers, as they have to circumvent Flatpak's sandbox with Zypak, in which doesn't comparable to Chromium's native sandbox, security-wise. Moreover, they all lack a proper support for PWA. Widevine support is also not possible without exposing filesystem=host-os, hence making Flatpak sandboxing with Chromium-based browsers not relevant.
Very informative, thank you. Still, I've been using Linux for 17 years now and have never had a virus or security-related problem, unlike my experience with Windows..
You mean not that you are aware of.
The issue with "verified" tag, it is his name. It verify the origine, which *we want* to have. But it doesn't verify the code itself, which we should know. It should have an other name !
There is also the issue of alternative version where their alternative origine has been verified.
Instead of "verified" or nothing. We should have "Original origine", "Alternative version", or "Unverified origine".
Tbh I don't think it's possible to make a package safer than what we have. At the end of the day you can always find a point in the development process where one can inject bad code, and if you paid attention, all the ways the current formats became unsafe nick mentions basically boil down to "the app dev is malicious/made a mistake" or "app is outdated in some way" which, how are you gonna stop it with the package at that point? If you download malware, it's still gonna be malware. The only way to make malware "safe" through packaging is to lock it in a private airtight room without an unlock option. At that point, that format is useless for packaging.
Linux formats and apps are safer bc you can audit them. You can independently verify if someone is trustworthy. That's how exploits are caught. Literally, the only reason xz was found is that someone compiled it on their own and noticed an anomaly.
As you say, we can audit our open source codes. What would be safer for Linux is to create a network to share what audit has been done on what (even on what version and what parts of software (we can do partial audit on most critical parts which is better than nothing and less than everything) ) to know how much safer each thing is, and what needs more to be audited (base on how much people use it vs his known audit and his criticality).
Also "verified" is a very misleading name for origine verification. Instead of "verified" or nothing. We should have "Original origine", "Alternative version", or "Unverified origine".
Really good content !
Currently a lot of good work is duplicated across all the different package formats/distros.
If something like Flatpak or Nix became more common, instead of 10 maintainers each having to package the same package for each of their distros, they could be working together or each have fewer packages to maintain. As a result perhaps there is more time for spotting security flaws or bugs, and the quality and thus the user experience would improve. The packaging process itself might become a bit more complicated when they're targeting a wider variety of distros, but I'm guessing it would still be a favourable trade-off.
A little out of the scope but what about Bottles ? I use Bottles to run Windows visual novel that aren't available on Steam. I don't change any of the default settings and it works great out of the box. Are these Windows executables only able to act in the folder and subfolders from which they are launched maybe ? I wonder what a designed for Windows malware would be able to do if executed through bottles. Unable to steal anything because it's not in the location it supposed to be or because it can only view what appears to be an empty Windows ?
TLDR; no matter what, you have to trust someone, and all of computing relies on the goodwill of random people, whether you like it or not
the snap store on ubuntu does let you graphically change snap permissions
The Debian's maintainer decision is based on security concerns, you made it sound unsecure (and problematic), which is hilarious.
You interpret what I said. I didn’t make it sound like it’s insecure, I said it took away user agency and went against developer’s wishes.
A maintainer DOES NOT decide for the users or the developers. If you don’t like how the app works, you stop packaging it.
The maintainer did something stupid, virtually everyone agrees, and it goes against Debian’s guidelines as well…
@@TheLinuxEXP >>went against developer’s wishes
The dev allows modifications, redistributions. Read the licence.
>>A maintainer DOES NOT decide for the users
You pick your favorite distro based on what the maintainer will decide, based on packaging policy of that project, if the decisions is somewhat unpleasing to you then, its fine, but clearly you're using a wrong distro;
>>If you don’t like how the app works, you stop packaging it.
This is a fake dicotomy. No, if it's FOSS you can modify it to work as you like and you're allowed to redistribute it.
>>The maintainer did something stupid, virtually everyone agrees, and it goes against Debian’s guidelines as well…
Your opinions, and i respect that.
To me, I don't want to be inconvenienced. All the package managers are great until you have to deal with them in the terminal because commands aren't universal but have to be individually referred, they have pros and cons but as a user, I shouldn't get stuck in between.
One of the biggest weakpoints of Snap and Flatpak is, that they are not packaged by my distributions maintainer and are coming straight from the developer. This is something I don't want. I want my distribution to repackage.
Redundancy of effort; there is native package for that.
Why? It just means more hands touch the pie, and like covered itsa not like the maintainers are doing security audits the vast amount of the time. Its placebo safety vs efficiency and a lessened workload for the developer.
Run the apps without full permissions istead. Containers, mandatory access control systems like SELinux and app armour etc.
@@BeefIngot Flatpaks are designed to run everywhere, therefore they are not optimized for my system. I want the middle man, as this is another step to pass.
Just because an application comes directly from its developers does not make it better than one from third party. Its like installing any software directly downloading from the website, like on Windows. I don't want that. I also do not expect my distributor to audit the code, but that's not the point.
Besides that there are other reasons, like not being able to do everything with one package manager (listings and what not). The file paths are different, its run different and other things. And often trying to figure out why the Flatpak does not work, if I ever figure out it is the Flatpak that is causing the issues, then its wasting my time even more. Flatpak has its place and I even use it, but not because its my first choice.
I do not want to use any operating system that relies on Flatpak or Snaps. My OS should have native packages as first class.
6:38 distro do however have a security team that does audit the code, debian has one, ubuntu has one, pretty sure fedora has one too
Granted this is also true for flatpak and the snap store (tho still unrelated to unverified/verified)
Snaps have access to permission selection in the Software Store app (sometimes)
flatseal can manage flatpak persmissions, graphically yes.
Thanks for video!
F.. all this, that is why I prefer ports and portage.
Time to run everything as a web app and watch our web traffic 😅
Defender of snap. . Wait, who defend snap? 😂
Richard Stallman was right
I use LMDE just as a way to install Debian+flatpaks easily, I've since removed cinnamon & replaced it with Trinity
The rust ecosystem has gone with a redeploy everything "for each application" design, there is shared code but each binary has copies of all it's dependencies internally.
Didn't debian, arch and rpm packages have a integrity checker and if it's not valid they don't install.
I don't think apps run by root by default. Never had I run vlc in admin mode in windows and Linux for more than 15 yrs
I was surprised to learn that to be a maintainer at Debian means to know licensing inside and out, but knowing programming is not needed.
Oh i thought distro packages are safe. Nice explanation 😅
Windows : Here is the .exe in zip archive. (What do you want auto-updates for ?)
Linux : Here are the 7 ways you can install different versions of this app, for your kind of distro. (If none of them work, you can always compile it from source.)
Or, here's a self-extracting exe
Windows packages is trash. In Linux you should only need your distro package manager and just it.
thanks
12:12 "this (kernel) version becomes more and more buggy" - To me this wording seems a bit misleading, because it makes it sound like somehow bugs are being *added* to an old version (which kinda doesn't work because changing something would basically make it a new version). A not-so tech-savvy person could entertain the notion that software versions somehow "decay" with age, like hardware (or like humans :-D ). What actually happens is that more and more bugs are getting *discovered* - and thus made public - over time, which is why their list becomes longer, and the potential attack surface - publicly! - increases over time (in some cases though, the publishing of a bug will actually contribute to improving the software's security, provided that bug is fixed swiftly, because before the time of publishing, attackers who knew about the bug, were able to exploit it in secret). It may sound like a nitpick, but I know for a fact that to whoever doesn't undersand software development cycles and security, most statements about security are unintelligible, and they have the weirdest notions about what is "secure" and so on.
Thoughts on app images?
10:00-10:30 this also applies to snaps
Hey nick, could you do a video about parental control on linux?
Does it even exist?
There is no controversy on packaging system.
There are the old linux users, veterans, with a lifetime of knowledge, who keep using what they have used, trusting on old and solid official projects and maintainers like they always did.
And there are the newcomers born from the linux hype in recent years, who know pretty few about anything related to linux, but watch a lot of influencers and blindly repeat what they say to pretend they know more than they actually do.
This apparent controversy, which is nothing more than kids noise, also occurs in other subjects such as window managers, text editors, distributions, etc...
Exactly... there is nothing wrong with distro packages (sure it's not 100% but nothing is), distro packages worked for 30+ years, still working. I hope they never change.
This is what happens when Linux gets popular and more users...
Traditional distro-based packaging is still the best for you as the user. It requires more work for the developer, but the user benefits most from this packaging format by having a much leaner system that uses less storage and memory resources. In my opinion, there's really no debate here, distro packages are the best for you the user.
I only resort to flatpaks if I have no other choice.
Good video.
@2:05 the demonisation of community packagers and maintainers (the volunteers who build and maintain all the DEBs, RPMs, etc) is a sad development in Linux. They're not just "randoms" you can't trust. They're very experienced, knowledgeable, and they have an impeccable record. Debian is over 30 years old and all in that time there hasn't been a single instance of a community maintainer deliberately inserting malware into a Debian package. Where malware has been discovered, like the recent xz-utils backdoor, it has always come from upstream. I just don't understand the attitude or where it comes from.
Agreed... I am starting to think it's all deliberate. The old neckbeard guys who have been thanklessly doing the hard work for 30+ years are now slowly being pushed out by political activists so they can take over. (Many similar things happening elsewhere too like NixOS)
I hope Debian NEVER CHANGES until the end of the universe.
Is it normal that linux mint flatpack and ubuntu updates come in daily?
The picture is not as bleak as this, because "Linux" strides both the FOSS and the commercial sectors. So say you are part of the coders/development team at Red Hat Enterprise Linux for example. Your company wants to sell secure servers and workstations. So you will grab some open source code, and test it out in all sorts of ways. Is it functional, is it secure, is it efficient, and so on? Of course, a full commercial version of Linux won't release the propriety bits of the code to the public. But I don't believe that they "re-invent the whole wheel". What would be the point? People can put back-doors and malicious code into programs for a hundred different reasons. You are never going to prevent that 100%.
So let's consider a totally closed code. All you have are the compiled binaries. You can't still do behavioral forensics on what is essentially a black-box. Is the app sending excessive telemetry, and to where?
Now imagine that most of the code is based on open source. You not only have the forensics as before, but most of the source code as well. So if you suspect malicious programming, that narrows down your search.
For example CentOS behaves pretty much the same as RHEL. The main difference is that you can get support from Red Hat if RHEL breaks, and if CentOS breaks, you have to make your own arrangements.
Not selling Red hat, or criticizing it. It is just an example.
At the end of the day, total objectivity is hard, if not impossible. All we have, all we can have is inter-subjectivity. I will use a religious example. Suppose a devout Catholic has a vision of the "Virgin Mary". No surprise perhaps, but was it true? Unless you can read the person's brain, you will never find out for sure. But suppose an atheist, a Buddhist, a Jewish person, etc, all claim to see the same vision? You still have not got to absolute proof or disproof, but you DO have something interesting.
That is why there is such consensus over stuff like gravity. Nationality, religion, ethnic background, age, gender, etc, etc, it is all a common experience. Gravity could be a "shared delusion" of course, but we do have to take it as "working knowledge", because we don't have any other option.
Hard Solipsism [we could all be living in a matrix] is simply absurd, because even if we knew the absolute "truth", it would not change anything.
So if I create a random repo as a reupload (not a fork) and the use that to autenticate with flatpak (or another store), and then package someone else's app, will that show up as verified?
Apparmor profiles for snaps are generated on the fly at snap install time and re-generated during snap updates from the interface definitions of snapd. Editing them on disk is a rather pointless action.
Microsoft Edge: Unverified.
Maintained by a known creator of spyware
God bless you, praying for you
Nick are you even a real Frenchman? I ask because, shouldn't you be at the roadside shouting your lungs out and waving . . . at the Tour De France? 🤔🤨
No real Frenchman would ever watch this thing 😅
@@TheLinuxEXP Hahahahhahaaa. I watch it. I'm not French . . Allez! Vingegaard, Allez!
More Packages (OPEN SOURCE) better..
Flatpak is king
sooooooo...... windows?
Windows has the same issues with their packages and installers :)
I wish AppImage was mlre hewvily invested in for Linux. It makes entry level for new Linux users easier. No looking up how to sudo dpkg -i FileName and what each part means for safety.
Honestly wish I understood making AppImages to create ones most new users would want en mass. Ah well, even if I did the originals would probably find some reason to complain.
What is the difference between app image and regular elf binaries?
To be fair it is a mess because you cannot bundle every library you use, most of them can be bundled but the ones interfacing with the host system like x11/wayland library should not be bundled.... making them complicated to make, so the responsibility of the appimage working is fully on the appimage developer.
I use EndeavourOS with arch repo, aur and flatpak. I don't care if it safe or not. I just use what i want. So people have strange paranoia that EVERYONE/EVERYTHING want to hack your pc with everything.
I'm on the same distro and I trust the AUR
@@AresydatchThe only packages you should NOT trust in the aur, are random packages with like, 1 upvote and 0.00 popularity. Other than that, aur is safe.
I used to be very careful too. Nowadays, I just use Windows to save a lot of headaches. Of course, I still maintain Linux servers, hence why I'm watching a Linux channel.