Another use for APT-Offline

2/26/26 (see Notes)

APT-offline came in handy when I was creating my MX-Linux 25.1 installation. I wanted to install Audacity on it, but my MX-L 23.3 installation became flaky when I installed Audacity on it and I didn't want the same thing to happen to my "master" installation of MX-L 25.1. 

My master-installation isn't the absolute first installation in the process I use. I buy Linux on DVDs from Shop Linux Online, use a "burner" program to make ISOs from them, and check the checksum of each ISO against the one provided by the official website. Then I use Etcher to create a non-persistent live installation from the ISO, then boot the live installation, and use the resulting live session to create a full installation on an SSD, which is the master-installation, which I then set-up and use for my first Snapshot-ISO. For the next ISO (creating the final ISO typically requires several ISO-iterations), I reboot the latest Snapshot-ISO to ensure that the live session is an accurate reflection of the ISO, then make all the desired changes, then create another Snapshot. If I were to use the master-installation, it would accrue all sorts of garbage that would end up on the Snapshots.

To avoid potential instability in my master-installation of MX-Linux 25.1, I didn't install Audacity on it. Instead, I used the Snapshot tool to turn it into an ISO, created a nonpersistent live installation from the ISO, booted the live installation, and added Audacity to the resulting live session. This required me to install a package index (a 90MB download) on the live session. 

But if I were to simply connect the live session to the internet and perform an update (which downloads and installs a fresh copy of the online package index, and entirely deletes the previously-installed package index, if there is one, to prevent conflicts), the package index would be stored in DRAM only, and if the PC were to shut down, the package index would be lost, and I'd have to download it all over again.  

But by using APT-offline (which I installed on the master installation, and which was therefore included in the Snapshot-ISO), I was able to download a copy of the package index to a storage device to avoid the possibility of having to download it all over again, and then install a copy onto the live session. If APT-Offline were installed on MX-Linux by default, I could have downloaded the package index once and installed it on the full installation as well. But I had to install the package index on the full installation before I could install APT-offline on it. [1] 

So I created the aforementioned Snapshot-ISO, turned it into a live installation, booted it, and used APT-Offline to download and install the package index, and then Audacity. Then I made a Snapshot-ISO of it, and then a live installation from the Snapshot-ISO. So far, there have been no indications that Audacity introduced any instability, other than the panel jumping around a bit when Audacity is launched.

Although I hadn't used APT-offline in a long time, it didn't take long to get the hang of it again, thanks to my system which allows me to use the same simple get- and install-commands for everything. I use the GUI to perform the set-op, i.e. to generate signature files, but my tutorial includes set-commands for those who don't have the GUI yet.

Get-operation error messages

It's normal to get a lot of error messages when performing a get-op, i.e. using APT-Offline to download stuff from the repository, because there are two systems for organizing the servers, and signature files include a set of URLs for each system. The typical error messages just flag the set of URLs that aren't compatible with the chosen server. If the same signature file were used on a server with the other organization, the other set of URLs would be flagged. I just ignore the error messages and have always obtained the required files.

Notes

Revisions

2/26/26

A) Rearranged sentence beginning with "But by using APT-offline" to make sense.
B) Clarified 2nd paragraph in Note 1.

[1] There are ways to install APT-Offline without first installing the package index, as explained elsewhere in this blog. But they're a PITA, especially if the PC has no internet connection, which is why APT-offline was created. By not including it by default, its purpose, which is to make it convenient to install stuff without an internet connection, is defeated. 

It seems to me that including at least a command-line version of APT-Offline, at least when adding it wouldn't require adding any dependencies of significant size, and letting people know that software can be installed on those Debian derivatives without a direct high speed internet connection, would make them more popular. 

I think of APT-Offline as a little jewel of a tool, or a toy, which does something which is traditionally considered to be impossible - installing software on Linux without a direct internet connection. It's the culmination of a great deal of development by those who developed the Debian package-management system. Many approaches were tried, and APT-offline came out on top.

Phone tethering and the short-sightedness of excluding APT-offline from distros by default

I've recently learned that tethering PCs to phones has become more feasible since I started writing about APT-offline, which makes it another option for connecting a PC directly to the internet, assuming that your phone-plan includes a sufficient amount of data and that it's feasible to take the PC to an area where the phone can establish an internet connection, preferably 5G.

In case the download-speed is slow, for whatever reason, prepare in advance by de-selecting any sections of the package index which are clearly not related to the software of interest (if this option is available in the type of Linux being used), which would be done before performing an APT-offline set-op (using the Linux installation of interest) to generate a signature file for a package-index download. The resulting signature file would be used in an APT-offline get-operation on some device with an installation of APT-offline and which can readily gain high-speed internet access, such as a 5G phone. The downloaded/validated package-index files would then be installed on the installation of interest, and then another set-op would be performed to generate a signature file for the desired software. If you don't know whether some section of the package index is related to the desired software, include it because it would waste more time to exclude a required section than to include one that isn't. I once de-selected the updates-section of the package index because I wasn't planning on updating the OS, but was then unable to install some of the software I wanted to install. It turned out that some of the required packages were listed in an updates-section of the package index.  

Signature files contain lists of URLs of files which must be downloaded to make the desired changes, combined with information which APT-offline requires in order to validate the files as they are being downloaded. In some cases, they include redundant listings to compensate for different server-organizations, so that if the file isn't found in one location on a particular server, it's found in the other location. This makes the signature file appear to be larger than it needs to be, and during the get-op generates many "not found" messages, which can be ignored.

Signature files are generated by entering an APT-offline set-command, which includes a list of the desired changes, on the installation of interest. The GUI, in set-mode, allows the user to select the desired changes, and when the create-button at the bottom of the set-mode-window is pressed, the GUI generates and enters the set-command which corresponds to the selections. Signature files are used by an installation of APT-offline on some device which can readily gain high-speed internet access, such as a phone, by entering a get-command which specifies the signature file and a destination-folder for the downloaded/validated files. (The GUI can't be installed on phones, but a few simple get-commands for APT-offline's text-command version can be stored in a clipboard-app and entered into a terminal with a few screen-taps, assuming that the signature files and download-destination-folders to be used in get-operations are placed in certain directories beforehand, which is easy and explained in detail in this blog's main article.)

No distros include APT-offline by default, although the text-command version (which can be used with a few simple commands) is small. On Xubuntu, which is about the worst case because it includes a bare minimum of software by default, APT-offline's text-command version would require only an extra 265K. If APT-offline were included by default, there would be no need to include the package index by default to accommodate those without a fast direct internet connection, thus reducing the size of the ISO far more than by excluding APT-offline by default. So, if reducing ISO-size is a high priority, it makes sense to include APT-offline.

If you need to lug the PC to some access point, and there aren't any public power outlets at any access points in your area, a 12VDC-110VAC inverter or an uninterruptible power supply could be used, although with the latter, you'd have get everything done before the batteries fade. So, if you can use 5G, you could get done faster and use a smaller UPS, assuming that the repository's server is fast.

In case you haven't guessed, I don't like laptops, for various reasons. Bare-bones mini-PCs, such as the ASRock Desk-Mini, are much less expensive, much more flexible, and potentially very secure, and if the keyboard or monitor develop some problem, it's cheaper to replace them. There was a time when you could get small cheap "netbook" PCs which could boot Linux flash-drive installations, and they were popular, but they disappeared from the free market without a trace.



Notes

[1] The text version of APT-offline can be installed without a package index or a direct internet connection, but this can be a major PITA, depending on how many dependencies it requires on the distro of interest, and how many levels of dependencies are required (the required direct dependencies might themselves require dependencies which aren't installed by default). The method involves manually searching the relevant repository via the relevant Packages site, comparing each required package against the Distrowatch list of packages included in that distro by default, downloading the required packages, and checking their checksums, which is normally done automatically by APT or APT-offline as the packages are downloaded. Then the packages would be installed one at a time with a "package-installer," some of which are slow and provide no information if an attempt to install a package fails because it requires some dependency to be installed first. Even in Xubuntu 22.04 (Xubuntu is one of the lightest-weight Ubuntu-based distros - only Lubuntu is smaller), installing APT-offline and its missing dependencies requires only 265KB of extra space. So, I don't see the logic of excluding it from all distros by default, considering that including it would allow the package index to be excluded by default, saving far more space than excluding APT-offline would save.

New APT-offline-GUI icon

5/5/24 (see Notes)

===================

Warning

There are potential security risks involved in connecting a phone (or for that matter any device with wireless capability) to an "air gap" PC. Even if the phone's wireless capability is supposedly disabled via software, it's possible that malware could enable it, such as in burst-mode, and even if it remained disabled, there would still be the possibility of malware on the phone accessing data on the PC. To be certain that hackers and malware can't access the PC via the phone, a "dumb" storage device such as a flash drive or SD-card should be used to relay data between the PC and the phone. Many if not most smartphones can interface directly with external drives, and if it's not convenient to move or copy files or folders with your phone's default file manager, you can install a dual-pane manager such as X-plore. Another possibility would be to use an MX-Linux installation just to make changes and to make duplicate installations for accessing/processing data (details below), so that there would be no data on the installation being changed, and you could connect the phone directly to the PC.

====================

My original APT-offline-GUI icon was too abstract and had a crude appearance by icon-standards, so I devised a replacement which expresses the essential aspects of using APT-offline with a phone as the internet-access device, and I used a combination of standard icons and shapes to give it a more polished appearance. It's more complex than the typical icon, but APT-offline is so unique that it can't be lumped in with anything else and symbolized by a simple icon. The details are too small to be seen in a small icon, but they could be seen by increasing the icon-size, which is an option wherever icons are used.

So, in the unlikely case that the icon were incorporated into APT-offline-GUI, and APT-offline were included in a Linux release, users could examine the icon and get a basic idea of what APT-offline does. They might realize that it would allow them to create a totally offline, totally secure installation, and to make changes to it without compromising its security. [1]   

In order to automatically appear in a panel or dock when the GUI is launched, and to be pinned in place to create a launcher in the panel or dock, the icon would have to be assigned an official name to avoid conflicts with other icon-names, the name would have to be incorporated into the APT-offline-GUI source code, and the icon would have to be placed in the appropriate icon-directory as part of the APT-offline-GUI installation-process. As it is, a generic icon is used.

In the new icon, the black arrow symbolizes the exchange of data between the PC and phone. This data consists of a) "signature files" (SFs), which contain lists of URLs of files to download, and information which allows the downloaded files to be validated [2]; and b) the resulting downloaded files, which are downloaded, validated, and stored in a folder reserved for the files listed in the corresponding SF, by the phone's installation of APT-offline running in "get" mode, perhaps after taking the phone to a suitable access-point, such as an area with 5G coverage or a fast wifi hotspot.

Error messages about files not being found are common during the download-process, but they're typically insignificant because signature files contain redundant listings to compensate for differences in server-organization, and if a file isn't found in one location on a particular server, it's found in another.

The downloaded files consist of software modules/packages, and/or "package index" files. A complete set of package index files is known as a package index, which contains information on all of the packages in the relevant online repositories, including which packages are required by each app. In some types of Linux, certain subsets of the online package index can be downloaded and installed, to reduce the amount of data required for an update, although I would caution against de-selecting any sections from the default selections unless you really know what you're doing, because you might end up needing the de-selected sections to make the desired changes to the PC. For example, I once de-selected the updates-sections (an option in Ubuntu at the time), because I was just installing apps, and it caused a problem because one of the apps I was installing required packages which were listed in one or more of the updates-sections. So, I decided to restore the updates-sections, without knowing whether it would solve the problem, and fortunately it did.

In Linux, a software-installation cycle consists of downloading package index files, then installing them, then specifying the desired software (such as apps or a software-update, which updates the OS and apps, and can require hundreds of MB), which causes the software/package manager to refer to the "local" (installed) package index and generate a list of packages (software modules) which must be downloaded in order to install the specified software. Some of the modules might have already been installed, and wouldn't have to be installed again, which is partly why the list must be generated on the installation of interest, and there are many other things which the package manager takes into consideration when generating this list. Once the list is completed, the packages would be downloaded and installed.

With a direct high-speed internet connection, it's easy to complete this cycle on a single day, while the package index reflects the latest state of the repository. But when using APT-offline, the interval between downloading package-index files and downloading packages might exceed a week, and the package index used for generating the list of packages to download would no longer reflect the state of the repository when the packages are downloaded. So, in previous revisions, I warned of a potential scenario in which packages might be deleted from the repository during the interval between downloading package index files, and using an SF based on those package index files in an attempt to download packages. But then it occurred to me that software modules are probably retained in the repository for at least a few weeks after being replaced by new revisions and de-listed from the package index, to eliminate the potential for such a scenario as long as the installation-cycle is performed in a reasonable amount of time.

In case you're wondering, the online package index can't be used directly, for various reasons, which would be very difficult to explain because APT (Advanced Packaging Tool, the software/package manager) and APT-offline are the result of years of development during which many complex factors had to be considered. Various ways to accomplish the same thing (installing software on a Debian-based system without a direct internet connection) have been tried, and the combination of APT and APT-offline was found to be the optimal approach.

After downloading the files, the phone (or the storage device such as an SD-card being used for passing data between the phone and the PC - see warning above) would be connected to the PC, and the PC's installation of APT-offline-GUI would be used in its install-mode to navigate to the aforementioned folder reserved for the files listed in the corresponding SF, and to initiate an install-op on those files. (There are other ways to use APT-offline to accomplish the same thing, but this is the most convenient and efficient.) This would completely install the files, except for app-packages being installed for the first time on that installation, in which case APT-offline places them in /var/cache/apt/archives, where packages are placed for installation during a normal installation process. To completely install them, the PC's software manager (Advanced Packaging Tool, or APT) would then be given a command to install the apps for which the packages were obtained, such as by entering "sudo apt install <app name>" for each app. This ensures that nothing gets installed which isn't part of an app, such a a piece of malware that somehow got slipped in with with the requested files, which is unlikely although you should protect the downloaded files until they're installed, and install them at the first opportunity. To make it easy to install the apps, it might help to keep a list of the apps which were requested during the set-operation which ultimately produced the downloaded files. (The name of the corresponding CNF [2] is a logical place for such a list, in an abbreviated form.) You could sift through the downloaded files to remember which apps you had requested, but there might be hundreds of files.

The sky-blue arrows in the icon represent internet connections, although the PC's has a negation-symbol superimposed to indicate the lack of an internet connection, or at least one with sufficient bandwidth to download the amount of data typically required to make a change to a Linux installation (updating the package index alone requires a download of 25-80MB, and installing some large apps can require over 100MB).

The list-icon on the phone-icon symbolizes a signature file stored on the phone. The lock-icon symbolizes APT-offline's "bullet-proof" level of security guaranteed to prevent corrupted files or malware from being installed [3].

An icon for Debian packages is used as the icon's background, to symbolize the ultimate goal, which is to install Debian packages.


Notes

Revisions

5/5/24 - Added an instruction to take a photo of the wi-fi card before removing it, and deleted previous revision-notes.


[1] To create an "air gap" (EM gap) PC, get a barebones mini-pc with a wifi card, take a photo of the wi-fi card in case you ever decide to re-install it, and remove the card. (I assume that if the wifi is simply disabled via software, there is some way to activate it with malware and use the wifi in burst-mode. Call me paranoid, but it doesn't hurt to be paranoid when it comes to data security.) Use long-nose pliers to pull the tiny gold-plated RF connectors off (assuming that the wireless card is horizontal, you would pull the connectors straight up), and cover the connectors with tape to prevent any potential shorting. Install memory, but don't install any internal storage (use external storage devices with encrypted and/or unencrypted partitions for storage and backup), and avoid any peripherals with wireless capability, because hackers might be able to use them to get into the OS. Never connect it to the internet when using an installation which has been used for accessing sensitive data, just to be on the safe side. However, a nonpersistent "live" installation which has been shut down probably wouldn't have any session-data on it, and would probably be safe to use. For the keyboard, I use an E-SDS Waterproof Industrial Keyboard with Touchpad, and to share my keyboard and monitor with up to four PCs, I used a CKLau-64H2ua KM switch. Neither has wireless capability.

Hackers want us to believe that they can spy on air-gap PCs via the power lines, but this is BS intended to prevent us from using air-gap PCs, because they can't be hacked, at least without taking extraordinary measures which require physical access to the PC. There is no way that any useful data can make it out to the power lines. There isn't even any useful data on the power supply pins of any of the chips in a PC. Even if there were, it wouldn't make it through the power supply out to the power line, which is typically noisy.

Authentication-key updates

Each installation contains decryption keys to allow digital signatures on InRelease files (which contain checksums for package-index files) to be authenticated, and the keys are updated periodically (because the encryption keys are changed periodically), which takes place during package index updates with a direct internet connection. However, key-updates aren't strictly required, as explained in the relevant entry of this blog. If you use a recent release to create an installation, the keys will probably be current for a while, and if you install all of the software right after creating the installation, you might be able to avoid the "cannot authenticate" messages which appear when you install software when the keys aren't up-to-date.

Types of installations for air-gap PCs

You could run the air-gap PC with a "full" installation (preferably encrypted to protect the data which it would retain) on a flash drive, and conceal the drive when not in use. (However, even if a full installation were encrypted, any data on it would be accessible to hackers when it's running, and the warning at the top of this page would apply.) To create a full installation, select a log-in password (or two if you intend to create an encrypted installation), boot the PC from a live installation, run its installation program (which would include an encryption-option), and use a freshly-formatted USB3 flash drive as the destination for the full installation, because full installations require USB3 drives, and some installers won't overwrite a previous installation. In case there's malware on the drive, perform a slow-format to overwrite the drive, which can take hours for large flash drives, and should be done at your convenience before performing the installation-process. In my experience, Sandisk Ultra-Fits and Ultra-Luxes are the only flash drives that consistently work well for full installations, although I tried just a few major brands. Another option would be to use a small nonvolatile memory modules, as long as it's easy to conceal when it's not in use.

MX-Linux, Snapshots, and NP "live" installations

I prefer to use MX-Linux (which is Debian-based, and thus compatible with APT-offline), because it has a "killer app" known as Snapshot, which makes it easy to turn an MX-Linux installation, with all of its settings and added software, into an ISO, which can then be used to create duplicate installations of various types. So, the full installation could be used as a "master," which would be used only for making changes and Snapshots, and the Snapshots could be used for creating nonpersistent flash-drive installations (NPFDIs), a.k.a non-persistent "live" installations, which are ideal for running air-gap PCs, because when they're shut down, they don't retain any trace of data accessed with them. Another advantage of this type of installation is that they're easy to replace if they fail, or get lost or stolen. I put them on USB2 drives, because they're adequate for this purpose, they're cheap, and they run cool, indicating low power consumption.

For storage, I use separate USB3 flash drives with encrypted and unencrypted partitions, and several backups scattered around. My system consists of a) a low-security drive (used on online and offline PCs) with a large unencrypted partition mainly for downloads, and a small encrypted one for text files that don't contain sensitive information; and b) a high-security drive (used on air-gap PCs only) with an encrypted partition. The system also includes a primary backup for a) and one for b), and secondary backups which contain a) copies of the low- and high-security drives (but not all downloads - only the ones which I consider to be reference material and want to archive); and b) a copy of my latest Snapshot-ISO in some cases, or c) a nonpersistent live installation of my latest Snapshot-ISO (which requires the entire drive). The primary backups are used for backing-up everything as soon as it's downloaded, created or revised. The secondary backups are updated weekly where appropriate.

The high-security drives contain a "heap"-folder (named "disseminate") which contains a) a copy of everything which has been added to the high-security drives since the last time the heap-folder was cleared, as described below, and b) a weekly-updated folder which contains a copy of the encrypted partition on the low-security drives. After updating b), the heap-folder is copied to each of the secondary backups, after deleting the previous week's copy of the heap-folder.

When the heap-folder becomes too large and takes too long to copy to the secondary backups on a weekly basis, the heap folder on the main high-security drive is cleared by disseminating its contents to suitable locations in the high-security drive's main file system, and by deleting what I no longer consider to be worth saving. The main high-security drive is then copied to each of the secondary backups. Assuming that it's been over a year since doing this, I also reformat all of the drives in my storage/backup system and refresh/update their contents. (I've considered using SD-cards instead of flash drives, to speed this up.) Each user would adapt this system to their needs.

Creating Snapshot-ISOs and nonpersistent live installations

When I'm running a full MX-Linux installation on my air-gap PC and using the MX-Linux Snapshot tool to create an ISO of the full installation, I use an SD-card to store the ISO, which saves considerable time, because Snapshot ISOs are typically huge, and SD cards have a very fast write-speed. Even so, creating a Snapshot takes about ten minutes. Creating NPFDIs is just a matter of copying an ISO to a flash drive in a special format, using a USB-installer program such as Etcher or MX Live USB Maker, an MX Tool on MX-Linux. This process is simple and takes about ten minutes.

The disadvantage of using NPFDIs to run the PC is that changing a setting, and making it persistent, requires changing the setting on the full installation, then creating a new ISO and a new NPFDI. So, I usually wait until I have to make a few changes, or an important one, before going through this process.

MX-Linux "master" installations: no data to hack

Another advantage of using the MX-Linux full installation as a "master," i.e. for nothing except making changes and Snapshot-ISOs, is that it can be connected directly to the internet to update the package index and install software, without having to worry about compromising any data. Using a direct connection to update the package index also ensures that the installation's decryption keys (which ultimately authenticate packages) are up-to-date, although this isn't strictly necessary if a major server is used, since any problems with it would be discovered quickly because many others would be constantly connecting to it directly, and the chances that someone would be able to spoof a repository are negligible.

If a master-installation fails (or if it's inadvertently used to run the PC and might contain sensitive data, and you want to be able to connect it directly to the internet), it could be re-created easily from the latest Snapshot-ISO. The new installation wouldn't have a package index, but it wouldn't need one until installing more software, by which time it might need to be updated anyways.

I also keep a record of every change (including every setting) that I make to the MX-Linux master installation, to minimize the number of revision-cycles (i.e. make changes to the master installation, then generate a Snapshot-ISO, then create a working-installation, and then use it for a while and realize that more changes are required) before arriving at a stable installation with a new MX-Linux release.

MX-Linux PERSISTENT installations

MX-Linux uses the "Antix live system," which allows for the creation of PERSISTENT live installations which could probably be used for running an air-gap PC without compromising security, because they can be set up to have "root" (software) persistence (so that you could make persistent changes to the installation), without "home" (data) persistence (so that the installation wouldn't retain data after being shut down), and they can be encrypted.

However, persistent live MX installations are difficult to use (although better written instructions/explanations, and experience, would help), and if a persistent live installation were being used for running the PC all the time, it would be more likely to fail than would a full installation being used just for making changes and Snapshots, and if you wanted a current backup, you'd still have to make a Snapshot every time you made changes. You'd avoid the step of making a new NP live installation, but making NP live installations is simple and takes only about ten minutes. So, I'm sticking with my system of using a full installation just to make changes and Snapshots, and NP live installations made from the Snapshots to run the PC. But for certain applications, the flexibility of persistent MX live installations is a big advantage.

[2] APT-offline signature files (SFs) are text files, but with a .sig filename extension, which are generated by the PC's installation of APT-offline running in "set" mode. In this mode, APT-offline uses the PC's software/package manager (Advanced Packaging Tool, or APT) to perform the most complex aspects of the set-process. The information which allows the downloaded files to be validated consists of reference checksums and files sizes (both obtained from the "local" or installed package index), and names to assign to files if they are found to be valid. For packages, whose names aren't changed when they are found to be valid, the replacement name is the original name, but by using the original name as the replacement name, APT-offline can simply replace the original name with the replacement name when a file is found to be valid, regardless of whether the file in question is a package-index file or a package.

APT-offline names every SF "apt-offline.sig" by default. As part of a system I devised to organize and simplify the overall process of using APT-offline, the default name is used for every signature file, but each SF is placed, along with a user-created folder named DDF (download-destination folder), which is intended to receive the files listed in the SF as they are downloaded and validated, and is reserved for the files listed in the SF - in a user-created "change-name folder" (CNF). The purpose of CNFs is to identify the purposes of the corresponding SF/DDF pair, and to separate SF/DDF pairs from each other, since they're all named alike and would clash if placed in the same directory. (The reason for using generic names for SFs and DDFs will become clear later.) A CNF's name might include a description of the target-installation, the date, and an abbreviated description of the changes which the folder's contents are intended to produce. For example, a CNF might be named "CNF-Brix-Xub2404-dd-mm-yy-update," or "CNF-Brix-Xub2404-dd-mm-yy-gimp-marble-update," where Brix is the name of a mini-PC, Xub2404 is the Xubuntu ("zoo-boon-tu") 24.04 installation on the Brix (some PCs have multiple installations on them), and GIMP and Marble are large popular apps. (GIMP is a powerful image-processor, and Marble is virtual-globe app like Google Earth, although not as sophisticated, but it can be used without an internet connection.)

The basic idea behind my system is to reduce the process of initiating a get-op to a series of screen-taps which can be performed on a phone even in a distracting environment, and to be able to consecutively perform multiple get-ops in a single download session, while keeping track of each SF/DDF-pair's purpose. So, at home, the phone would be connected to the PC, and the PC's file manager would be used to move each CNF into a separate get-op "hopper"-directory (a get-process directory, or GPD) on the phone. Then, each SF/DDF pair would be moved out of its CNF and directly into the corresponding GPD. This allows a fixed get-command (which translated to English is "go to GPDn, get the files listed in apt-offline.sig, and put them in DDF") to be used for initiating a get-op on the SF/DDF pair in the corresponding GPD (GPD1, GPD2, etc.). If the SF/DDF pair were left in the CNF, or if the SF and DDF had unique names, a new command would be required for every get-op, which would be highly impractical. So, if you have three PCs, you might want to perform three get-ops in a single download-session, and you would have three GPDs, each with a fixed get-command.

================

Note

Getting the path for the get-commands is tricky. You might know of some handy technique. I ended up installing a file manager named X-plore on the phone, because when X-plore is used for navigating to some directory in the phone's file system, X-plore displays the path and allows it to be copied and pasted. There are other file managers that do this, and by the time you try it, the PC's file manager or the phone's pre-installed file manager might be able to do this. I pasted the path into a text file on the phone and moved the file to the PC to process the text to create the get-commands, because I couldn't do it on the phone, but you might be able to do it on your phone. So, take the following instructions as a suggested approach, and feel free to modify them if you have a better approach.

================

To create the get-commands, you would use a PC to create a text-file named "get-command-1.txt" containing the basic get-command ("apt-offline get path/GPD1/apt-offline.sig -d path/GPD1/DDF," where "path" would be left empty for the time being), and move the file to the phone. Then, on the phone, you would install a file-manager app, such as X-plore, which allows you navigate to a directory and copy its path so that it can be pasted where required. Then you would navigate to a certain directory (specified in the main article in this blog) which is the optimal location for GPDs, copy its path, paste it into the aforementioned text file, and move the text file back to the PC, because it's far easier to perform the next steps on a PC, than on a phone, or at least it was for me when using my phone. Then you would open the text file on the PC, insert the path into the command in two places, delete everything besides the command from the file, and make two copies of the text file (one named "get-command-2.txt" and one named "get-command-3.txt"), so that there's one file for each command, to make it easy to copy each command to a clipboard-app on the phone (I tried selecting individual commands from a single text-file on my phone, and gave up). Next, you would substitute the correct number into each occurrence of GPD1 in each of the copies, and you would have the required get-commands.

Then you would copy the get-command files to the phone, install a clipboard-app on the phone, open each text file (one at a time), and copy the command, which would enter the command into the clipboard-app, and repeat this for each text file containing a get-command. Then each command could be copied into the terminal with a few taps, and then entered. (The terminal is part of the Userland app, which must be installed on the phone in order to install APT-offline on the phone. This site's main article provides the details.)

After the download-session, the downloaded files would be installed by using the PC's installation of APT-offline-GUI in install-mode to navigate to the DDF of interest and to initiate an install-op. If the changes are being made to an MX-Linux installation which is being used as a "master" installation (explained elsewhere in this article), the phone could be connected directly to the PC without creating security risks, but it might be necessary to use the phone's file manager to move the relevant SF/DDF pair back into its CNF, so that the PC's installation of APT-offline can find the DDF. But otherwise, the DDF containing the downloaded files, along with the associated SF, would be returned to their CNF, using the phone's file manager, and the CNF would then be copied to a flash drive or SD-card, which would then be transferred to the PC, to eliminate the security risks.

This might sound like too much work, but once the system is set up, it's very easy to use.

If you want to install software, and it's been a while since the package index was updated, you would generate an SF for a package-index update, then use the SF in a get-op to get the package-index files. Then you would install them, generate an SF for the desired apps, and use that SF in a get-op. You might want to consider downloading package-index files on a weekly basis, if convenient, just to have fairly fresh ones on hand in case you need to install them.

[3] Never create an installation from an ISO which you have obtained from an outside source, without first authenticating the ISO. This is done by calculating the ISO's checksum (a function built into some file managers, sometimes initiated by right-clicking on the ISO and selecting the calculate-checksum function in the resulting menu), and comparing the calculated checksum to the reference checksum. I use SHA256 checksums, which are the highest-security reference checksums typically provided. If the checksums are different, the difference won't be subtle. In my experience, the easiest way to find the reference checksum of the latest release of some type of Linux is to visit the official website, but if you need a checksum for an older release, I suggest Googling "checksum Linux <type version>." Distrowatch has checksums for older releases, but it can be difficult to find them.

Indications of key-update process during direct package-index updates found in Ubuntu

In a previous post, I indicated that repository-keys are apparently updated during package-index updates performed with a direct internet connection, but without providing any indication that the keys are being updated. (The keys are not updated when an update is performed via APT-offline, which explains the "cannot authenticate packages" warnings which appear when installing software after performing an update via APT-offline.)

However, I've since created an installation of regular Ubuntu (which I've realized is much better than I previously indicated, although I still think that the workspace-switching scheme is excessive), and performed a direct update on it via the terminal, and noticed indications that the keys were updated first. So, this confirms my suspicions that the keys are updated during direct package-index updates, but it still doesn't mean that every detail of the process was divulged.

How to authenticate package indices for PCs which cannot be connected to the internet

Rev 8/6/22 (see Notes)


Every package index includes a Release or InRelease file (actually probably one for each of several sections) which contains a digital signature which must be decrypted with the public key corresponding to the secret/private key with which the signature was encrypted, in order to be authenticated, i.e. proven to be an official package index. This file contains checksums for the rest of the package index files, and the package index files contain checksums for every software module/package in the repository. So, this constitutes a secure chain of evidence that the packages are official and safe to install. But even without digital signatures, there would be very little chance that anyone could create counterfeit package indices and substitute them for authentic ones, although there are situations in which it would be possible. In some cases, such as in Ubuntu and its "official flavors," some of the required keys are not included by default, and if you create an installation out of one of these distros and update the package index via APT-offline, and then, with the installation disconnected from the internet, enter "sudo apt install <app> -y," where <app> is some large app which requires many packages try to install something, "cannot authenticate packages" (CAP) warnings will probably appear in the terminal because some of the keys are missing. I've tried various approaches to install the missing keys and eliminate the CAP-warnings, and the only way that works is to update the package index with a direct internet connection.  


After creating a full installation, first enter "echo 'Binary::apt::APT::Keep-Downloaded-Packages "1";' | sudo tee /etc/apt/apt.conf.d/10apt-keep-downloads" (copy the command without the beginning and end quotes, and paste it into the command-line with Ctrl-Shift-V) so that any software-packages which are installed via a direct connection are retained in /var/cache/apt/archives after they're installed, instead of being deleted, which is done by default in many types of Linux. (It's easier to just enter the command instead of trying to determine whether it's necessary.)

Next, the package index should be updated, and when this is done with a direct connection (instead of using APT-offline), the first thing that happens is that missing keys are installed and outdated keys are updated. (I realized this after finding debian-archive-keyring in /var/cache/apt/archives, although I had never entered a command to install it, so obviously it was installed in the background during an update.) However, something else happens which doesn't happen when these same keys are installed without a direct internet connection, and whatever it is makes the difference between success and failure. I have tried copying the contents of usr/share/keyrings from an installation which has been updated ("sudo apt update") online (which eliminated "cannot authenticate packages"/CAP warnings from the online installation), to the same directory in an offline installation, but it didn't eliminate the CAP-warnings from the offline installation. I've also tried installing the missing keyring (debian-archive-keyring) both online and offline, and running "apt-key update" (the apt-key command will no longer be available as of Ubuntu 22.10) both online and offline, but none of these eliminated the CAP-warnings. So, obviously, something happens during an online update that doesn't happen during any of these unsuccessful approaches. Some articles indicate that it's necessary to associate each source in the etc/apt/sources.list file with a particular key, but I checked the sources.list file after updating Kubuntu 22.04 online, and the the list had the conventional format, so clearly this is not necessary, and Kubuntu's developers apparently considered it to be overkill. (It would provide a benefit only if the private keys of the official archive had been stolen, which is extremely unlikely. PPA-keys, on the other hand, might get stolen if the maintainer uses lax security practices.)

So, as far as I have been able to determine, a direct connection is required to install or update keys so that the system can make use of them.   

Once the proper keys are installed, the actual package-index update begins by attempting to decrypt the digital signature in each Release/InRelease file (which are the first package-index files to be downloaded) with the corresponding key, presumably successfully (assuming that it's not counterfeit, which is highly unlikely, but not impossible). Even if the proper keys aren't installed, and the package index can't be authenticated, it would be installed anyways, because chances are that the authentication failure is due to missing or outdated keys. Still, I'd rather check the index with the proper keys to eliminate even the small chance that the index is counterfeit.

Linux Mint is one of the few Ubuntu-derivatives, if not the only one, in which all of the required keys are installed by default (apparently - I can't find any solid information on this subject), and the package index is not locked by default, so that you can use the package manager (APT) to generate a "download script" for APT-offline. (A download-script is a simple list of the URLs of the packages required to install APT-offline on that installation with the software configuration which existed when the script was generated. Installing APT-offline typically requires python3-magic to be installed first, so it's typically listed in APT-offline download-scripts, but if something else which requires python3-magic were installed first, python3-magic wouldn't be included in the APT-offline download-script.) Then, assuming that the installation doesn't have a direct internet connection, you would go to an access point and download the required packages from the Ubuntu Packages website (an interface to the repository), along with their reference SHA256 checksums, calculate their SHA256 checksums (right-click on each package, select Properties, and then select the tab with buttons for calculating various checksums) and compare each calculated value to the corresponding reference value. If they're different, you can tell with a glance.

So, Mint might be a good choice for an offline installation, assuming that it's 100% compatible with your PC. (Mint is notorious for its PC-compatibility issues, but there are lists of compatible PCs, and you can buy PCs with Mint pre-installed.) But you might prefer another type of Ubuntu without the hardware-compatibility issues, or for example Kubuntu so that you can install Kdenlive (the top-rated Linux video editor) with a mere 60MB download, as opposed to 200-300MB to install it on other types of Linux.

The problem is that there is apparently no way to update the keys on PCs which have installations of Ubuntu or its main derivatives, and which cannot be connected to the internet, such as bulky and/or power-hungry desktop PCs which have no internet connection and are not practical to take to an internet access point. However, I've devised a work-around for such cases. There might be better solutions, but if so, they're very well hidden, and chances are that most people would be able to find some way to to obtain a temporary direct high-speed internet connection for even a desktop PC, and avoid my convoluted solution.

My solution (although in practice not in this order) is to use APT-offline to obtain a copy of the package index, then to install a copy of it on an installation in which the package index has been updated by means of a direct internet connection, and then, with the installation disconnected from the internet, enter "sudo apt install <app> -y" for some large app which requires many packages (such as kdenlive). If the package index is counterfeit, you would receive CAP-messages which indicate that many  of the required packages cannot be authenticated. In some cases, I've gotten CAP-messages related to just a couple of packages out of many which the app requires, which might mean that a key for a particular section of the package index is missing or outdated, although if an update had been performed, all of the keys should be available and up to date. But if just a couple of packages are affected, you could compare their checksums to the reference values on the corresponding download pages of the corresponding Packages site (i.e. Debian Packages or Ubuntu Packages). If you don't receive any CAP-messages, the package index obtained via APT-offline would have to be authentic, and you could install another copy of it on the "unconnectable" installation, and disregard any CAP-messages which will probably appear when you install software due to the unconnectable installation's missing or outdated keys.

There are two major approaches to accomplishing this goal, one of which involves taking a mini PC and possibly a 12VDC-110VAC power inverter or an uninterruptible power supply to an access-point (if no power outlets are available at the access point), and perhaps a cardboard hood to shield the monitor from sunlight. The other approach would involve a couple of trips to the access-point, but with just a phone or a tablet (for details on installing and using APT-offline on an Android or iOS device, see APT-offline A-Z). If the keys in the distro which you use for your "unconnectable" PC are incomplete by default (i.e. in the source-file and when the installation is first created) you'll have to take the first approach. With Linux Mint, however (at least as of 20.3), the latter approach can be used. (But with Mint, the first step is to  ensure that your PC is on some list of compatible PCs.)

A) Take mini-PC to access point

The most straightforward approach would be to take your "portable" PC [2] with a flash-drive installation made from the distro that was used for the installation on the "unconnectable" PC to the access point and perform a direct update using the default repository-settings, unless you really know what you're doing when you change the repository-settings. If some of the required keyrings are missing or outdated, the latest versions would evidently be automatically installed in the background (i.e. with no indication) during the package-index update, based on my experience. For example, I performed a direct update on a flash-drive installation, after entering the aforementioned command to retain downloaded software packages after installing them, and later found the debian-archive-keyring package in the software archive, although I didn't enter a command to install it. So, it must have been installed automatically in the background during the update.  

Next, I'd install APT-offline and nmon [3], along with any other software I'd need in the foreseeable future, on the flash-drive installation. Then, if your installation doesn't have a good disk I/O monitor (such as a widget or a configurable system-monitor app), I'd launch nmon by opening a terminal and entering "nmon," then hit "d" to configure it to monitor disk I/O, which comes in handy when writing large amounts of data to a flash-drive installation, to avoid prematurely terminating the write-process, which can take longer than indicated by the terminal. Normally, to avoid interrupting the write-process, flash drives are ejected and left plugged in until the ejection-process is complete, but flash-drive installations can't be ejected when the PC is running from them.

Then I'd use APT-offline to generate a signature file for an update (open a terminal and enter "sudo apt-offline set apt-offline.sig --update," which would create the signature file and place it in the Home directory), and then put the signature file and a folder named DDF (download-destination folder, to contain the downloaded packages) in a folder named "CNF-<distro-abbrev>-update-<date>," (such as "CNF-Kub2204-update-M-D-Y). CNF is for "change-name folder," which is part of a system I devised for using APT-offline efficiently, even when using Android/iOS devices for the get-operation - see APT-offline A-Z for details.

Next, I'd open a terminal in the CNF and enter a generic get-command ("apt-offline get apt-offline.sig -d DDF" - there is no "sudo" in get-commands). This would download the package-index files, screen them for errors using the reference checksums and file sizes in the Release or InRelease file, and if a file passes its screening-test, it is renamed with the name listed in the signature file after the file's URL (the name which it must have in order to be installed), and placed in the DDF.

The final step in updating an installation via APT-offline is to install the downloaded package-index files. To do this, you would normally transfer the flash drive which contains the downloaded files (in the DDF in the relevant CNF), to the target-installation, and then use the target-installation to open a terminal in the CNF and enter "sudo apt-offline install DDF," while keeping an eye on the disk I/O monitor to see when the installation is actually complete. But in this case there is no need to transfer the device containing the downloaded files to the target-installation, since it already is connected to the target-installation.

Once the package index obtained via APT-offline is installed, I would perform a mock installation (without an internet connection) of some large app that requires many packages and that's not already installed, by entering "sudo apt install <app> -y." If any CAP-messages appear which indicate that packages in general cannot be authenticated, the package index would be counterfeit, but otherwise it would be authentic, in which case another copy of the package index could be installed on the unconnectable installation, and software could be installed on it without regard for the CAP-messages caused by its missing or outdated keys.

B) Multiple trips to access point with phone or tablet

Based on my recent experience, the keys in Ubuntu and all of its "official flavors" are incomplete until the relevant installation is updated via a direct internet connection. Linux Mint is the exception, as far as I know, at least as of 20.3, so might be the best distro for your unconnectable PC (assuming that that PC is 100% Mint-compatible). In that case, you could use APT to identify the packages required to install APT-offline, by performing a mock installation as if you had a direct internet connection, and APT would indicate what it tried to install but couldn't due to the lack of an internet connection. Then you would download those packages from the Ubuntu Packages site, along with their checksums. (Copy the checksums from the download-page into a text file, because although the Ubuntu Packages download-pages with the checksums can be downloaded like a regular html page, they can't be opened with a web browser. LibreOffice Writer will open them, but it's not as convenient as copying the desired information and saving it in a text file.)

Then you'd check the checksum on each of the packages required to install APT-offline (right-click on each one, select Properties in the menu which appears, and then select the tab which calculates checksums, and the rest is obvious), and if they match the reference values from the Packages site, you would install them by clicking on each of the packages, and following the package-installer's instructions. The next step would be to use APT-offline to perform an update, as described above, and once the update is performed, you could install any software you would need for the foreseeable future. By the time the keys expire, I assume that there would be another Mint release with the new keys.   

If you don't know whether any of the keys required by your installation are missing by default, you could install APT-offline using the package installer, then use APT-offline to update the package index, and then use APT itself to perform a mock installation (without an internet connection) of some large app that's not already installed. Then if you get any CAP-messages indicating that none of the packages can be authenticated, you'll know that you'll have to perform a direct update to install or update the keys, and if you have an unconnectable installation of the same type, you'd have to re-install the package index obtained via APT-offline onto the directly-updated installation and perform another mock installation to check for CAP-messages which indicate that packages in general can't be authenticated. If there are none, the package index would have to be authentic, and you could install it on the unconnectable installation and disregard the CAP-messages which I assume it would produce due to disabled or outdated keys.

So, it's a convoluted process, but being able to use Ubuntu or one of its derivatives (I prefer the derivatives) on an unconnectable desktop PC, for example, is worth the wade.   

===========

Notes

8/6/22 - A) In the fourth paragraph, added a list of unsuccessful methods which I used in an attempt to install the required keys. B) Cleaned up some lousy writing in a few places and tweaked several passages. C) Revised Note 1 and added Note 3.


[1] 16GB Sandisk USB3 Ultra-FITs are good for Linux installations, due to their combination of reliability, price, performance and power consumption. Their problem is that they have plastic connector-shrouds, which wear out, but you could effectively give them a metal connector-shroud by pluging them into a USB3 M-F adapter and just leaving them plugged in. Sandisk's small, metal-cased Ultra-Luxe drives are also quite fast, although they seem to dissipate quite a bit of heat, and the only 16GB version which I tried didn't last very long. (Still, other 16GB units might run just on the warm side, and provide excellent performance and reliability.) Sandisk also makes a small metal-cased "Flair" drive which might be good for Linux installations, although the one I tried didn't last very long at all. So, Sandisk seems to have a problem getting its chips into small metal cases. I've tried a few other major brands, and other than a 16GB Kingston USB3 Datatraveler (no longer available), they were DOA, or Linux wouldn't even run on them. Cheap Chinese drives are notoriously unreliable because they're made from 2nd-rate chips from the periphery of the wafer, so I wouldn't put an installation on them. An article which recommends various flash drives for Linux installations recommends Sandisk Ultra-FITs and PNY Turbos, among others which are either expensive, or USB2's which are good for live installations but not full installations. But Amazon reviews indicate that PNY Turbos have a high failure rate. HP flash drives (which are made by PNY) might be more reliable, but they're not cheap.

[2] Laptops and Chromebooks might be convenient, but I doubt that you can use either to create a flash-drive Linux installation and boot from it, which can be done with mini-PCs. Mini-PCs can also be configured as air-gap PCs and connected to a keyboard and monitor through a KM switch to share the keyboard and monitor with other PCs, including an online mini-PC and perhaps a desktop PC for heavy-duty data processing. (For details on creating a cheap air-gap PC, see my post on the subject.) The potential problem with mini-PCs is providing them with power at the access point, which can be done with a 12VDC-110VAC power inverter plugged into a car's cigarette lighter or with an uninterruptible power supply with sufficient capacity to power the PC for about 15 minutes if no power outlets are available.

[3] Nmon is an excellent, terminal-based system monitor which uses bar-graph indicators and can be easily configured to monitor various processes, although your installation might already have a good widget for monitoring disk I/O (Kubuntu 22.04's is the best in my experience), and then there's Conky with the MX-Linux standard configuration, which I covered in one of my posts, and GKrellM.

Software developer casts doubts on the future of Flatpak, etc.

Rev 4/19/22

On a lark, I decided to try Amberol, a simple music player which is currently available only in the form of a Flatpak. After downloading what must have been about 100MB, which was just the first part of six, I decided that I was no longer interested in it, and terminated the installation. I've been using the MOC player, although after fiddling with Clementine (standard in MX-Linux XFCE) for a few minutes, I realized that it provides the option of dragging files and folders onto it to play them and put them in a queue, and the ability to clear the queue with a click. By default, it displays a periodic spectrum analysis, but it can display other types of waveform analyses, or none, which I chose to reduce the use of system resources, although the analyzer wasn't much of a load on the system. So, for my purposes, Clementine is a great choice. Something like Amberol would be better, if it were available as a Debian package, instead of as a separate OS to run on top of the existing OS.

I decided to see if I'm the only one who thinks that the amount of data required to install Flatpaks is ridiculous, and found a 2021 article entitled Flatpak is Not the Future at ludocode.com, written by an experienced software developer, who indicates that Flatpak, Snappy, etc. are causing more problems than they're solving, and that the solution is to standardize the libraries (the OS-modules used by apps) across Linux distributions, which is supposedly taking place to some extent. 

I also looked into the global prevalence of internet access, and found that there are still billions of people on the planet without good internet access, and for them, Debian-type Linux, which includes APT-offline, is a good option. There's also the option of using a laptop or a Chromebook to run Linux, and to take the device to some internet access point (such as a wi-fi hotspot) to access the internet and to make changes to the installation. However, Linux laptops tend to be expensive. (Netbooks, which were cheap little Linux laptops with the potential for extreme security, have apparently been banned, because they're no longer available despite their popularity when they were available, or precisely because of it.) But Chromebooks which can run Linux apps have reasonable prices.

But if you don't like laptops/Chromebooks for some reason (I don't like the cost, and all the compromises made to fit everything into the case), and would rather use a PC that remains at home, and use a phone or a tablet to download web pages to view at home, and to download software/data modules to make changes to the home PC's installation, you could do the former with apps designed for that purpose (since web-pages for phones aren't the same as those for PCs), and the latter with APT-offline.

Installing APT-Offline on MX-Linux without an internet connection

3/19/22

Because updating the package index in MX-Linux requires an approximately 80MB download for the XFCE version and 120MB for the KDE version, I wanted to be able to download the package index and the software once, and reuse them, to avoid having to download them again. So, I wanted to use APT-offline, because when you update an installation with APT-offline, it downloads the package-index files into a folder created by the user for those files only, and it can install them on as many installations (of the same type and version) as you like.

However, there's a catch: APT-offline isn't included with MX-Linux by default, and the software/package manager wouldn't tell me what packages I had to install in order to install APT-offline, because the package manager is locked on new installations (including on live installations) until the package index is updated. So, it looked as if I would have to update the package index by means of a direct internet connection, in order to unlock the package manager, and then install APT-offline and use it to download the package-index files into a folder to retain them. (During a normal package-index update-process, the downloaded package-index files are automatically deleted after being extracted and installed, although I suppose there's some secret, convoluted command which would prevent them from being deleted.)

Then it occurred to me that I could go to the "Debian packages" site, find a list of packages which are required for installing APT-offline on MX-Linux 21 (which is based on Debian 11, a.k.a. Debian Bullseye), and then determine which of these had been installed when I installed them on another installation by means of a direct internet connection, and assuming that only a few packages would be required, copy them from the aforementioned installation (thus avoiding the need to validate them, since they had been validated during the normal installation process), and install them with package-installer such as GDebi, by simply clicking on them. It turned out that, in order to install APT-offline on MXL-21, only two packages totaling 65KB are required: python3-magic, and APT-offline itself (not APT-offline-GUI, which requires several dependencies and would be a pain to install by means of a package-installer). So, I obtained copies which I had installed on another installation by means of a direct internet connection, and which therefore had been validated, and installed them on live versions of MX-Linux 21 XFCE and KDE by just clicking on them (python3-magic first, since APT-offline depends on it), as a test, and found that it worked.

But in general, you could go to the relevant Packages site (such as Ubuntu Packages), get the list of "depends" (required) files required to install APT-offline, and then check Distrowatch's list of packages installed by default on the release of interest. Then you'd go to the relevant Packages site and download those that aren't installed by default, calculate the checksums of your copies, compare them to the reference values on the Packages site, and if they match, install them by simply clicking on them. The installer would then let you know whether they had already been installed, or whether another of the packages which you had downloaded and screened would have to be installed first. But the list would probably be small in any case for APT-offline, so this approach would probably be practical in any case.


> Creating a signature file for a package-index update

Once APT-offline is installed, you would tell it to create a signature file [1] named apt-offline.sig, for a package-index update, by simply opening a terminal wherever you want to put the signature file (right-click in the chosen directory, and select "open terminal here" or "open in terminal"), and entering "sudo apt-offline set apt-offline.sig --update." Next, you'd create an "APT-offline Change-Name Folder" named "AOL-CNF-<PC-designation>-<type of installation, such as MX21-X for MX-Linux 21 XFCE>-update-<date>," which would provide you with sufficient information to identify the purpose of the signature file and its age, which you would put inside the CNF-folder along with a generically-named download-destination folder named DDF to receive the downloaded/screened files produced by the get-process, performed with some device with a 4G or better internet connection and an installation of APT-offline (such as on Ubuntu installed on top of the Android app Userland - see APT-Offline A-Z at AnAptOfflineBlog for details).

> Creating a signature file for installing apps

To create a signature file to install apps, you would enter "sudo apt-offline set apt-offline.sig --install-packages," followed by a list of apps, using their special names without caps or spaces, separated by commas ONLY (no spaces). To get the software modules/packages/files, you would process the signature file exactly as you would for getting software-index modules - put it in an appropriately-named CNF along with a DDF, transfer the CNF to the download-device, etc.


> Rationale for my system for using APT-offline

By using generically-named signature files and download-destination folders, and always putting them in the same directory on a phone before initiating the get-process, the get-process can be initiated with a fixed get-command, such as "apt-offline get <pathGPD>/apt-offline.sig -d <pathGPD>DDF," where pathGPD is the path to the "get-process directory" (any stable, convenient directory into which each apt-offline.sig/DDF pair would be transferred for use in a get-operation, and then returned to their CNF). Once you enter this command into a terminal, you can execute it again by pressing the up-arrow key (or whatever key has this effect) until the command appears on the command-line, and then pressing Enter, which is easy to do even on a phone. Then, if you have another signature file to process, you could move the processed apt-offline.sig/DDF pair back to its CNF, using an Android file manager such as X-plore (my favorite), then move the next apt-offline.sig/DDF pair into the GPD, and perform another get-op by re-entering the fixed get-command.

> Just ignore get-op error-messages

You can probably safely ignore the error-messages which typically appear in the terminal during the get-process, because they typically indicate that APT-offline has given up on one approach and is taking another (due to differences between repository-structures), and in my experience it has always found a combination of approaches that works.

Installing packages obtained via APT-offline

Then you would connect or copy the CNF to the target-installation, open a terminal in the CNF, and enter "sudo apt-offline install DDF." This would install the package-index, which could take a while to install on a flash-drive installation due to the size of the index after extraction (120MB for XFCE, and 200MB for KDE, as I recall), and the typical slow write-speed of flash drives. So, wait for the terminal to return a command-prompt, indicating that it's done.

To install software packages, you would first "add" them to the installation (put them in the "archives" directory, either manually or by using APT-offline to perform an install-op on the folder containing the software), after which you would actually install them by performing a normal installation-process for each of the apps listed in the set-command which created the signature file, and hopefully listed in an abbreviated manner in the CNF's name. They would be saved in an archive-backup which would contain all of the software packages which you had installed on that installation, along with the latest package-index-file download which you had installed on that installation, because to install the software specified by a particular set of package-index files, you'll have to install the same package index files. If you forget what's included in the folder, you might have to search through a lot of files to find the actual app-packages, so it might be a good idea to keep a list of installed apps along with the software and index files.

If you want to install more software on the same installation, you could try your old copy of the package index, but you might find that you have to update it, such as if some of the packages specified by your old package index are no longer available from the repository. When you get the packages for the new software, you would add them to your archive-backup which contains all of the software packages you have installed, and your most recent copy of the package index.

If you create a new installation, and try to install your saved software using your latest copy of the package index, you might find that you have to update some of the software to be consistent with the package index. Assuming that the packages are still available from the online software repository for that type and version of Linux, you would then get them and install them, but if they aren't available, you'd have to update the package index and then go through the process of installing all of the software again, which might have the effect of updating some of the software modules (or, if you're using APT-offline to install the software, listing the updated software modules in the signature file). Avoiding this convoluted process is why it's best to install all of the software you'll need at once, but you can't always anticipate what you'll need. If just a few packages are required to add an app, you could try to install them by means of a package-installer, without updating the package index, as described above for installing APT-offline. But if there are conflicts between the requirements for the existing and desired software, it might not be practical to resolve them without using the package manager.

Even if you never want to install more software,  but just want to keep making new installations indefinitely (theoretically), the package-index files will probably become too old to use at some point, and the package manager would refuse to install them on a new installation, even though you weren't planning on using it to access the (online) repository. So, if you want to continue to create additional installations without downloading package-index files every time, you would have to get new package index files with APT-offline and save them. You could try to use the same software with the new package index, but you might have to get some upgraded software packages. Then, each time you end up having to download more software packages, you'd add them to your backup-archive for that installation. You wouldn't have to delete packages that have been superseded by updated versions, because you can copy them to the new installation (to /var/cache/apt/archives), and the package manager would just ignore them.

If you want to get fancy, such as to download vast amounts of data (such as an OS-upgrade) very quickly (assuming that you have a suitable internet connection), there are options which you can use with the get command to optimize the get-process. These options are listed on the apt-offline(8) "manpage" (manual-page).

Notes

[1] An APT-offline signature file is a specialized text file which contains a list of URLs of files to download, combined with security-related information such as checksums, file sizes, and names to assign to the files if they pass their tests.

Installing Ubuntu Snaps on offline installations

Rev 11/24/21 (see Notes)

According to an article entitled
Snap Packages {Comprehensive Guide for Ubuntu Users} (https://phoenixnap.com/kb/snap-packages), Snaps can be installed on installations without an internet connection, as follows:

To download a snap package, use the following command:

snap download <package_name>

Download a snap package.

The system downloads two files to your $HOME directory – a .assert and a .snap file.

Note: It is advisable to also download and install the “core” and “gnome-3-26-1604” snaps if they are not already present on the target system. This is because some GNOME snaps require them to function properly.

1. Copy the downloaded files to the $HOME directory of the machine on which you want to install the app.

2. Install the packages using the following commands:

sudo snap ack <package_name.assert>

sudo snap install <package_name.snap>

[end of excerpt]


So, I looked into whether it would be possible to install snapd on Ubuntu on Userland on an Android phone, and found that it apparently is, although it's a 34MB download and I decided to put it off for a while. But assuming that it would be able to perform the procedure described above, it would be possible to download snaps with an Android phone and install them on a Linux installation. But snaps are typically massive, so you'd need a high-speed connection to download them in a reasonable amount of time.

I can think of several scenarios in which APT-Offline would still come in handy, and there will most likely be a demand for it for a long time to come. I enjoy using it because it's like an intricate toy that performs functions which nothing else can perform. With the instructions I've provided, those who want to use it should be able to figure out how to use it and adapt it to their situation. The instructions are long, but the idea is to read the introduction, and then start using APT-Offline to make some desired change to some installation, and refer to the instructions only as needed. There's nothing like using APT-Offline to learn how to use it.

Unfortunately as of this writing, it appears that APT-Offline doesn't perform the install-operation, or at least it doesn't on my installation. I'll try upgrading my system and see of that fixes it, but if not, the solution would probably be to make a fresh installation and get a temporary direct internet connection to set it up without installing APT-Offline, because if it doesn't perform the install-op, yet somehow ended up getting released, it might contain malware, and can't be trusted.

To get a temporary internet connection, you need to have access to AC power at your access point, and if all else fails, you could use an DC-to-AC inverter plugged into a car's cigarette lighter, or an uninterruptible power supply. You might also need a cardboard hood over the monitor to block direct sunlight.

If after using your secure installation for a while you realize that you want to install something else on it, perhaps you could find it in the form of a Snap and install it as described above, because if APT-Offline can't perform the install-op, the only other definitely secure procedure at that point would be to create a fresh installation, get a temporary direct internet connection for it, and set it up again.
 
Creating new installations isn't a big deal if you don't store any data on them (for details, see my review of the Gigabyte Brix GB-BLCE-4105R mini-PC, at http://toggwu.blogspot.com/2021/11/cheap-air-gap-pc.html), although the only flash drives which I've used and which work well are Sandisk Ultra-FITs, which must be plugged into USB-3 ports to provide the functionality required for an installation. The vast majority of U-Fs have plastic connector-shrouds, and in one such case which I was constantly plugging and unplugging the drive, part of the shroud broke off, although it didn't have any effect on its usability (Lexar manufactures a model without a shroud.) The U-Fs sometimes run on the hot side, although Sandisk apparently doesn't consider this to be a problem. 15GB U-Fs have slow write-speeds compared to 64GB U-Fs, so naturally the installation-process takes much longer on 15GB U-Fs compared to 64GB U-Fs. Because U-Fs are physically tiny, I attach tags to them to label them and to make it easier to find them if they get dropped. I also use combinations of brightly-colored zip ties (such as yellow, and dayglo green and orange) to make them more visible and to give each one a color-code to differentiate them from each other.

I also tried a Lexar 32GB USB-3 drive, and although it had a very high write-speed when I was erasing it before performing the installation, it had a very slow write-speed during installation, and the installation booted extremely slowly and didn't function correctly. So, Lexars are OK for storing data, but unusable as bootable drives. I've also tried two installations on a 15GB Kingston USB-3 Datatraveler, but the installations didn't respond to my inputs very quickly, although they worked much better than the installation on the Lexar. I like the fact that the Kingston has an all-metal connector (which is the same as the drive's body), and that it ran cool. So, in a pinch, Kingstons could be used. I plan on trying Verbatim Metal Executive USB 3.0 flash drives, because I've found Verbatims to be very reliable, which is obviously a requirement for a bootable drive.

I use cheap Chinese drives with LED transfer-indicators and caps for uncritical data (which is nevertheless backed-up multiple times), because I like their no-nonsense physical design and the fact that they're fairly easy to label. For example, in some cases I simply mark them with a Sharpie, and then put clear tape over the label. To change the label, I remove the tape and wipe the drive with alcohol. In other cases, I create a window in a piece of wide clear tape by placing a piece of narrow clear tape face-to-face across the wide tape, and then cutting the wide tape to certain dimensions and wrapping it around the drive so that the window is on one side of the drive, and then I put a label under the window and cinch the tape to hold the label in place. But these drives have a high failure rate because they use low-quality chip grade-outs from the edges of wafers, as opposed to the high-quality chips from the center of the wafer, which are used for more expensive drives.

Notes

Rev 11/24/21 - Corrected claim that Lexar 32GB USB-3 drives make good bootable drives, which was based on an erronoeous recollection. I tried one such drive again, I realized that it's actually unusable as a bootable drive. Also made other revisions to section on flash drives.

New suggestions for portable devices for running Apt-offline

Rev B - 7/16/19

With the arrival of Android 8/Oreo, GnuRoot no longer runs on all Android devices, but there is a successor to GnuRoot, known as Userland. However, when I tried Userland, I gave up on even installing it because it requires knowledge that few users probably have, and the installer provides no indication of status or progress for the main installation, which is reportedly huge, which I gather means that it's larger than 100MB. But I don't know, because all of the articles written about it are vague too.

So, you could get an Android tablet which runs 7/Nougat, just for running Apt-offline on top of GnuRoot Debian, and noncritical apps. (Android security is apparently partly based on keeping the OS in a state of upheaval.) However, I can't guarantee that the resulting package-downloads would be safe to install, due to the lack of Android security updates, so use this approach at your own risk.

Another option for a portable device for running Apt-offline is a Chromebook, now that all Chromebooks run Linux apps:

In case you've missed it, last year, Google started making it possible to run desktop Linux on Chrome OS. Since then, more Chromebook devices are able to run Linux. Going forward, all of them will be able to do so, too. Yes. All of them. ARM and Intel-based.
[...]
It's as simple as simple can be. Just open the Chrome OS app switcher by pressing the Search/Launcher key and then type "Terminal". This launches the Termina VM, which will start running a Debian 9.0 Stretch Linux container.
Congratulations! You're now running Debian Linux on your Chromebook.

Want Ubuntu instead? It's a bit more trouble, but you can bring up Ubuntu with a few shell commands. Want to run, say, Fedora? You can run Fedora with Chrome OS, as well.

from All Chromebooks will also be Linux laptops going forward

So, Chromebooks are now the ideal portable device for running Apt-offline, other than the fact that they don't fit in pockets, whereas small tablets fit in large pants-pockets. (I like Intel's compute-card design, where the electronics are put on a module and plugged into a lap-dock, so that the guts of the laptop could be removed and carried in a pocket. I'd also consider making the battery removable, if it's not already a standard feature, so that for example it could be put in a pocket instead of being left in a hot car.) Chromebooks are also the ideal approach to accessing the internet, whether or not you have good internet access at home, especially now that they can run Linux apps at the same time.

Anti air-gap-PC hysteria

Rev 12/6/18

Today I did a quick search using the term "air-gap," and found what appears to be a desperate attempt by the NSA to suppress the use of air-gap PC's. The claims that they aren't secure from all possible attacks might apply to systems which are targeted by intelligence agencies, but the average person probably doesn't have to worry about these attacks. For instance, the notion that someone can monitor the power line outside your home and determine what's on your encrypted flash drive is absurd, especially since PC's use regulated power supplies which would prevent any data from getting out to the power line from a PC. (The only way to get a signal out would be to modulate the PC's power consumption to such an extent that it could be detected on the power line, which is possible but would probably require noticeable changes in the PC's behavior. A PC's power consumption is low compared to a lot of other things, which might be turning on and off, and then there's power-line noise, so it would be very difficult to get any data this way.) The claim that there are Windows viruses that copy data to and from flash drives in hopes that they will be plugged into an air gap PC is plausible, but I don't care about Windows since nobody who is security-conscious would use Windows for an air-gap PC. Other, even more exotic techniques are also the stuff of intelligence agents, and not likely to be applied to the average home PC-user who just wants to keep personal data such as shopping lists and correspondence from Big Brother. So don't let these claims frighten you away from using an air-gap PC, which combined with an online mini-PC and a KVM switch provide a very high level of security for a very low cost in terms of time and money.


Revision notes

12/6/18- Added "(The only way to get a signal out....)"

Some ideas on gaining temporary internet access for setting up Debian installations for use as internet-access-impaired installations

Rev 11/26/18

KDE Neon is one of the most difficult types of Linux to use without a direct internet connection, due to several factors, although they can be overcome by using a temporary direct connection for initially setting it up, such as by updating the package index and adding Apt-offline, kdesudo, Synaptic Package Manager, and Software & Updates (software-properties-kde for the KDE desktop, and software-properties-gtk for everything else). (The software manager provided with Neon is clearly intended for use with a direct high-speed internet connection, and not for customizing the package index to your needs.)

Ubuntu itself was also intended for use with a direct high-speed internet connection, although it doesn't require as much initial set-up as Neon to make it suitable to use as an internet-access-impaired installation. (Just update the package index and install Apt-offline-gui and any other apps you want initially.)

If you can afford a laptop PC which can boot Linux from a USB port, setting-up a flash-drive installation would be easy, and the installation could then be used for booting another PC, including a desktop which could be used even for video editing (the video files would be stored on an hdd/ssd, perhaps in unencrypted form due to the amount of processing required to encrypt video). However, such laptops tend to be expensive, and I don't like laptops in general for various reasons. There was a time when you could get a small laptop ("netbook") without an OS (and without built-in wireless!), into which you could plug "Linux on a stick" and boot it, but this didn't sit well with Big Bro, who didn't want it to be convenient for everyone to get a PC which he couldn't monitor. (Based on Snowden's claims, the Thought Police are a secret division of the NSA.)

So, netbooks disappeared from the "free market," and if you want something with the same capabilities without bowing down to the laptop-dictatorship, the best alternative is to use an AMD-based mini-PC without built-in wireless, and with a wired-only keyboard and a wired-only monitor, because it could double as a secure home-PC. (At home, I have cheap "offline" and "online' mini-PC's which run Linux and share the same keyboard and monitor through a KVM switch. I don't have to worry about hackers, viruses, or updates, although I replace the OS on each PC every year or so to stay reasonably current.) Portability is compromised, because you'd probably need an AC outlet. Perhaps you know of an access-point where you would be allowed to use AC outlets, but if not, you could get a DC-to-AC inverter and run it from your car's electrical system. There are small monitors which are designed to use in cars, or you could use a regular monitor when there is little sunlight, or somehow block some of the sunlight (perhaps put a cardboard hood on the monitor - typically on the top and sides, and about a foot deep, although it could be something like a box with a slit in it). You could use drive-in restaurants as your wi-fi access points (you'd use an external wi-fi adapter, some of which plug into Ethernet ports and don't require special drivers). These are just some possibilities, and you can probably come up with some others.

But once the installation is set up, it would be much more convenient to use Apt-offline to make changes, and if you want to make some changes to a secure installation, Apt-offline allows the changes to be made without compromising security.

But then there's always Xubuntu, which includes Apt-offline's text-command version by default (which makes it easy to install Apt-offline's GUI, which comes in handy at times). The decision to include Apt-offline's text-command version is a reflection of Xubuntu's intelligent, minimalistic overall design. It's a little rough around the edges, but Ubuntu and its derivatives are undergoing major changes (such as the development and incorporation of a new display-server known as Mir), and rough edges are to be expected until the dust settles.


Revision notices

11/24/18 - A) Corrected the 1st sentence in the 4th paragraph. In the initial version, I accidentally wrote "wireless" when I meant "wireless-less," i.e. wired-only. If wireless capability exists, you should assume that it can be surreptitiously enabled, such as in burst-mode, to spy on you. Wi-fi burst-mode is a reality, and it cannot be detected without special equipment. So, a secure PC cannot have any wireless circuitry, period, including in any peripherals. The NSA's TEMPEST-spec takes this to an extreme - it considers even wire to be a wireless device. B) Clarified the last paragraph.

11/25/18 - A) Revised the sentence beginning with "If you can afford a laptop PC..." for clarity and to mention the use of an hdd/ssd to store video files.

11/26/18 - A) Tweaked the sentence beginning with "If you can afford a laptop PC which...."  B) In the sentence beginning with "There are small monitors which are designed to use in cars," changed "shroud" to the more common term "hood," and suggested a couple of basic designs for the hood.

Linux for practical secure dual-PC systems

During the interview, Snowden discussed his motivations for releasing the documents to journalists, explaining, "The intelligence capabilities themselves are unregulated, uncontrolled, and dangerous. People at NSA can actually watch internet communications and see our thoughts form as we type. What's more shocking is the dirtiness of the targeting. It's the lack of respect for the public and for the intrusiveness of surveillance."

Edward Snowden, quoted in In NBC interview, Snowden says NSA watches our digital thoughts develop
http://arstechnica.com/tech-policy/2014/05/in-nbc-interview-snowden-says-nsa-watches-our-digital-thoughts-develop/


Snowden was apparently referring to a "Thought-Police" black-op within the NSA which snoops on us partly to interfere with our plans to make us feel powerless. Don't plan on getting rid of them, because you can't get rid of something if you can't find it.

Although learning to use Linux can be frustrating, it is worth the effort because it is the most practical OS to my knowledge for creating relatively inexpensive secure PC systems which don't rely on software (other than AES-grade encryption software, which is trustworthy) for protecting data. In such systems, there are two PC's which share a monitor and a keyboard by means of a KVM switch, one of which is used for accessing the internet but not for processing sensitive information, and another PC for processing sensitive information (such as shopping lists, plans, and messages to be encrypted and transferred to the internet-connected PC for transmission), which is unquestionably secure because a) it is completely electromagnetically isolated from the internet, and it has no internal drive which can be used for surreptitiously storing data to be uploaded to the Thought Police when a connection becomes available, or to be retrieved during a "no-knock search" (it stores data only in an encrypted form on physically small USB flash drives which are removed and hidden when not in use); and b) the installation can be maintained by using a unique program named Apt-offline, which combined with the new "containerized" software systems for Linux, allows any available change to be made to the installation (including OS-updates) without connecting it to the internet. Installing the new "containerized" types of Linux software is like installing Windows software, but the new systems won't entirely replace the old systems anytime soon, if ever, so there will still be a place for Apt-offline in the Linux world for the foreseeable future.

You could probably create the same kind of system with Windows, but you would need two copies of Windows, and to update Windows on the secure PC, you'd have to get a copy of the latest version of Windows and use the copy to update the installation (or to create a new installation). This will become more feasible when Windows Core is available, because it will allow installations to be tailored to the PC, instead of using a gargantuan OS which is the same for every device. It might also be possible to create two installations of Windows from a single copy to run on a single PC, and run one on the PC in "secure mode" and the other on the PC in "non-secure mode," but it would be inconvenient to put it mildly to switch between the two installations.

Linux is great for accessing the internet, because it's essentially immune to viruses. I've been using it to access the internet for over 7 years, and have never had any problems with viruses, or any need to install anti-virus software. Although OS-updates are made available, I don't use them except in rare cases, and have never had reason to regret it. Instead, I replace the entire OS every couple of years to stay reasonably current.

Linux also allows you to format any drive, including physically tiny, all-metal USB flash drives and micro-SD cards, which can be hidden easily, with an encrypted format which the NSA reportedly won't even try to crack. Instead, they would try to get the password, which I suppose could involve sneaking into someone's home, and circumventing the typical security measures. (Booby traps are illegal for good reasons, so don't get any stupid ideas.)

The only reason I would use Windows would be for some application which I couldn't get anywhere else, or to use a piece of hardware that doesn't work with Linux. Windows works well in Windows ads, but recent Chromebook ads indicate that many people still have problems with it. Chromebooks are great for people who don't want to think about their PC beyond using the applications, and think that BB couldn't have any reason to spy on them and/or that taking steps to prevent him from spying on them is un-American, but if you want a PC which you can trust to protect your data, Linux is the probably the best OS for you. You might balk at the cost of the required hardware, but you can use inexpensive mini-PC's which use the latest AMD processors, which have a lot of processing-power per buck and per watt, and you can't obtain completely trustworthy security through other means at any cost.