Lurking with PGP
When people verify that their copy of someone else's key is correct, they don't laboriously check 1000-10000 characters of the ASCII representation of the key. Instead, they compare an abbreviated form called a fingerprint. Each key is verified by its fingerprint, which is represented by 32 hexadecimal characters. The possibility of two keys having the same fingerprint is so close to nil that you don't even have to consider it. So if the fingerprints match, the keys match.
Before checking fingerprints, it is best to quickly check the ID. The ID is even more abbreviated; it consists of only 8 hexadecimal characters. If, for instance, a user uses two different sets of PGP keys, the ID is used to differentiate between them.
Since we started with comp.os.linux.announce, let's show how you can easily retrieve the public key for verifying those messages. (I assume that you have PGP installed. If you don't, I'll explain later how to do that. I just want to keep things simple for now.)
PGP normally tries to do the right thing without being told. If you feed it a public key, it figures that you want to add it to your “public key ring”, available for inspection or use at any time. Normally, you call it with the name of a file, so try this:
finger email@example.com > /tmp/cola pgp /tmp/cola
If PGP complains “Key ring file 'home/.pgp/pubring.pgp' cannot be created”, then you should create the directory ~/.pgp and try again:
mkdir ~/.pgp pgp /tmp/cola rm /tmp/cola
PGP will ask if you want to add the key to your public key ring; answer yes. When it asks whether you want to certify any keys yourself, answer no. You can't do that without having created your own public and private key. You will still be able to verify messages, but you can't use some of PGP's built-in features. This will look like Listing 2.
The comp.os.linux.announce key is now on your public key ring, and you can now use it to verify posts made to comp.os.linux.announce.
Now let's try checking the signature on a message posted to comp.os.linux.announce. Using your newsreader, save a message to a file, preferably with the extension “.asc” (short for ascii). Let's save it in the file cola.asc, and then call PGP to check the signature:
PGP is verbose (as usual), and checks the signature. Part of what it says lets us know that the signature checks out Okay—but it warns that it can't be sure, because you don't have a key of your own:
File has signature. Public key is required to check signature. Good signature from user "Lars Wirzenius <firstname.lastname@example.org>". Signature made 1996/05/01 11:36 GMT WARNING: Because this public key is not certified with a trusted signature, it is not known with high confidence that this public key actually belongs to: "Lars Wirzenius <email@example.com>".
If you want to get rid of that warning, you will have to create your own keys, and before you do that, you ought to read the manual and understand it.
PGP also saves a copy of the message without the signature in a file called cola—it strips the .asc from the filename. If you had saved the original message in a file named “cola”, it would have asked you for a different filename to put the unsigned message in. Unfortunately, at the present time, the only way to check a signature without creating a new file containing the unsigned text is to press CTRL-C when PGP stops to ask you what to do.
In order to verify that your copy of a key is the right one, you need to put the key on your keyring, and then use PGP to print its fingerprint. Use the command:
pgp -kvvc user_id
where user_id is either part of the recipient's e-mail address or the actual 8-character key ID. Listing 3 shows part of the output of this command for the key used to sign Announcements of the Linux Emergency Response Team (ALERTs), which are used to announce security issues related to Linux. This (-kvvc) shows a lot of information for each key; you can get a more concise listing with the command:
pgp -kvc user_id
Now try to print the fingerprint for the key Lars uses to sign comp.os.linux.announce postings. You can check it below.
Once you have generated the fingerprint, you need to compare it to a trusted version. That might mean the fingerprints listed in this article, or it might mean calling the sender on the phone, or it might include a fingerprint listed in a book. There are many options—it's up to you to judge if the option you choose provides good enough verification for your purposes.
Here is a list of IDs and fingerprints for important and useful keys in the Linux world:
Lars Wirzenius's comp.os.linux.announce key:4CBA92D1 E7FA89856D9B781D F530EBFBD811CA3F
Linux Security FAQ Primary Key used to verify ALERTS:ADF3EE95 AB4FE7382C3627BC 6934EC2A2C05AB62
Ted Ts'o's signature key used to sign other people's keys (Ted organizes PGP-signing BOFs at conferences, and so has signed many other people's keys):466B4289 9C056649DF837EEF D8AC7542A2334B91
Your humble author, who will also be organizing PGP-signing BOFs at some conferences, and wants to show off:4536A8DD 2AEC88084064CED8 DDF8122B61438315
(Please note that in order to fit the fingerprints into the article, we have removed many of the spaces. The spaces are just there to help you read the fingerprint, and the fingerprint is the same with or without spaces.)
Linux developers are starting to talk about listing their PGP key IDs and fingerprints in the CREDITS file in the Linux kernel source code.
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!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- SourceClear Open