Always prefer Free & Open-source (FOSS) software instead of proprietary.
Limit the amount of unofficial packages used to simplify maintenance.
Make periodic checks on which are in actual use, and remove or replace with their official counterparts.
Use precaution when using packages from the AUR or an unofficial user repository.
Most are supplied by regular users and thus may not have the same standards as those in the official repositories, therefore must be checked by you.
STABILITY
To improve stability and simplify maintenance:
Avoid cutting edge software and install only mature and proven software.
Such packages are less likely to receive difficult upgrades such as major configuration changes or feature removals. Prefer software that has a strong and active development community, in order to simplify support in the event of a problem.
Avoid any use of the testing repository, even individual packages from testing.
These packages are experimental and not suitable for a stable system.
Avoid packages which are built directly from upstream development sources.
These are usually found in the AUR, with names including things like: dev, devel, svn, cvs, git, etc.
SOFTWARE
Listed by safety and stability.
Use only 1st, as the most trusted, and fallback to other sources only if you actually need it.
Arch
Official repositories using pacman
Search
pacman -Ss PACKAGE_NAME
Information
pacman -Si PACKAGE_NAME
Install
sudo pacman -S PACKAGE_NAME
Arch User Repository using AUR
Search
yay -Ssa PACKAGE_NAME
Information
yay -Sia PACKAGE_NAME
Install
yay -a PACKAGE_NAME
Compile from Source code or create your own package using PKGBUILD.
It’s best to create your own package, when you install program system-wide, even when you don’t intend to share it in the AUR, because pacman does a much better job than you at keeping track of files.
If you install things manually you will, sooner or later, forget what you did, forget where you installed to, install conflicting software, install to the wrong locations, etc.
Of course you can do whatever you want, but generally i’d say AUR is better choice for better organization, because basically what it is - a process of creating a normal Arch package from source, Flatpak could be somewhere between around 3-4.
More on AUR
AUR
The Arch User Repository (AUR) is a collection of user-submitted package description files (PKGBUILD files).
These description files can be used to create package archive files (.pkg.tar.zst files).
These PKGBUILD files can be used by an AUR helper (for example yay, paru) or manually built using makepkg.
The AUR is one of the safest ways to install software, because it is so transparent.
But it does not tolerate just looking up the package in Pamac and clicking Build button, or doing yay PACKAGE_NAME blindly. It requires that user knows what’s going on.
That’s why it is recommended to try building at least one package manually, to understand what’s going on.
yay has a nice feature that allows you to inspect a PKGBUILD file before installing, and to see the differences in the PKGBUILD file when updating a package from the AUR.
How to use AUR safely
Find package on aur.archlinux.org or yay -Si PACKAGE_NAME and check:
Votes
Popularity
Comments (review most recent ones for red flags)
Maintainer
Last packager
If it’s established, popular package maintained by someone who maintains a lot of other packages - chances are it’s fairly safe, usually if something fishy going on it will be removed from AUR fairly quickly.
Otherwise be extra careful while checking PKGBUILD and / or source code!
Check update frequency of the package, if it’s not some simple script or suckless software - probably better to find alternative if it’s very outdated or rarely have updates.
How to inspect the PKGBUILD file?
Typically, good PKGBUILDs contain very simple instructions.
Make sure all links are valid, and point to the official and trusted site of the software!
All URLs, as well as local files expected by script, should be listed neatly in the beginning of the file in source=.
Look for any downloads of external scripts, with curl or wget, there should not be anything like that.
If there are local files or scripts listed in source=m check them for anything malicious.
If the checksum variable (sha256sums=, md5sums=) contains word SKIP (usually that’s the case for *-git packages) - then the related source links should be checked more carefully, as they are not automatically verified.
Check depends=, especially if they are from AUR, generally that’s very bad idea long-term.
Typically, building and installing packages should not touch anything in home directory (~, $HOME).
If you find something like that, be very suspicious and make sure you completely understand what that command does.
Look for anything that looks intentionally obfuscated:
anything that is written in an unclear way
many ;, && and ||
lots of brackets
sed, awk
Update AUR package
Usually it’s only once you have to do a full review of PKGBUILD and / or source code.
On update just use diff to review only changes, mostly they’re pretty small.
AUR package stopped working after system update
AUR packages are targeted at Arch stable.
When software library versions change their features and way they work can also change. These changes are normally backwards-compatible, but not always, and almost never are they forward-compatible.
This means a package built with a new library version will rarely work with an older library version (not forward-compatible), and it’s also the reason why “partial upgrades” can break things.
Solutions
Update your system.
Rebuild AUR package.
If that fails - report to AUR package maintainer via comment on AUR package page.
If this fails or it’s upstream AUR program bug - report to their issue tracker.
That being said, Electron is such a crap that probably isolating it as portable system-agnostic Flatpak or appimage is not bad idea As long as you don’t forget to update it routinely, coz Electron is…well you know, something that needs to be fixed for security and bugs routinely.
flatpaks are not safer than AUR packages as a general rule.
A flatpak is a framework and packaging format. Anyone can make a flatpak. flatpaks can have malicious code just like any other package. This is true of just about any packaging format you can think of.
You shouldn’t trust a packaging format. You should trust a packaging source/packager. In other words, Arch/EOS repo packages aren’t trustworthy because they use pacman’s package format. They are trustworthy because they are packaged by Arch TUs or the EndeavourOS team.
As this relates to flatpaks, you need to look at who is packaging them. Some flatpaks are officially packaged by the team/publisher of the software. Those should be considered pretty safe. However, many are not. Then it comes down to do you trust the packager.
The sandboxing provided by flatpaks is questionable at times, depending on the application and how you want to interact with it, it may be mostly useless.
The AUR has a huge advantage when it comes to trust. That is you don’t really need to trust anyone. AUR software isn’t packaged by a 3rd party. The packages are built on your machine. The AUR PKGBUILD files which are used as the “directions” to build the software are easy to view for yourself. Many AUR helpers even offer to display them to you as part of the update process.
Of course, whether you choose to prefer flatpaks over AUR packages is entirely a matter of personal preference. The great thing is that, here, you have the ability to choose for yourself.
Should also ask about where Snaps fare in this discussion.
The only two programs I have ever acquired from the AUR were Brave browser and Pokete game, both on Manjaro. The latter had to be build and pulled in too many dependencies in my opinion for a flimsy text-mode-only game. I was unwilling to install it as Flatpak.
In my experience Flatpak could install as many as two different versions of GNOME platform, and it would get more interesting after v44 comes out, if those apps are ever updated. I’m often not very eager necause only one “package” of GNOME platform could take as much as two-thirds of a GiB. As much as I liked the Cowsay I had to forget about it and program my own version LOL to show off to some online friends because it was cheaper in memory and it was at my short hobbyist programming reach.
Avoid the distros which put a heavy emphasis on Flatpak or any other packaging system which is not “native” like the Arch repos on Arch Linux. There seems to be an increase of distros offering only GNOME or KDE Plasma locking users into Flatpak. Tried one of them already which left a sour feeling. (Not RebornOS and I’m left with the desire to see what that “FIRE” was like!) It’s also causing me to avoid testing elementary OS although I sympathize with the story of the devs breaking up but not their begging for money for half-effort.
I would go even further, and make a claim that snapd is malware. I’ve already written about that on this forum:
There is a reason why snapd is not in Arch Linux repos, even though it is very popular on the AUR. However, the best treatment of the subject is by Linux Mint.
what exactly is understood by “checking a package”? How exactly do I verify that a package is… safe? (I guess safety is what we’re checking for)
is there even a way for me to do that if I am a very “non-tech” casual user?
the only thing I can think of so far is reading comments / feedback from other users on a specific package…
the reason for these questions is probably my lack of knowledge, and I do admit that I could and probably should learn a lot of things myself, but some of the questions that I’ve been having (like the ones I’m asking here) genuinely feel like I won’t be able to just “type it in the searchbar” and find an answer…
I have a similar question here… how exactly can one check that software is mature and proven? o:
isn’t it “yay -S” for installing?.. I always use that and it works…
One way for AUR packages is to look at the build file. This requires some technical know-how still. You can see a list of build depenancies or run dependancies, but not knowing what those mean or what they do won’t help you make an informed decision still.
One way is if it’s a Flatpak, Snap, or AppImage, is it packaged/distributed by the software vendor? For example, the Microsoft Teams flatpak app in Unofficial, Microsoft releases a .deb and .rpm package for this.
It’s somewhat safe to assume if it’s in the distributions official repositories, it’s at minimum been vetted and tested and could be considered safe. Make sure you trust who is providing the distro though.
There is a place in my post where you can click to open more info:
More on AUR
I can’t be more specific than that
Research. Check how long it was around, read some comments and issues about given software, if it’s something fresh - at best try to understand quality of code yourself.
You don’t have to use -S with yay, it’s not necessary.
What -a does however is telling it to use only AUR for next operation.
yay -a - update all AUR packages yay -a package_name - install package from AUR
That’s a great example!
If you see that something has vendor Microsoft - avoid at all cost, it is definitely a spyware.
I would say that Flatpak vs AUR depends on what youre installing and the number of dependencies that end up coming from the AUR also.
Generally you want to treat anything not from the Arch Repos as foreign and a threat (possibly any package really). AUR and Flatpak allow you to check how things are built through either the flathubs git or through AUR pkgbuilds.
You can build flatpaks yourself (its actually pretty easy) but the ones on flathub are built from by flathub automatically from the build files similar to pkgbuilds, maintainers cant upload binary files directly for obvious reasons. AUR you build it all locally but you need to know what youre looking at to know if something is malicious in either case and need to make sure of the what and where of sources.
Ultimately it comes down to which source you trust more for a given package, some flatpaks are maintained by the original authors and very trustworthy, others arent. This also goes for AUR.
Keep in mind the flatpaks arent built by the maintainers themselves. They upload a manifest which is used by the flathub build system to actually do the build/packaging
You can also use these to build the flatpaks locally for your own repo if you wish to.
This is how flathub/flatpaks work, this process does beg the question of what kind of review process happens AFTER the initial approval and a package is added?
Fork the Flathub repository on GitHub with “Copy the master branch only” unchecked.
Clone the fork: git clone --branch=new-pr git@github.com:your_github_username/flathub.git
3. Create a new branch with your app’s name: git checkout -b your_app_name
4. Add your app’s manifest to the branch, commit it and push the commit
5. Open a pull request against the new-pr branch on Github
6. Your pull request will then be reviewed by the Flathub admins
Once your pull request has been approved, a new repository will be created for your application, containing your app’s Flatpak manifest. You will have write access for the repository. The Flathub service then uses the manifest from your repository to continuously build and distribute your application on every commit.