I obtain Linux ISO's by purchasing "live" DVD's and using various burner-programs to generate ISO's from the DVD's. Before using any ISO, calculate its checksum and compare it to the corresponding reference value on the official website, or on Distrowatch. It is a very bad idea to use an ISO which has not been validated in this manner, because some of them contain dirty tricks which can lead to loss of valuable data.
All of the Linux DVD's which I've obtained from Ebay seller ZC Trading, including Kubuntu 20.04 and Ubuntu Mate 20.04 (which were the latest at the time, except for the daily releases, which I don't trust), have arrived quickly in good condition, and have produced ISO's with good check-sums. If he doesn't advertise what you want, contact him.
To calculate a checksum, I recommend placing the ISO of interest on an hdd or ssd on a PC with some power. Then right-click in the directory where the ISO is located, and on the menu which appears, select the option to open a terminal in that directory, and enter "sha256sum <filename.iso>," without the quote marks and with the ISO's actual filename. To get the actual filename, right-click on it and select Rename, then press Ctrl-a, then Ctrl-c. Then paste the filename into the command by pressing Ctrl-Shift-v and hit Enter. I haven't timed it, but it seems to take about half a minute on my PC to perform the calculation. If you want to copy the result, highlight it and press Ctrl-Shift-c, but if the checksums aren't identical, the differences won't be subtle.
Wednesday, June 10, 2020
Saturday, February 22, 2020
How to retain downloaded packages in /var/cache/apt/archives after installing them
2/25/20
Debian/Ubuntu software is modular, and when you tell the software manager to install a piece of software, it refers to the installation's internal software index known as the local package index [1] to determine which modules/packages are required, then downloads them from a secure site, screens them for corruption by comparing them to reference data in the local package index, and places them in /var/cache/apt/archives before the actual installation process begins.
Normally, the downloaded packages are automatically deleted after installation. However, some people might want to retain the downloaded packages after installing them, such as to save copies to use in case they have to re-create the installation in the near future, such as to create a new installation to replace a botched one. Packages can become outdated quickly, and new versions might be required if you wait too long to re-create the installation, because every time a new installation is created, a new local package index must be installed if you want to install any additional software, and the new index would specify the latest versions for everything.
According to Disable auto clean in apt (https://unix.stackexchange.com/questions/499035/disable-auto-clean-in-apt ), the downloaded packages can be retained by entering the following command:
"echo 'Binary::apt::APT::Keep-Downloaded-Packages "1";' | sudo tee /etc/apt/apt.conf.d/10apt-keep-downloads" (Copy the command without the end-quotes and paste it into the terminal with Ctrl-Shift-V. In case there have been any revisions, get the command directly from the source.)
This command (not necessarily in the following order) creates a text-file named 10apt-keep-downloads, inserts the line "Binary::apt::APT::Keep-Downloaded-Packages "1";" in it, and places the file in the /etc/apt/apt.conf.d/ directory, which contains Apt configuration files, which are executed in alphanumeric order. In the past, they were lumped into a single configuration file, but it became too unwieldy.
I took a different approach, by opening the installation's text-editor with superuser privileges (by entering "sudo <text-editor name>" and then the password) and added the aforementioned line to the /etc/apt/apt.conf.d/20archive file because it pertains to the archives directory. This caused the packages to be retained, but it apparently also caused some problems. So, to be on the safe side, and for convenience, I recommend using the aforementioned command.
Notes
[1] The local package index, which is an extracted version of user-selected sections of the online package index (which is revised daily) is massive and contained in var/lib/apt/lists (the package index is also known as "package lists" when extracted). The reference data for a particular package can be found by entering "apt-cache show <package name>" (assuming that the local package index includes the section which pertains to the package of interest). For an introduction to the package index from a PC-user's perspective, see the package-index sections in my article on Apt-offline, because although it's not difficult to understand, it has to be explained in a precise manner when explaining it in writing, and I don't want to repeat it here.
Debian/Ubuntu software is modular, and when you tell the software manager to install a piece of software, it refers to the installation's internal software index known as the local package index [1] to determine which modules/packages are required, then downloads them from a secure site, screens them for corruption by comparing them to reference data in the local package index, and places them in /var/cache/apt/archives before the actual installation process begins.
Normally, the downloaded packages are automatically deleted after installation. However, some people might want to retain the downloaded packages after installing them, such as to save copies to use in case they have to re-create the installation in the near future, such as to create a new installation to replace a botched one. Packages can become outdated quickly, and new versions might be required if you wait too long to re-create the installation, because every time a new installation is created, a new local package index must be installed if you want to install any additional software, and the new index would specify the latest versions for everything.
According to Disable auto clean in apt (https://unix.stackexchange.com/questions/499035/disable-auto-clean-in-apt ), the downloaded packages can be retained by entering the following command:
"echo 'Binary::apt::APT::Keep-Downloaded-Packages "1";' | sudo tee /etc/apt/apt.conf.d/10apt-keep-downloads" (Copy the command without the end-quotes and paste it into the terminal with Ctrl-Shift-V. In case there have been any revisions, get the command directly from the source.)
This command (not necessarily in the following order) creates a text-file named 10apt-keep-downloads, inserts the line "Binary::apt::APT::Keep-Downloaded-Packages "1";" in it, and places the file in the /etc/apt/apt.conf.d/ directory, which contains Apt configuration files, which are executed in alphanumeric order. In the past, they were lumped into a single configuration file, but it became too unwieldy.
I took a different approach, by opening the installation's text-editor with superuser privileges (by entering "sudo <text-editor name>" and then the password) and added the aforementioned line to the /etc/apt/apt.conf.d/20archive file because it pertains to the archives directory. This caused the packages to be retained, but it apparently also caused some problems. So, to be on the safe side, and for convenience, I recommend using the aforementioned command.
Notes
[1] The local package index, which is an extracted version of user-selected sections of the online package index (which is revised daily) is massive and contained in var/lib/apt/lists (the package index is also known as "package lists" when extracted). The reference data for a particular package can be found by entering "apt-cache show <package name>" (assuming that the local package index includes the section which pertains to the package of interest). For an introduction to the package index from a PC-user's perspective, see the package-index sections in my article on Apt-offline, because although it's not difficult to understand, it has to be explained in a precise manner when explaining it in writing, and I don't want to repeat it here.
Friday, February 21, 2020
The most important reason for checking the integrity of ISO's before using them
revised 3/3/20
Probably the most important reason for checking the integrity of a Linux ISO before using it is to be certain that the encryption software contained in it is the official version, and not some hacker's version with a backdoor. To do this, check the integrity of the ISO, which is done by finding the reference sha256 checksum on a trustworthy site (either the official site or Distrowatch, which lists the checksums for all of a distribution's "point" releases, such as Ubuntu 18.04.3, and not just the latest one).
Then, you would calculate the sha256 checksum for your ISO-copy (which you might have downloaded, or made from a DVD, which various Linux and Windows DVD-burner programs can do). The command for calculating an ISO's checksum is "sha256sum <path>/filename.iso." To get the ISO's path, right-click on it and select Properties in the menu which appears, and a window which contains various information, including the path and file's name, will appear. To copy it, either highlight it and hit Ctrl-C, or right-click on it and select "copy" in the menu which appears. To paste something into the terminal, use Ctrl-Shift-V.
If the checksums agree, you at least know that your ISO is the official version, although this still isn't an absolute guarantee that there aren't any backdoors into the encrypted partitions which you create with it. The only way to be certain would be to analyze the code, which is out of the question for most people. You might assume that there couldn't be a backdoor due to the threat of some whiz-kid programmer analyzing the source code and blowing the whistle if he or she finds something, but that's just wishful thinking. So, using encryption software is ultimately a gamble that it's not a means of luring us into a false sense of security so that Big Brother can snatch our encrypted drives and access our secrets, which he would have to do in order to access the data if you normally open them only on an air-gap system.
To be on the safe side, I use the slow-format method to format new flash drives, which erases everything on the drive before formatting it, to ensure that there's nothing on them which could compromise security. (The drive's firmware, which is a sort of "BIOS" for the drive, might contain viruses, such as Stuxnet, but no such viruses have supposedly actually been deployed in the wild, and I haven't seen any indications that they can create backdoors into LUKS partitions, although to be on the safe side, open them only on an air-gap system to ensure that the data when in unencrypted form can't be sent out over the internet by some virus.) By the way, the latest version of the Disks program (a.k.a. gnome-disk-utility) as of this writing has apparently undergone a major revision, and it can create LUKS partitions in free space, instead of having to create FAT partitions and then reformatting them as LUKS partitions. Keep track of which installation was used for creating each encrypted partition, pay attention to news of any vulnerabilities which might compromise the security of your data, and reformat any affected drives. Use long passwords which are easy to remember but impossible to guess, with upper and lower case letters, numbers, and symbols. Store a copy in a safe place (besides on the encrypted flash drive, such as in a list of all passwords you have ever used, in case you ever have a need for an old password which you've forgotten). When you are certain that you have memorized the password, destroy the physical copy. Don't leave your flash drives lying around unattended, and get into the habit of locking your PC's screen whenever you leave the room.
Probably the most important reason for checking the integrity of a Linux ISO before using it is to be certain that the encryption software contained in it is the official version, and not some hacker's version with a backdoor. To do this, check the integrity of the ISO, which is done by finding the reference sha256 checksum on a trustworthy site (either the official site or Distrowatch, which lists the checksums for all of a distribution's "point" releases, such as Ubuntu 18.04.3, and not just the latest one).
Then, you would calculate the sha256 checksum for your ISO-copy (which you might have downloaded, or made from a DVD, which various Linux and Windows DVD-burner programs can do). The command for calculating an ISO's checksum is "sha256sum <path>/filename.iso." To get the ISO's path, right-click on it and select Properties in the menu which appears, and a window which contains various information, including the path and file's name, will appear. To copy it, either highlight it and hit Ctrl-C, or right-click on it and select "copy" in the menu which appears. To paste something into the terminal, use Ctrl-Shift-V.
If the checksums agree, you at least know that your ISO is the official version, although this still isn't an absolute guarantee that there aren't any backdoors into the encrypted partitions which you create with it. The only way to be certain would be to analyze the code, which is out of the question for most people. You might assume that there couldn't be a backdoor due to the threat of some whiz-kid programmer analyzing the source code and blowing the whistle if he or she finds something, but that's just wishful thinking. So, using encryption software is ultimately a gamble that it's not a means of luring us into a false sense of security so that Big Brother can snatch our encrypted drives and access our secrets, which he would have to do in order to access the data if you normally open them only on an air-gap system.
To be on the safe side, I use the slow-format method to format new flash drives, which erases everything on the drive before formatting it, to ensure that there's nothing on them which could compromise security. (The drive's firmware, which is a sort of "BIOS" for the drive, might contain viruses, such as Stuxnet, but no such viruses have supposedly actually been deployed in the wild, and I haven't seen any indications that they can create backdoors into LUKS partitions, although to be on the safe side, open them only on an air-gap system to ensure that the data when in unencrypted form can't be sent out over the internet by some virus.) By the way, the latest version of the Disks program (a.k.a. gnome-disk-utility) as of this writing has apparently undergone a major revision, and it can create LUKS partitions in free space, instead of having to create FAT partitions and then reformatting them as LUKS partitions. Keep track of which installation was used for creating each encrypted partition, pay attention to news of any vulnerabilities which might compromise the security of your data, and reformat any affected drives. Use long passwords which are easy to remember but impossible to guess, with upper and lower case letters, numbers, and symbols. Store a copy in a safe place (besides on the encrypted flash drive, such as in a list of all passwords you have ever used, in case you ever have a need for an old password which you've forgotten). When you are certain that you have memorized the password, destroy the physical copy. Don't leave your flash drives lying around unattended, and get into the habit of locking your PC's screen whenever you leave the room.
Subscribe to:
Posts (Atom)