Tails above the Rest: the Installation
Validate the Signature with sha256sum
Since Tails users need to care a bit more about security than the average user, you will need to go through the extra step of validating this signature. Depending on how paranoid you are, there are a few ways you can go about this. The simplest way is to attempt to download the signature file from multiple computers that are in different locations (and even in different countries if you can swing that; see my "Raspberry Strudel: My Raspberry Pi in Austria" article in the February 2013 issue about one method of colocating a Raspberry Pi in another country). Then, confirm that all of the checksums match. The idea here is that even if someone were able to perform a MITM attack or otherwise compromise your home computer or home Internet connection, it would be much more difficult also to compromise the connection at a public computer at a library, all the computers your friends use and the computer you have at work. With this in mind, simply download as many different copies of the signature file from as many different locations you can, and then use a tool like sha256sum (like md5sum, just using a different algorithm) to compare the checksum of all the files to make sure they are all the same:
$ sha256sum tails-i386-0.22.iso.sig 4578929f419d7f4bc99b99ec17a6c0ff3936c5bb02938d3940bac2b93580383b ↪tails-i386-0.22.iso.sig
In fact, if you are downloading the same version of Tails as I'm mentioning in this article, you even could use the signature published here as an extra point to compare against.
Note: if you are truly paranoid, you also can use GPG to validate further that this signature was created with the actual Tails signing key by taking advantage of the fact that the Tails maintainer has gotten the signing key signed by a number of Debian maintainers. This process is a little more involved, but if you want to go that route, it is well-documented at https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html#index3h1.
Validate the ISO with GPG
Once you have validated the signature, you can use it to validate the ISO. First, you need to download the public part of the signing key that was used for this signature from https://tails.boum.org/tails-signing.key. Once you have that signing key, import it into your GPG keyring:
$ cat tails-signing.key | gpg --keyid-format long --import gpg: key 1202821CBE2CD9C1: public key "Tails developers ↪(signing key) <email@example.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)
With the signing key imported, you now can verify the ISO image with GPG:
$ gpg --keyid-format long --verify tails-i386-0.22.iso.sig ↪tails-i386-0.22.iso
If you have added the signing key to your keyring, you will get a reply like:
gpg: Signature made Mon 09 Dec 2013 02:50:48 PM PST gpg: using RSA key 1202821CBE2CD9C1 gpg: Good signature from "Tails developers (signing key) ↪<firstname.lastname@example.org>" gpg: aka "T(A)ILS developers (signing key) ↪<email@example.com>" Primary key fingerprint: 0D24 B36A A9A2 A651 7878 7645 ↪1202 821C BE2C D9C1
Otherwise, you will more likely see the following output:
gpg: Signature made Mon 09 Dec 2013 02:50:48 PM PST gpg: using RSA key 1202821CBE2CD9C1 gpg: Good signature from "Tails developers (signing key) ↪<firstname.lastname@example.org>" gpg: aka "T(A)ILS developers (signing key) ↪<email@example.com>" gpg: WARNING: This key is not certified with a trusted ↪signature! gpg: There is no indication that the signature ↪belongs to the owner. Primary key fingerprint: 0D24 B36A A9A2 A651 7878 7645 ↪1202 821C BE2C D9C1
Either output means the signature matched, and you have the legitimate ISO. The warning in the second reply simply means you haven't personally signed the Tails signing key with your own key, so it's not part of your web of trust.
The following reply is one to look out for. If you see this, it means the ISO was not correct and either downloaded incorrectly or was tampered with and can't be trusted:
gpg: Signature made Mon 09 Dec 2013 02:50:48 PM PST gpg: using RSA key 1202821CBE2CD9C1 gpg: BAD signature from "Tails developers (signing key) ↪<firstname.lastname@example.org>"
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server