Comparison of package safety
There's no such thing as absolutely safe or absolutely unsafe. It's all relative. But relatively speaking, distribution packages are generally safer for multiple reasons. That shouldn't prevent you from installing non-distribution packages when you need them. But if a program is available both as a distribution package and from another channel, you should use the distribution package if possible.
By “distribution package”, I refer to packages distributed directly by major distributions such as Debian, Ubuntu, Red Hat, SuSE, Arch, FreeBSD, etc. Distributions with less manpower may have less relative safety. Packages downloaded manually in the distribution format (e.g. a .deb or .rpm) do not have the safety advantages of distribution packages. Packages installed from additional package sources (e.g. Ubuntu PPA) are in between.
Transparence
Distribution packages are signed and replicated, and the installer verifies the signature. So you know what you're getting. If a bug is discovered in a given version, you'll at least be able to know whether you had the buggy version.
In contrast, when you install something with curl https://example.com/run_me.sh | bash, you have no way to know what you installed. A malicious web server can return a clean installer if you download the .sh, but a backdoored installer if you run curl … | bash, by detecting the timing of pauses in the execution of the installer script. This even distinguishes curl -o install.sh … from curl … | bash.
Third-party package sources are in between: they're only signed by their vendor, but some (such as Ubuntu PPA) are hosted by distributions, which at least prevents undetected substitutions.
Scrutiny
Software shipped by distributions get some scrutiny. It's not a lot, and absolutely not something that can prevent bugs or backdoors. But it's enough to make it harder to ship a backdoor that goes undetected for a long time. And it means that the software is trusted by at least one person who is trusted by a distribution.
Getting the software directly from the vendor removes one layer of scrutiny, whether you get it from a package source or a website download.
Security updates availability
Distributions have people who make security updates when a vulnerability is discovered. That includes porting security fixes to the distributed version of the package. Except with rolling distributions, in a given version of the distribution, you only get major bug fixes, so you can be reasonably confident that the fixed version won't have new features that interfere with your workflow.
Some vendors follow the same principles. Others don't.
Security updates automaticity
For any software that comes through your package manager, a single command (e.g. apt update && apt upgrade) applies all the security updates. Some distributions or desktop environments set up automatic tasks to apply security updates, or to prompt you to apply security updates.
For software that comes through other channels, you have to remember to go and look for updates. So you might have vulnerable software for a long time before you notice.
Package automation
Most packaging systems keep track of which package owns which files. They signal an error if a package tries to overwrite a file from another package. They remove all the files of a package when you uninstall it. This applies to anything that uses the packaging system, regardless of who made the package.
You do not get these benefits from manually installed software.
Package quality
Distributions have minimum package quality requirements. For example, they follow directory structure conventions. They won't disrupt your system or your user account in arbitrary ways. They clean after themselves when you uninstall them.
Third-party software, whether it comes as a package or not, may or may not reach this quality.
Integration quality
Distributions don't do much testing of most of the software that they ship. But at least they make sure that all dependencies are satisfied — you won't end up with software B requiring A version 1.3, software C requiring A version 1.4, and no way to install both versions of A. In particular, a given version of a distribution compiles all the programs against a given set of library versions. Distributions solve DLL hell for you.
If you install software that isn't from the distribution, you're on your own. The vendor may or may not have tested with a system that's similar to yours. Two different vendors may have completely different expectations of a typical system.
That's why a lot of vendors now ship “appliances”: instead of just shipping an application, they ship the application and all the libraries it depends on. Sometimes they go as far as putting the application in a container: flatpak, Docker image, virtual machine… That solves the dependency problem, but it also means that the libraries in the container don't get bug fixes (and in particular security fixes) unless the vendor applied the fixes to their own copy of the library. In practice, that never happens, so we get back to the security update availabiltiy problem I mentioned above.
About language ecosystems
If you're a developer, in many programming languages, language-specific distribution channels (pip, npm, rustup, hackage, opam, …) are hard to avoid.
Unfortunately, the state of packaging is pretty bad. The one good thing is that they handle versioned dependencies. These package managers barely keep track of which files belong to who. They may or may not be able to clean everything up when uninstalling.
These ecosystems usually give up on DLL hell and just tell you to install separate copies of everything in each of your build trees, or at least one per (version of a) project. But if your project needs libraries A and B, which both need library C but at different versions… sucks to be you.
So you should avoid language ecosystem packaging if you can, but often, you can't. You need to spend some effort in reviewing and maintaining your supply chain.
