An Introduction to Gnu Privacy Guard (part 2)

An Introduction to GNU Privacy Guard (Part 2) by David D. Scribner (September 26, 2002)

DesktopLinux.com guest author David Scribner has penned an article introducing new users to GnuPG on GNU/Linux (and UNIX) systems. In Part Two, Scribner continues his tutorial on using this powerful encryption package Part One is available here . . .

An Introduction to GNU Privacy Guard
by David D. Scribner

In the first half of this article we discussed the various uses that GNU Privacy Guard could bring to your business or personal life in enhancing security of your digital documents and files, as well as the basics in getting started with GnuPG. As there is so much more to public-key security than command-line operations, in this second half I will continue with importing and exporting keys, building (and keeping) your 'web of trust' sound, and a few of the more popular GUI front ends available for GnuPG.

Keyrings & Keyservers

As you've seen, the concept behind GnuPG and public-key security deals with keys, and keyrings. When you created your first pair of keys, you also created your first keyrings. If you take a look in your home directory, you'll find a hidden directory created for the GnuPG files (~/.gnupg). Within this directory there will be two keyring files, pubring.gpg and secring.gpg. The pubring.gpg file is your public keyring, and secring.gpg is your secret, or private, keyring.

Your secret keyring, containing only the one or two secret keys you create will remain small, however the public keyring will grow as you collect and add more public keys to it. Your secret keyring should be stringently protected at all costs, but your public keys, and keyrings if desired, can be shared.

As you continue working with GnuPG, you will note that many users publish their public keys on web sites or key servers. In the past, keys were exchanged via email, BBS or newsgroups postings. In recent years as the popularity of public-key security has gained ground, formal key servers have evolved to handle the need of dispersing these keys in a more convenient and centralized manner. After you've created the keys you'll be happy with and have worked with GnuPG to get to know your way around it a bit (and thoroughly memorized your passphrase!), you'll eventually want to start exchanging your public key(s) with others.

You'll also find various public keyrings dispersed on the Internet. Many of these keyrings hold the public keys of GnuPG/PGP users belonging to special interest groups. As you experiment with your secret and public keyrings, you may consider importing several keys from one of these keyrings to see what they're comprised of. You will likely find keys that have been signed by several other key holders, include additional email addresses, or even identifying photos. Since you may not actually know any of these people, you will probably limit your experiments to signing and encrypting files to your own key sets, but importing a few 'popular' keys from one of these keyrings will give you an idea of what yours can become like down the road! When you're done, they can be easily deleted from your keyring if you choose.

Say for example you find a user's key available for download on the Internet that you want to import into your own public keyring, and the key is named "user-key.asc". After downloading the file, to import this public key into your keyring you would use the command:

$gpg --import user-key.asc

Likewise, to make an ASCII-armored copy of your public key that can be emailed, included as a download link, or whose contents can be displayed on a web page so others can import it into their own keyring, use the command:

$gpg --armor --export username > keyname.asc

This will export your key in ASCII armor format as previously explained, for the username or key ID specified, redirecting the output to the file "keyname.asc".

Key servers, or 'keyservers' as they are sometimes referred to, have simplified the dispersing of public keys to the masses as it provides a somewhat centralized repository to post and retrieve public keys from. Although there are several key servers out there, most all are connected and synchronize their data. If you post or update your key to one of these servers, you'll find that the key will be broadcast and updated to the other key servers, sometimes rather quickly.

A couple of the more popular key servers are MIT's PGP Key Server and the OpenPGP Key Server. For other key servers closer to your geographic location, you might take a look at the OpenPGP Server Lookup web site. There, you'll find listed other key servers located around the world.

It's at these key servers that you can search for a public key belonging to someone by their name, email address or key ID. Keyservers are also good to use when verifying a key's fingerprint. If you were given a key by someone, or download one off the Internet from a web site, checking that key's fingerprint against the one listed on a keyserver to make sure they match is a good precaution to take as it will minimize the risk of receiving a bogus key. That's not to say that all keys on a keyserver are legitimate, but due to their circulation bogus keys can often be exposed for what they are.

Importing public keys from a key server into your keyring is as simple as specifying the key to import, and the key server to import it from. For example, the command:

$gpg --recv-keys --keyserver wwwkeys.pgp.net user@some-email.com

will import from the keyserver, "wwwkeys.pgp.net", the key for "user@some-email.com" into your keyring. Exporting a key is just as easy. The command:

$gpg --send-keys --keyserver wwwkeys.pgp.net user@some-email.com

will export the key for "user@some-email.com" currently residing in your public keyring to the keyserver "wwwkeys.pgp.net".

However, not everyone wishes to have his or her public key uploaded to a key server. So, if another user gives you their key for signing, always check with them prior to submitting it to one of the key servers. They may prefer that you email it back to them in a signed and encrypted message instead.

Web of Trust

Now that we've covered creating a key pair for your encryption and authentication needs, and have experimented a little with importing and exporting keys for yourself to use as a learning experience, you're probably eager to start exchanging keys with other users. One of the fundamental aspects of using public-key cryptology with GnuPG/PGP is the ability for users to "'sign' other users keys, adding yet another layer of legitimacy to that key. This also allows you to detect any tampering with the key in the future. However, signing another's key(s) is something that should not be taken lightly as it will affect the level of trust others have established in your key.

By having others sign your key, they are helping you establish what has become known as a 'web of trust'. Having several signatures on your key helps assure others receiving your key of its authenticity, especially if the key receiver also knows one or more of the others that has signed your key.

Keep in mind that when someone signs your key, they are only vouching for you in that your key is authentic and that it indeed belongs to you, because they have personally verified the fact. They are not vouching for your personality, ethics or morals, only that you are who you say you are identity-wise, and the key they've signed is yours.

Before you go signing another's key, it's important that you first verify that the key you were emailed, downloaded from a key server or were given actually belongs to that person. If you were to do this over the phone, or even in person, checking each character of the person's ASCII-armored key block would not only be exhausting, but extremely error prone as well. As such, each key has a 'fingerprint'. These fingerprints are derived from a hash of the key block, and provide a relatively sure way of verifying the key to the owner without error.

To view a key's fingerprint, the GnuPG command 'gpg --fingerprint keyID' is used. The output displayed can then be used to communicate the received key's fingerprint to the owner, who can then verify that the fingerprint is correct, and matches the fingerprint of their key. An example of a key's fingerprint, as output by GnuPG, might look similar to:

pub 1024D/F357CB52 2002-07-09 GnuPG User

Key fingerprint = 5172 708D CA58 C2D9 4082 BA0D 103D 1293 F357 CB52

sub 2048g/A9CB69B3 2002-07-09

Once you've confirmed that the fingerprints match, you can then sign that user's public key with your secret key to validate it. When you created your key pair and a public key was formed, it was automatically signed by your secret key when using GnuPG. To sign another's key however, you can use the command:

$gpg --sign-key keyID

Along with '--sign-key', one other command for signing keys is available that I want to bring to your attention, and that is '--lsign-key'. The '--lsign-key' command signs the public key for local use only (instead of flagging your signature as being exportable along with the key as the '--sign-key' command). As your signature is not exportable, you're not validating that user's key for others to rely on, but it will still be treated as a valid key on your local system.

Why would you sign a key for local use only? Perhaps one example would be that you imported a key used to verify the signature of a software package. You want to sign the key so that the risk of tampering with this key without your knowledge is minimized, and warnings issued by GnuPG about using a non-validated key won't be displayed. The command to locally sign a key is:

$gpg --lsign-key keyID

You will be prompted for your passphrase, after which your signature will then be attached to that key. To sign a key you could also edit that key. The GnuPG command to edit keys is:

$gpg --edit-key keyID

This invokes the interactive menu system that allows you to modify the properties of a particular key. To sign the key with your secret key, in turn allowing your signature to be exported, use the menu command 'sign'. Just as when using the '--sign' and '--lsign' commands from the shell's command prompt, you will be asked for your passphrase. When correctly supplied, it will attach your signature to the chosen public key when you then use the 'save' command, or 'quit' and respond that you want the changes saved.

The interactive menu system used when editing keys gives you a greater degree of flexibility when signing a key. For example, if you have a key that contains more than one user ID, you may want to sign only one or more IDs for that key, but not all of them. You might choose to do this if you weren't able to verify the email address associated with that ID, or want to keep the size of your keyring smaller than it would be if your signed keys had your signature attached to every ID (the key will still be considered valid, and as your keyring grows, signing only one ID on locally signed keys helps keep their size down). When you first display a key with '--edit-key', you will see something similar to:

pub 1024D/2B94CF89 created: 2001-01-01 expires: never trust: -/q

sub 1024g/12E688D4 created: 2001-01-01 expires: never

(1) Close Friend (GnuPG Gnut)

(2). Close Friend (Webmaster)

Command>

The period after "(2)" indicates that this ID is the primary user ID. If you were to sign the key now, your signature would also be attached to that user ID as well. To mark a different ID, or several IDs for signing, the menu option 'uid' followed by the chosen number is used. Once marked, the ID number will have an asterisk placed after it. If you were to mark the first ID to attach your signature to, the resulting output would look like:

pub 1024D/2B94CF89 created: 2001-01-01 expires: never trust: -/q

sub 1024g/12E688D4 created: 2001-01-01 expires: never

(1)* Close Friend (GnuPG Gnut)

(2). Close Friend (Webmaster)

Signing the key at this point with the 'sign' menu command attaches your signature to the chosen ID. The menu command 'save' will then save the signed key and exit, or you could use the menu command 'quit' to exit without saving any changes.

Other commands you'll find useful in the interactive menu for editing keys are 'fpr' to list a key's fingerprint (which you'll do when verifying the key with the owner), 'check' to list the signatures on a key, 'adduid' and 'deluid' to add or delete a user ID on a key (name, comment or email address, which comes in handy if your email address changes), and 'trust', which is used to assign a trust value to a key. For a list of commands that can be used with this interactive menu, simply type the word 'help'. After pressing the [Enter] key, a list of possible commands will be displayed.

When should you use the 'lsign' command in place of the 'sign' command? Anytime you cannot refutably verify that the key you're signing belongs to its owner! This is perhaps the most vitally important safeguard you can take in keeping your "web of trust" sound. Unless you have personally checked and verified the identity of the person against the key you were given with complete complete confidence, or one of your trusted fellows has (more on this below, in Level of Trust), don't sign it with an exportable signature! You may have found Werner Koch's (the main developer of GNU Privacy Guard) key on the Internet, but unless you can personally verify the key, don't sign it with an exportable signature. Doing so will only weaken the level of trust others have placed in you to vouch for another's key validity, in turn weakening your web of trust.

I would like to add that, while on the subject of building your web of trust, many 'famous' people have their public keys posted on key servers and the Internet (Linus Torvalds, Philip Zimmermann, Richard Stallman, Wichert Akkerman, Theodore T'so, Eris S. Raymond, etc.). If not common sense, then at least politeness should dictate that unless you actually know this person or will be conducting business with them, don't disturb their peace by invading their personal life in an attempt to verify their key just so you can sign it with your exportable signature. I'm sure they're kept busy enough as it is.

How does your web of trust grow? By getting to know other GnuPG/PGP users, and spreading the value that public-key encryption and authentication can bring to a person's personal and business dealings. You could add your public key's fingerprint to your email signature line perhaps (which sometimes brings about questions as to what it is by unknowing recipients, giving you the chance to evangelize), or once you've created a key pair you're happy with, publish your public key to a key server, or post the key block on your web site.

Many computer user groups may also hold key signing events where their member's keys are checked for accuracy and the holder's identity verified with a photo ID or driver's license. The keys are then later downloaded or emailed to the participants, key fingerprints checked, signed and returned to the user or key server as requested. Check your local user groups to see if they're holding one in your area. Linux user groups in particular often hold key signing events, and even parties in some localities, where the participants are invited to mingle and get to know each other in a more informal setting after the verification process is over.

As well, the Internet has come to the aid of some as there are sites (Biglumber.com for example) that will post lists of users wanting to have their keys verified, as well as users willing to sign another's key. Checking the lists for your area might put you in touch with someone local so the verification process can be completed.

If GnuPG were to stop here however, your 'web of trust' would really be no more than a 'wagon wheel of trust', as the only trusted keys on your keyring would be those to which your signature is attached. As in real life, the concept of trust used with GnuPG extends beyond that. Say for example there was a local GNU/Linux convention that you attended with one of your good friends, Greg. At the convention the two of you run into a buddy of his, Tom, operating one of the booths and were introduced. You don't know Tom personally, but you do know Greg and trust that if he said this person was indeed Tom, you would have few doubts as to his identity.

GnuPG utilizes trust levels in much the same way. You may acquire keys for which you don't personally know the individual they belong to, yet due to the interaction with other keys on your keyring that are trusted, they may be 'introduced' and therefore treated as valid to varying degrees. This is what establishes the "web" in the web of trust model. These keys may not be linked directly to your key, but by the interconnection with other keys on your keyring, they in fact become a part of your web.

Levels of Trust

Many new to public-key use are sometimes overwhelmed by the word 'trust' when referring to the keys in their public keyring. In simpler terms, there are basically two types of trust available to you, 'validity trust' and 'owner trust'.

Validity trust, also called calculated trust, is based on to what extent a key can be considered valid. When you sign a key it's considered fully valid. If you can't verify with absolute certainty that the key belongs to its owner, and the owner is who they say they are, you can either sign the key for local use only (so your signature is not exportable, but the key is still considered valid), or refuse to sign the key and allow the validity to be calculated. If you do verify the key as being authentic, you can sign the key with an exportable signature and the key is then not only considered valid by you, but can also be treated as valid by others that have placed trust in you.

This type of trust is referred to as owner trust, and as the name implies, has to do with a key's owner and is used to specify just how much trust you have in a person's key to validate, or introduce, other keys on your keyring. As mentioned, this is because although a person may not be able to personally verify the validity of another's key, GnuPG allows trusted keys to validate to various extents other keys containing that trusted key's signature. The validity of these introduced keys depends on the amount of owner trust placed on the introducing key. A greater amount of owner trust yields a greater amount of calculated validity trust.

The default configuration for GnuPG specifies that if you haven't personally signed a key yourself, it can still be considered valid as long as two conditions are met. The first condition specifies that either the key has been signed with another key on your keyring that has been granted full owner trust, or the key has been signed by at least three other keys on your keyring that have been granted marginal trust. The second condition requires that the path of signed keys leading back to your own key (and inclusive of) include no more than six keys, or five 'hops'. These conditions can be altered in the GnuPG options, however, and can be made as tight (or flexible) as you wish them to be, but for most users the defaults are adequate and have withheld the test of time.

How do these levels of 'owner trust' work? Let's say you have personally validated and signed Greg's key and have assigned full owner trust to that key. You've since imported Sandra's key. Although you can't possibly validate her key personally since she lives in a distant city (and you've never met or spoken with her before), as Greg has signed her key it will be considered fully valid.

In a perfect world, the owner of every key on your keyring would be fully trusted, but that just isn't the case. It would be nice, and is why I try to stress the importance of keeping your web of trust sound, but there will be keys on your keyring whose owner you simply might not want to place trust in either due to their lack of knowledge in dealing with public-key security, or the seriousness they place in trust values. There might also be keys belonging to people that you just don't know enough to grant trust to, or people you simply don't know at all. They're all a part of your web of trust however, so GnuPG addresses this by allowing you to assign levels of owner trust to each of your keys.

Assigning owner trust to a key on your public keyring uses the same interactive menu system that can used to sign keys ('gpg --edit-key keyID'), and there can be one of five levels of trust placed on a key. If you recall, when you first chose to sign a key with the interactive editing menu, you were displayed with something similar to:

pub 1024D/2B94CF89 created: 2001-01-01 expires: never trust: -/f

sub 1024g/12E688D4 created: 2001-01-01 expires: never

(1). Close Friend (GnuPG Gnut)

The two types of trust are displayed on the right. The owner trust level is displayed first, and the validity, or calculated trust level is displayed second. In this example, a "-" appears for the owner trust level, and an "f" appears for the validity trust level, indicating the key has been signed, but no owner trust level has been established.

In dealing with owner trust, if the level is signified by a dash ("-"), it simply means that no level of trust has been assigned as yet. This is the default level placed on any new key imported into your keyring. If you don't know this person and have no level of trust to place on the key, simply leave this level of trust where it is. As there is no level of trust yet established, this key will never be used in validating another's key.

The second level is signified by an "n" and means no trust, or to not trust this person to correctly verify others signatures. Since these levels can be changed at any time you might assign this level to someone that is new to public-key use until they've grasped the hang of it. Then again, the key may belong to someone you know that is careless in the way they carry out key verifications and don't wish to have possible falsely validated keys pollute your web of trust. With a trust level of this grade, this key won't be used in validating another's key either.

The third level is signified by an "m" for marginal trust. Assigning marginal trust to a key indicates that you feel pretty confident that the key's owner understands the importance of proper key verification before placing their signature on a key. Bringing our example users back into the picture again, Greg mentioned to you that he has assigned full owner trust to Sandra's key on his keyring. You trust Greg's judgment of course, but since you don't personally know Sandra, her key might be a good candidate for marginal trust consideration until she's proved herself otherwise. With a trust level of marginal, if your public keyring contains a key, which in turn has been signed by at least three other keys on your keyring of marginal standing, that key will be considered valid. Quite often, the majority of the public keys on your keyring will likely be granted this level as your web of trust grows and your keyring expands.

The fourth level, signified by an "f" for full trust, is the level you would give to a key who's owner you have no doubts about their understanding of public-key use and verification checks, and is someone who's trust you would consider as good as your own. Our friend Greg would be a good example of someone worthy of full trust. He's been using GnuPG or PGP for quite a while, has established a good web of trust, and definitely takes every precaution in validating keys so as to not spoil that web of trust. With a full owner trust level, any key on your public keyring signed by this person's key will be considered fully valid.

The fifth level, signified by a "u" for ultimate trust, is used only for keys in which there is a corresponding secret key available. In other words, your personal public keys will have the status of ultimate trust when placed on your keyring. Needless to say, any key on your public keyring signed by you is considered a fully valid key, and is why it's important that you properly validate keys via proper methods before you sign them. Get carried away by signing anyone and everyone's key without properly verifying them first and you will quickly pollute your web of trust. I'm sure I've said that enough so I'll leave that topic alone now.

GUI Front Ends

Since GnuPG is command-line oriented (which actually adds flexibility to the utility) some users may be disappointed or miss a graphical user interface. This may especially hold true for newer Linux users transitioning from a graphical desktop OS like Windows. Although there are graphical front-ends to the application similar to those in earlier PGP days, they are still in the development stage and may lack the 'polish' you expect, or have grown accustomed to. Although several GnuPG interfaces exist, I will only touch on a few of them here.

GPA - GPA, or GNU Privacy Assistant, is actually being developed by the GnuPG organization. Utilizing GTK (the GIMP Tool Kit) for its interface's widgets, GPA allows you to encrypt/decrypt files, view your keys, signatures, sign keys, edit trust levels, and import/export your keys to a public-key server among other things. Like many GUI front-ends, GPA is early work in progress, yet the version I'm currently using, 0.4.3, seems to be very stable. One area that GPA currently lacks is a system for the application's Help button (it's unresponsive). The interface is very intuitive however, so this certainly isn't a major drawback, but indicates there is still work to be done.

Seahorse - Seahorse provides a graphical interface much like GPA, with perhaps one of the nicest graphical front-ends to GnuPG that I've run across so far. Still very early in the development stage and currently at version 0.5.0, this GUI front-end provides much of the same functionality of GPA. Although the interface is very appealing to me, I did find that in its current state the application does suffer from a rare lockup now an then when used on my Debian 2.2 and Red Hat 7.1 systems. No data is corrupted, and killing the application is easy, but like most early projects this is to be expected. The author has recently announced a request to take over the Seahorse project, as development has stagnated for over a year now. Hopefully, someone will come to this worthwhile application's rescue.

TkPGP - Another nice GUI interface for GnuPG. TkPGP is written with Tcl/Tk, and also allows you to sign and encrypt documents in a text window, select files for encryption, decryption, signing and verification, but provides minimal key management functions. The application is capable of using a sizable number of GnuPG commands and configuration settings, providing a powerful interface to many of the GnuPG commands and options available, and includes the ability to remember your passphrase for a set time (handy when you're working with GnuPG for an extended period).

Other graphical front-ends exist for GnuPG and are worthy of consideration, so be sure to check into them before settling on one or two you like. There are also many character-based wrappers, written in Perl for example, that provide front-ends to this great utility. If you're operating at a character-based terminal and wanting a menu interface for GnuPG, be sure to check into these offerings as well. A rather comprehensive list of front-ends for GnuPG can be found at the GnuPG web site, or freshmeat.org.

Caveats

When working with sensitive data, whether you're using GnuPG or not, certain 'common sense' caveats should apply. In other words, you should be aware if your sensitive data is winding up in shared memory locations, temporary files, etc., and whether you are working with your documents over a network or on shared systems. The same concerns apply when using GnuPG or any other public-key encryption system.

Keep in mind that simply deleting a file does not actually remove the file's contents from the hard drive, and that it can often be recovered with a little work. Also, if the application you're using to create a sensitive document uses 'timed' saves or writes buffers to an unsecured location on your system, even after thorough deletion of the file there may be enough of the original document left behind in these areas to thwart your security efforts. Various file-wiping utilities exist for most platforms (such as 'shred' or 'wipe' for Linux), so if such a scenario applies to your situation, you should seriously consider looking into using one of these.

If you're using a shared terminal or operating over a network, you may consider using removable media such as a floppy or zip disk for your document's creation and encryption location... just don't leave it behind! You may also want to look into the features GnuPG has for encrypting text and messages straight from the terminal's keyboard. No plain-text file is left behind to worry about, as it's saved straight to an encrypted file.

Don't forget that your GnuPG secret keyring should be kept protected at all times. This file, secring.gpg, is kept in the ~/.gnupg directory by default. If your terminal is shared or if your home directory is stored on a server somewhere, you'll definitely want to configure an alternate location for this file in your ~/.gnupg/options configuration file. It could be kept on a floppy diskette, or even renamed and moved to another directory location if needed, as long as that location is secure.

For those that utilize shared terminals at work, a web caf� or truck stop, there's even a small distribution of Linux, Tinfoil Hat, developed especially to operate in conjunction with GnuPG. A bootable floppy that for the really paranoid even utilizes a wrapper for GnuPG called gpggrid to circumvent keystroke loggers, Tinfoil Hat Linux not only provides a reasonably secure place to store your keys and encrypted documents (reasonable as it's not handcuffed to your wrist), but also provides secure encryption and decryption of your files in RAM.

Keystroke loggers, or key loggers, can be software, or even small devices or plugs that attach between the system and the keyboard, logging every keystroke entered by the user (thereby capturing any text, including any passwords and passphrases that may have been entered). The hardware loggers, being small and usually attached at the back of a system, are many times overlooked and can go unnoticed. Software key loggers may save the keystrokes to a file, or transmit them over a network to another system.

If your data is sensitive, and your system accessible by others, be aware of the security measures that need to be taken into consideration in protecting your passphrase. A weak passphrase, or one that can be discovered easily, nullifies the security available with public-key encryption. The point is that your passphrase, as mentioned, is the weakest link in your encryption. Guard your passphrase well, and use common sense in keeping it safe or your efforts will be futile.

Also, if you haven't done so already, copy your keyring files to the same diskette as your key's revocation certificate and place it in a safe or deposit box for security's sake. Since the revocation certificate generated when you first created your key pair probably only includes 'generic' comments explaining your reasons for revoking the key, keeping a backup copy of the keys allows you to generate a new certificate with details should your secret key ever become compromised or lost.

Conclusion

We've now covered your introduction into using GnuPG. As you have seen, it's not difficult to use, and in fact most of it is rather intuitive. When its features are used from within many other applications such as email clients or supportive applications or plug-ins, much of what goes on in the background is transparent, simplifying matters even more. The steps to using GnuPG are just as simple . . . come up with a good passphrase, create a key pair and its revocation certificate, experiment with it, publish your public key to a key server when you're satisfied, establish and build your 'web of trust', and last but certainly not least, always keep security in mind.

Although the use of public-key security has grown tremendously since those early PGP days, it still has a long way to go to gain popularity in many countries, perhaps due to the overall sense of freedom those countries enjoy within their boundaries. With the tremendous growth of the Internet, thefts of corporate data and the proliferation of crackers and script-kiddies, those boundaries have dissolved. Once you've started using GnuPG with regularity you'll perhaps wonder what you did without it. With the numerous worries about the need for increased security defenses in businesses, corporations and homes, you may even find that it brings a bit of stress relief to your life!

An Introduction to GNU Privacy Guard (Part 1) is available here.

About the author: David Scribner has been an IT consultant since 1984. Scribner advises small and mid-size businesses on a wide range of services from training to technical services.

Copyright � 2002 David D. Scribner. Reproduced by DesktopLinux.com under license. This document may be freely distributed and copied in whole or in part, as long as credit to the author is given.

A version of this article appeared at Linuxguru.net.