Every newcomer (me included) after painstakingly (at least in the early days) installed the Linux operating system, had only one question in mind: OK, now what?!
Well now, it is time to install some apps!
For this blog I will be using the Pop!_Os which is a free and open source operating system based on Ubuntu (which itself is a variant of Debian).
In newer versions of Linux distros, there are a lot of GUI tools for installing new applications. For example the Pop!_Os uses a so-called Pop!_Shop and Ubuntu uses Ubuntu Software Center, from which you can install applications with a single click, LITERALLY! Those GUI tools use the distribution’s repositories so anything you install from there should be safe. If we need some app that is not included there what do we do? Well, the first thing we would think is, to do a little search using the apt tool. And that is also safe, for now. But what if our beloved app is not included in the preconfigured repositories? Then the only option left is to install it from external sources. Because time is passing by and impatience starts to nest, we can get tempted to copy-paste the first piped command which appears on google search. Well, that is where the trouble starts.
Try to understand commands you find online before executing them
In blogs and forums sometimes people can mistype a command (I do this often :)). Sometimes the command can work well on some distributions and not on others or it can be devastating. If you are not sure about a certain command you can always check the manual for the command or just read the distribution wiki page.
$ man tee
example of manual for the tee command
A curious case is when websites tell us to “pipe” wget or curl into bash in order to install their app. Sometimes they even tell us to ignore certificates as well.
$ wget -O – http://example.com/install.sh | sudo sh
example of “piping” wget into bash without using https
Imagine that the .sh file we are “piping” has a line in it similar to this one:
rm -rf /$TMP_DIR
What would happen if the connection closes midstream and all left from the script we are downloading is this:
rm -rf /
If that script gets executed, and it will because it is a perfectly legal script, it’s going to hurt badly. That is why some maintainers started wrapping code snippets into shell functions:
docleanup() {
rm -rf /$TMP_DIR
}
docleanup
A script like this, if it is missing some part, will result in an error when executed. The latest versions of Linux should have a safeguard against rm -rf / but either way, check the script before executing or don’t “pipe” into bash.
Install apps from sources you trust
If you need some famous apps like IntelliJ or slack, go to their website and you will find all the information on how to install them. Lately, it is not unusual for software maintainers to provide a .deb file. When there is no other option and if you trust the source go for it, otherwise prefer to install the apps the old fashion way by downloading a .tar.gz file which you can extract wherever you want and later it will be easier to remove completely.
Another thing Linux users usually do is install extensions. I on the other hand like the original look and feel of most Linux distributions so I rarely visit those kinds of websites. By installing extensions from unofficial sources, you can become a victim of the second biggest virus to hit 2019 Linux users specifically running gnome-desktop environments, called the “Evil GNOME”. Rightly dubbed because it runs as an extension in (you guessed it) the gnome-desktop environment. And yes, the Linux world is not virus-free, because every software made by man can be broken by man. This virus can monitor your audio, keep track of newly created files, and even has a key-logger. If you need gnome extensions you at least should visit the official website for this.
If you use browser extensions check if they are on the browser recommended list, or are located in the GitHub repository, in which case you can check them out yourself. Some browser extensions can keep track of your browsing history and even the things you type if they have the required rights. The bottom point is to install extensions from the official and trusted websites or don’t install them at all.
Don’t use apt-key anymore
Some websites offer us their GPG key and repository in order to install and update their software, which will look something like:
$ wget -qO – https://<example.com>/<repo-key-pub>.gpg | sudo apt-key add –
$ echo “deb https://<example.com>/ <apt/stable/>” | sudo tee /etc/apt/sources.list.d/<my-repository>.list
$ sudo apt-get update
$ sudo apt-get install <my-package>
<repo-key-pub> will be replaced with their public key
<example.com> will be replaced with their website or download path
<apt/stable/> will be replaced with their repository path
<my-repository> will be replaced with their repository name
<my-package> will be replaced with their package name, can be similar to the repository name
But when we try to execute this command on newer Debian-based distributions we will likely see the following output: “Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8))”. This message doesn’t mean that the developer decided he has better things to do and closed the project, but it has something to do with security.
The reason for this change is that when adding an OpenPGP key to /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d, the key is trusted by apt. But that is not all! That key is trusted by apt for all other repositories configured on the system that doesn’t have a signed-by option (we will see later in this blog), even the official Debian / Ubuntu repositories. As a result, any unofficial apt repository, which has its key in one of those 2 locations we mentioned, can replace any package on the system. Well, that is hardly likely that a source you trust will do that, but even they can get hacked. It’s also important to know, while the apt deprecation message says to “manage keyring files in trusted.gpg.d instead“, the Debian wiki states otherwise. That is because adding keys to /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d is equally insecure as we mentioned above.
Only 2 steps are required for the correct (secure) procedure:
STEP 1: Download the key into /usr/share/keyrings directory.
$ wget -O- https://<example.com>/<repo-key-pub>.gpg | gpg –dearmor | sudo tee /usr/share/keyrings/<myrepository>-archive-keyring.gpg
gpg –dearmor is piped if the file is ASCII armored (encoded)
you would probably need to replace all text within <>
note that the key extension can be .gpg, .asc, .key, and probably others
There is nothing special to this location, it is just a directory. Convention states that directory /usr is for all the programs and support files used by regular users, /usr/share contains shared data among programs, and /usr/share/keyrings is just a descriptive name.
STEP 2: add the repository sources.list entry. Previously, a sources.list file from the /etc/apt/sources.list.d directory would look like this (just a simple file with the following content, nothing special):
deb https://repository.example.com/debian/ stable main
However, to be able to use the key added under step 1, the sources.list entry must now look like this (/etc/apt/sources.list.d/<myrepository.list>):
deb [signed-by=/usr/share/keyrings/<myrepository>-archive-keyring.gpg] <https://repository.example.com/debian/ stable main>
As you can see there is an additional signed-by option (as we mentioned somewhere above) which points to the exact location of the key. And we are almost done.
After this step you can update the package list and install your app:
$ sudo apt update & sudo apt install <my-package> -y
